Agreely and consent-management platforms

If you already run a consent-management platform (CMP) such as OneTrust, Didomi, or Osano, a fair question is whether Agreely overlaps, and whether you need both. This page answers that plainly. The short version: a CMP and Agreely solve different halves of the same law, and for many teams the right answer is both. Agreely is designed to sit alongside a CMP, and even behind one, not to replace it.

The crispest way to see the split is by scope. A CMP governs cookie and tracker consent on the web: banners, tag and script blocking, IAB TCF strings. Agreely deliberately does not do the cookie-banner job. It governs consent for the personal data your own systems process, server-side, at the point your backend actually touches the data. Same law, different scope on purpose: web and cookie consent on one side, data-use consent on the other.

#Two different jobs

A CMP is built to collect a consent signal and control the browser. It renders the banner and preference center, scans cookies, geo-targets the notice, and blocks scripts, cookies, and tags from firing until a category is accepted. That is real Law 25 work, and it is the front door most websites need.

Agreely is built to prove consent and enforce it where your server uses the data. It issues a signed receipt an auditor can verify without trusting Agreely, and it answers one synchronous, fail-closed question inline in your backend before you use a piece of personal data for a purpose:

Has this customer granted this category for this purpose, right now?

A CMP stops a tag from firing in the browser. Agreely stops your billing job from using a phone number it was never licensed to use. Those are different points in the stack, and both matter.

#Side by side

We name a "typical CMP" generically here. Products differ, features change, and the summary below reflects the category as commonly built, not a claim about any one vendor's current release. Verify specifics against a vendor's own documentation.

	A typical CMP	Agreely
What it governs	Cookies and trackers on your website (banners, tag and script blocking, IAB TCF strings)	The personal data your own systems process, at the server-side point of use
What it optimizes	Collecting consent and controlling cookies and tags in the browser	Proving consent and enforcing it at the server-side point of use
Where it runs	Client-side banner plus tag and cookie blocking	A synchronous /v1 check your backend calls inline
How consent is logged	Stored in the vendor's database or managed ledger, signed with a key the vendor holds	A signed receipt (W3C Verifiable Credential, EdDSA plus WebAuthn passkey) tied to keys published in a DID document
Third-party verifiable without the vendor?	Verification runs through the vendor or its API	An auditor can verify without trusting Agreely *
Enforcement point	Blocks cookies and tags in the browser	Fail-closed check per (customer, category, purpose) cell in your backend
Tamper-evidence	Vendor database or managed ledger	keccak256 and Merkle commitments anchored on a public chain (Base; testnet today)
Breadth	DSAR automation, data mapping, vendor risk, cookie scanning, banners, PIA templates	None of that, on purpose

* Fully true offline today for company-attested receipts. A citizen-signed receipt reaches only partial offline verification until the server verify path ships. See the caveats below.

Note the honest asymmetry in the last row: a CMP is far broader than Agreely. Cookie banners, geo-rules, DSAR workflows, data mapping, and cookie scanning are all real, necessary work, and Agreely does none of it. Agreely is deliberately narrow: one accountability layer, done so it holds up without trusting the vendor.

#When to use which (often both)

• You need a cookie banner, geo-rules, tag control, DSAR workflows, or data mapping. That is a CMP. Agreely does not do these and does not try to.
• You need to prove, after the fact, that a specific data use was licensed, in a way a regulator or auditor can check without taking your word for it, and you need your own code to refuse the data when it was not. That is Agreely.
• You need both, which is common. Let the CMP own the banner and the browser, and let Agreely be the accountability layer behind it for the server-side data uses that carry the Law 25 risk. Agreely can sit directly behind a CMP.

#The one honest distinction

Most consent tools can show you a record they hold. The question Law 25's accountability principle really asks is whether someone who does not trust the vendor can still verify what was agreed. Today the major CMPs sign their consent records with a key they hold themselves, whether a shared-secret token, a vendor-held signing key, or a managed ledger behind the vendor's API, so verification runs through the vendor. Agreely signs with asymmetric keys published in a DID document, so the proof stands on its own. That is the line, and it is why Agreely exists as a separate layer rather than another banner.

#Honest caveats

We hold ourselves to the same honesty about our own limits that we ask of any comparison. The honest boundaries page lists the full set of claims Agreely refuses to make.

#Next

• What Agreely is
• Consent accountability
• Verifying a receipt
• Honest boundaries