The Week a Tool Count Stopped Counting as a Disclosure
The most consequential release note I read this week was one sentence long.
On the eleventh of August, Klaviyo’s What’s New feed added an entry titled “Klaviyo MCP Server, New Tools”. The body reads, in full, that you can give AI agents and developers full programmatic control of your Klaviyo account, using 260 or more new MCP tools to read data, build segments, run campaigns, author flows and manage catalogs, from Claude, from OpenAI, or from your own agent.
That is the largest agent surface any customer engagement platform on my watchlist has ever put in writing. It is also, as a disclosure, about a third of one.
TL;DR
- Klaviyo published the largest agent surface on my watchlist and none of the numbers that would let you govern it. 260-plus MCP tools with four named write verbs, in one sentence, with no session lifetime, no permission inheritance model and no revocation path. The vendor with the only published governance numbers, MoEngage, has a far smaller surface.
- Five facts make a tool inventory governable: the count split by read and write, the write list enumerated, the session lifetime absolute and idle, the permission inheritance model, and how long a full revocation takes to propagate. We accepted a lower standard for MCP than we ever accepted for an API key.
- In four days the opt-out path became programmable, audited and finable. Twilio let a consent record clear a carrier-enforced block, CalPrivacy fined a broker $116,490 for gating that same path behind Social Security digits, and IAB Tech Lab finalised DDRF 2.0, which puts a signed identity assertion inside a deletion request.
- Personalisation identity and rights-request identity are two different problems with opposite cost structures. Personalisation makes false positives cheap, so thresholds get tuned generously. On a rights request a false positive deletes the wrong person’s data, and the instinct to compensate by collecting more identifiers is exactly what California has now fined twice.
The number Klaviyo published, and the two it did not
Start with what the sentence actually says, because it is more specific than most vendor language and it deserves credit for that. Two hundred and sixty tools is a real number. Klaviyo did not say “expanded MCP capabilities” or “deeper agent integration”. It said how many, and it named four verbs that are unambiguously writes: build segments, run campaigns, author flows, manage catalogs. Nobody reading that sentence can pretend this is a read-only intelligence surface with a fashionable protocol wrapper on it. An agent connected to this can create the thing that sends email to your customers.
Now look at what is missing, and notice that the absences are not exotic. There is no published session lifetime, so nobody outside Klaviyo knows how long an authorised agent connection stays authorised. There is no permission model in the note, so nobody knows whether these 260 tools inherit the permissions of the human who authorised them, or run with a broader service identity, or can be scoped down at all. There is no statement of what an agent authoring a campaign can do that an operator could not, which is the only question that tells you whether your existing approval workflow still means anything.
Last week MoEngage published its MCP session lifetimes: thirty days, or seven days idle, managed independently of dashboard and mobile sessions. I said on the AI beat at the time that these looked like the first hard session numbers anyone had put in writing for a vendor MCP surface, and that they were the benchmark question to take to every other vendor. Nothing has displaced them since. So we now have a market where the vendor with the largest published tool count has published no governance numbers, and the vendor with the only published governance numbers has a much smaller surface. I mean that as a description of a disclosure practice that has not settled yet rather than as a criticism of either vendor, and it means the buying question has changed shape. Six months ago the useful question was whether a vendor had an MCP server. Every major CEP answered yes by May. The useful question now is how many tools, which of them write, and what stops an agent from running a campaign at three in the morning because a prompt was ambiguous.
What a write-capable tool inventory should actually say
I have started keeping a short list of what I want a vendor to publish before I let an agent near a production engagement platform, and it comes from the same instinct as judging agentic marketing claims by what a vendor is willing to write down. This week gave it a sharper edge. It is five items and none of them are unreasonable.
The tool count, split by read and write. Klaviyo gave the count and implied the split; nobody has given both explicitly. The write list, enumerated, because “manage catalogs” covers both updating a price and deleting a catalog. The session lifetime, absolute and idle, which MoEngage has published and almost nobody else has. The permission inheritance model: does the agent act as the authorising user, as a service principal, or as something new that your identity provider has never seen. And the revocation path, meaning what a security team does at two in the morning when it needs every agent connection gone, and how long that takes to propagate.
None of this is a request for a vendor to slow down. It is a request for the same documentation any other integration has carried for twenty years. What is odd about the current moment is that we accepted a lower standard for MCP than we ever accepted for an API key, largely because the protocol arrived wearing the clothes of a developer convenience rather than an integration.
A tool count tells you what an agent can reach. A session lifetime, a write list and a revocation path tell you what stops it.
Twilio makes consent authoritative over the carrier
The second thread of the week has nothing to do with agents, and it is the one I expect to be rewriting client architecture documents about.
On the twelfth of August Twilio shipped support in its Consent Management API for toll-free network-level opt-out overrides. Until now, if a recipient in the United States or Canada opted out on a toll-free number, that block was enforced at the network level and there was exactly one way to lift it: the recipient had to text an opt-in keyword back. It did not matter what your CRM said, what your preference centre recorded, or what the customer had told a service agent. The suppression lived outside your data model and your data model could not reach it.
That is now no longer true. Where a recipient gives valid re-opt-in consent through another channel, a web form, an email, an in-app preference centre, you can log that consent through the Consent Management API and Twilio passes the signal downstream to clear the block. Twilio frames the benefit in deliverability terms, as the elimination of error codes 21610 and 30004, which is the honest commercial framing and undersells what has actually changed.
What has changed is the location of authority. A carrier-enforced suppression used to be a terminal state that your profile could observe but never alter. It is now a state your own consent record can change, through an API, with the evidence held on your side of the boundary. That means the consent object in your platform has just acquired real downstream power over a network the platform does not control, which is the same promotion the open-tracking pixel got last week when it became a profile attribute, and it means the quality of that object now matters in a way it did not last month. If your consent record cannot say which purpose, which jurisdiction, which channel, when, and on what evidence, you have just been handed an API you are not equipped to call responsibly.
California makes friction in the opt-out path finable
On the eleventh of August, the same day as the Klaviyo note, the California Privacy Protection Agency Board ordered a data broker called LocateSmarter to pay $116,490 and change its practices. Two findings. It failed to register as a data broker in time, which is administrative and unremarkable. And it required Californians to provide the last four digits of their Social Security number before they could opt out of the sale of their personal information.
The second finding is the one to read twice. CalPrivacy holds that demanding part of a Social Security number could intimidate consumers out of exercising a right they hold, and separately that doing so violates the CCPA’s data minimisation requirement, following the agency’s own enforcement advisory from January on how minimisation applies to consumer requests. This is the first CalPrivacy action against a data broker under the CCPA and the first arising under both the CCPA and the Delete Act, and it follows a decision against Ford in March, a $375,703 fine issued explicitly for adding unnecessary friction to the opt-out process.
There is one more detail that removes the obvious defence. The agency’s executive director noted that the fine was substantial even though only a handful of consumers actually submitted opt-out requests. Low volume is not mitigation. The finding attaches to the design of the path, not to how many people walked down it.
Deletion requests grow an identity assertion
On the same day, the IAB Tech Lab published updates to its Privacy Standards Portfolio. The part that got picked up in the trade press was the Global Privacy Platform work, and the part that matters architecturally was barely mentioned.
Two corrections before the substance, because I nearly repeated both. The item is dated the eleventh of August, not the twelfth, which is when the aggregator that surfaced it published its own summary. And that summary described the release as requiring support for Global Privacy Control signals, which is not in the primary document at all. The GPP changes are a public comment draft, open until the eleventh of September, and they concern alignment with the Fifth Amended Multi-State Privacy Agreement: removing MSPA coverage for the old state-by-state approach, eliminating Service Provider and Opt-Out Option Modes, removing secondary usage consents, and simplifying notice and choice fields.
The finalised piece is the Data Deletion Request Framework, version 2.0, which completes a comment period that opened in late 2025. Among its revisions: clarified identity and deletion request JSON Web Token definitions, improved result feedback and troubleshooting, strengthened framework integrity, and support for implementation-specific extensions.
Put plainly, a deletion request now arrives carrying a signed, structured assertion about who the subject is. That is not a legal artefact. It is a schema, and your identity graph either can resolve it or it cannot. Most of the deletion tooling I have seen in production takes an email address, runs the same match logic that powers personalisation, and deletes what it finds. DDRF 2.0 describes a request that says something more precise than an email address, and the systems that can act on it accurately will be the ones whose identity model was built to answer questions rather than to maximise matches.
A regulator, a messaging provider and a standards body, in four days, all working on the same path out.
The two identity problems most stacks solve once
Read the California decision and the DDRF revision together and a specific design flaw comes into focus, one I have built into systems myself without noticing.
Almost every stack I have worked on has one identity resolution capability, sitting where the CDP does the resolving. It was built for personalisation, and personalisation has a particular bias: a false positive is cheap and a false negative is expensive. If you match two records that belong to different people, someone gets a slightly wrong product recommendation. If you fail to match two records that belong to the same person, you send duplicate mail, fragment the profile, and lose the revenue the whole investment was justified on. So the threshold gets tuned generously, the graph gets built to find connections, and everyone is happy.
Then a rights request arrives, and the incentives invert completely. Now a false positive means you delete or suppress the wrong person’s data, and a false negative means you fail to honour a legal right. The cost structure that justified a generous threshold no longer applies, and the obvious engineering instinct is to compensate by asking the requester for more identifying information until you are confident. That instinct is exactly what California just fined, twice, in the same year.
So the rights-request path needs a verification threshold that is stricter than personalisation on accuracy and simultaneously more frugal on data collection. Those two requirements pull in opposite directions and you cannot satisfy both by reusing one match function with a knob turned. You are looking at a second identity problem with a different objective function, and it deserves its own design. I do not think many organisations have built it that way, and the enforcement record has now made the omission expensive rather than theoretical.
Personalisation makes false positives cheap. A rights request makes them the whole risk. Same graph, opposite objective functions.
Adobe’s quieter week, and the pattern underneath it
The rest of the week was Adobe, and it was better than its headline suggests.
Adobe Journey Optimizer added personalized PDF attachments to API-triggered emails on the twelfth of August. Up to five per message, static or recipient-specific, with recipient-specific files fetched from the Data Landing Zone at send time and each file’s location passed in the API payload. The restriction is real, transactional API-triggered campaigns only, but the pattern is the interesting part: Adobe is not generating the invoice, it is collecting one that your existing system already produced, at the moment of send, from a location you control. For anyone who has tried to move statement or policy-document delivery onto a customer engagement platform and stalled on the document generation question, that is the integration shape that makes it possible. It also means the send path now has a runtime dependency on a storage layer, which belongs in your failure analysis and probably is not in it yet.
The same day, AJO added LINE as a channel in Limited Availability, and it arrived through the Custom outbound channel that shipped on the thirty-first of July rather than as a bespoke integration. Treasure AI made LINE a first-class Always-on Campaign channel nine days earlier and shipped test-send flagging in its LINE delivery logs on the tenth. Two vendors, one window, one channel that Western roadmaps have historically treated as an integration project rather than a channel.
Journey Optimizer B2B began deploying 2026.8 today, taking person journeys from beta to general availability alongside person lists, variant split paths, journey re-entry and external action nodes on the person side. The two-model design that made that product hard to explain is converging. And Adobe Marketo Engage published August release notes on the tenth after a silence since the eighteenth of June, with a new interface, an AI Script Builder for personalisation scripts, and a small item that will save somebody a production incident: archiving a folder now disables and deschedules every campaign inside it.
What to ask your vendors on Monday
Three questions, and they are all versions of the same one.
Ask every platform with an MCP server for its tool count split by read and write, its session lifetime, and its revocation path. If the answer is a capability list rather than three numbers, you have learned something. Ask your consent architecture whether it can express purpose, jurisdiction, channel, timestamp and evidence as separate fields, because Twilio has just made that record authoritative over a network you do not control and the next provider to do so will not wait for you. And ask whoever owns identity resolution to show you the rights-request path, specifically, as a distinct thing from the personalisation path. If it is the same code with a different threshold, you have the design California has now fined two companies over.
A tool count is a capability statement. A session lifetime, a write list and a revocation path are a governance statement. This week one vendor published the first and none published the second, and the gap between them is the whole of the risk.
Sources
Klaviyo MCP server and Composer
Twilio consent management
California enforcement
IAB Tech Lab privacy standards
Adobe releases this week
- Journey Optimizer release notes
- Journey Optimizer B2B Edition release notes
- Marketo Engage release notes
Other vendor releases this week
The digest behind each weekly article is produced through a structured AI-assisted scan of official release notes and product update sources. I review the output, verify the relevant signals and write the architectural interpretation.
This article draws from the Martech Weekly Digest scans run on August 14, 2026, covering release notes and product updates across several CEP platforms and vendors. The dated record behind it is in MarTech Watch, Week 33.
If you find errors or gaps in coverage, I want to know. The process improves when the output is challenged.
