Who Holds the Keys to the Agent Web — Part 3: Who Gets the Receipt
Independent research. Available for advisory, research collaboration, and expert consultation. Get in touch
Agents are quickly becoming the executors of transactions. But the transaction is only the beginning. What happens after the task is complete, when terms change, exceptions appear, disputes arise, and someone has to prove what was decided? That is the post-transaction relationship. In agent commerce, the deepest capture will look like a service that remembers your operations better than you do. And the risk goes beyond the vendor training on your data and moves to the vendor becoming the only party that can explain how the work was done.
In Part 1, I argued that authentication is where the open agent web closes first. Whoever manages the credentials that let agents act on your behalf sees the complete graph of everything those agents touch. The capture mechanism was security, based on the argument that centralised identity management is safer than the local alternative.
In Part 2, I followed the money into agent-to-agent commerce. The commercial graph, the thread that includes the transaction history plus the legitimacy layer plus the reasoning traces of what was decided and why. That was the capture mechanism. No single entity holds the whole graph yet, but the infrastructure being built will make it assemblable by anyone positioned at enough intersections.
Part 3 follows the question that neither part fully answered. What happens after the transaction is done? What happens after the session is closed, the context has cleared and the record has settled on both sides. This post-transaction state that includes the amendments, the disputes, the obligations that persist, the history of what was agreed and what changed after, this is where the most detailed capture in agent commerce occurs. And this is where the fewest open alternatives are being built.
The autopilot services described here are real. They are shipping and accumulating context as you read these lines. The outsourcing dynamic they create has been documented in management research for decades. But the full system with agents managing things like long-lived commercial relationships, disputes arising from decisions no session can reconstruct, analytics brokers assembling cross-layer graphs, this is still forming. Some of what is written here is diagnosis of what already exists and some is projection from the architecture being built. The point is that the defaults are being set up now, and once they harden, the operational record will belong to whoever kept it.
There are two forms of this post-transaction capture, and this article addresses both. The bounded case is where the agent disappears after a transaction and the evidence of why it acted disappears with it. The persistent case is where the autopilot stays, handles the next exception, and accumulates the relationship over time. The first creates an evidence gap while the second creates a memory dependency. But in the end both produce the same asymmetry where one side keeps the usable record, and the other does not.
The autopilot is not the agent
Parts 1 and 2 described capture mechanisms that operate on agents, What happens to the systems that run, complete a task and then stop. The auth layer controls what the agent can reach and the transaction layer controls what it buys. Both of these layers assume an agent with a defined scope and a defined endpoint.
The most consequential AI services emerging now are not agents in this sense. They are autopilots, that is persistent services that do not disappear when a task is done. The accounting service that closes your books is something that forms a relationship you maintain. It comes back next quarter and handles the exceptions from last quarter. It accumulates the history of every close, every flagged item and every judgment call. It logs every time you overrode the default and every time you let it stand.
The capture mechanism at the post-transaction layer operates differently depending on which entity you are dealing with. An agent that books a flight and closes creates a bounded record. But an autopilot that manages your travel budget indefinitely creates an unbounded one. The auth layer and the payment rails do not distinguish between them. The capture implications here are entirely different, and it is the persistent service (the autopilot) where the post-transaction capture concentrates.
The vendors building it are explicit about what they are selling. Harvey markets its Memory feature under the tagline "Never Start From Scratch Again". The system carries forward matter details, relevant precedent, working preferences, and approved best practices into every AI output. Sierra describes an Agent Data Platform where every interaction enriches the agent's memory, making future interactions more impactful, and where every interaction strengthens its intelligence. Writer's homepage says the platform encodes a company's DNA into AI agents by embedding the context, standards, and tools the team runs on. Cogent's security platform describes continuous learning from outcomes. When operators approve an exception or complete a fix, those outcomes update the knowledge graph, and the system adapts its reasoning to match the organisation's patterns. Lindy's documentation contrasts its system with stateless tools. Unlike stateless AI tools, Lindy builds context across every interaction and gets better over time.
Every one of these vendors is telling that the service improves because it accumulates your operational context. The longer you use it, the better it gets. That is the pitch, the accumulation is genuine and the quality improvement is real. The question is what else accumulates alongside the quality.
Sequoia Capital named this shift explicitly in their March 2026 thesis. They state that the next generation of AI companies would sell outcomes, not tools. It is the transition from Copilot to autopilot. A copilot sells the tool while an autopilot sells the work. Bessemer Venture Partners' State of AI report the same year was more direct about the structural consequence. They claim that the accumulated intelligence on the user and their specific environment become the stickiest assets. When an AI product understands a user's world better than anything else, replacing it feels like starting over. The vendor's marketing copy and the analyst's moat thesis describe the same mechanism from different sides of the table.
The context graph that builds itself
The AI-native accounting service that closes your books every quarter keeps the working memory of the close. It knows which items were flagged, which calls were made, which exceptions were approved, which ones were rejected, and why. Over time, it sees patterns that are invisible in any single quarter. It learns how your organisation behaves when policy meets reality.
This is the context graph. It is a map of how work actually gets done and it is built from decisions, exceptions, approvals, overrides, recurring patterns, and the small judgment calls that rarely appear in formal documentation. The service only needs to do the job well, remember what happened, and carry that memory forward.
So what makes this different from ordinary software lock-in? A traditional platform learned how you used the tool but an autopilot learns how the work itself should proceed. It does not merely observe behaviour from the outside. It participates in the judgment loop and as the thinking becomes inseparable from the work, you end up handing the thinking to the autopilot.
The strongest lock-in mechanism at this layer is not whether the provider trains its frontier model on your data. Most enterprise providers explicitly disclaim this on paid tiers, and those disclaimers are largely credible. The lock-in is whether the service embeds your operational logic in persistent service-side memory. The tenant-grounded retrieval layers, agent skills, managed pipelines, the workflow logic that accumulates over time and is costly to migrate. “No training on your data” is not the same as “no lock-in.” The memory of how your organisation actually operates lives in the service’s operational layer, not in the raw training data, and that layer is where the switching cost compounds.
There is also a counter-argument here that needs to be stated fairly. The accumulation is the value proposition. The autopilot that knows your operations better after three years is better at its job precisely because it has accumulated your context. You cannot have the service quality without the context accumulation. But the question is not whether the autopilot should accumulate. Obviously it must do so. The question is whether the canonical record of that accumulation lives in your infrastructure or theirs. The quality improvement and the lock-in are the same mechanism. The only thing that separates them is where the record is kept.
The vendor also has legitimate intellectual property in the system that produces that performance. This IP lives in the model weights, the orchestration code, the generic heuristics, and the safety mechanisms that apply across all clients. But the customer-specific state is not the vendor’s product. The prompts, the workflows, the exception history, the approvals and overrides, the decision logs, the pending obligations, these are the record of the customer’s work, generated by the vendor’s product while acting on the customer’s behalf. The vendor can own the system but the customer should own the customer-specific state needed to continue the work elsewhere.
GDPR Article 20, the EU Data Act, the Digital Markets Act, and related regimes, distinguishes between data you provided and data the provider inferred or derived from it. The European Data Protection Board’s portability guidelines include data actively supplied by the person and data observed from their use of a service, but they expressly exclude inferred and derived data created by the provider. The Data Act’s switching rules require export of customer data and digital assets, but they also exclude information specific to the internal functioning of the service where export would risk breaching trade secrets. Even the Digital Markets Act, the EU’s strongest anti-lock-in instrument, stops at derived data in the draft joint guidance.
But current portability law does not clearly require an AI service provider to hand over the operational understanding it built from your work. It may have to return the data you provided, the usage data it observed, or the outputs it generated but it does not clearly have to return the learned map of how your organisation makes decisions.
When you leave, you may get the files, the logs, and the outputs. What you may not get is the accumulated understanding that made the service useful.
This is why “no training on your data” is both true and incomplete. The vendor may not be training a frontier model on your records. But it can still become the only place where the working memory of your organisation lives.
The outsourcing wedge
There is a pattern in professional services outsourcing old enough to have its own management literature. After three years, the outsourcer knows the client's systems better than the client does. The switching cost is the institutional memory the outsourcer accumulated by doing the work. You can terminate the relationship but you cannot take back three years of context.
Cohen and Levinthal’s foundational work on absorptive capacity established why firms that outsource too deeply lose the ability to re-internalise what they externalised. Once the internal knowledge base atrophies below a threshold, the client can no longer recognise, evaluate, or recapture the capability they transferred.
The vendor gains in the opposite direction. The more clients it serves, the more edge cases it sees. One client’s exception becomes another client’s improvement. A reconciliation problem in one accounting workflow, a procurement exception in another, a compliance workaround in a third — these gradually accumulate, and each teaches the vendor something reusable. The client learns only from its own case, but the vendor learns across all of them.
Autopilots create this dynamic faster and more completely. The outsourcer observed your organisation from outside. The autopilot is inside the work. Every decision it makes on your behalf is an observation of how you make decisions. Every exception it handles is a data point on what your preferences actually are, not what you stated they were. Every quarter of accumulated history is context the replacement service does not have.
The switching cost here is only partially about data portability. In reality, it is mainly about the accumulated model of your operations that the current service holds and any replacement does not. You can export a transaction log, but you cannot easily export the contextual understanding that makes the log interpretable. The new service would need to rebuild that model from scratch, in your operations, over time, making the errors the old service learned to avoid. That learning period is the switching cost, and it is invisible in the subscription fee.
The important question at this layer is simple: where does the operational record live while the work is happening?
It does not have to mean rejecting managed vendors or self-hosting everything. A customer-controlled record could live in sovereign cloud, customer-owned storage, an escrowed archive, a continuous export package, or some other managed arrangement. The customer needs to keep the working record as the service runs. Not later. Not only at termination. Not as a special export after months or years of accumulated decisions have already settled inside the vendor’s system.
The missing piece is not a better export button but a working record the customer controls from the start. The autopilot can still do the work and the vendor can still run the service. But the history of what was decided, changed, approved, rejected, and carried forward should not live only inside the vendor’s system.
The brokered graph
No single company needs to control the whole commercial graph to assemble it.
At the post-transaction layer, the graph can be built by whoever becomes useful to all the parties that hold pieces of the record. The payment processor, the trust registry, the autopilot service, the dispute platform, the insurer, the auditor, each party keeps a slice. The broker only needs access to enough of them to start assembling the graph.
The insurance industry offers the clearest analogy. The insurer does not run the hospital, the pharmacy, or the employer. Through claims data, it sees the patient's health history, medications, and employment status simultaneously. It assembled the picture through utility, each counterparty found it useful to share, and the insurer assembled what none of them individually held.
The incentive structure for agent commerce is the same. The payment processors hold transaction data, the trust registries track reputation, the autopilot services hold the reasoning traces and the dispute platforms record what went wrong. No single entity controls all of these today. But a provider offering fraud detection, risk scoring, and service quality signals to all four simultaneously would need read access to each and each layer would find it useful to grant that access. The commercial graph can be assembled by a broker that becomes useful enough to all the parties who collectively hold the slices.
No dedicated analytics provider occupies this cross-layer position in agent commerce yet. But the position is being approached from the payment layer outward. The processors already hold transaction data, fraud signals, and merchant-relationship history, accumulating a cross-layer picture as a byproduct of providing useful services at multiple points. And the custody question is currently unspecified in most of the standards proposals being developed for agent commerce which means the authoritative record defaults to whichever party maintains the most complete operational record. In a system where custody is unspecified, the most diligent record-keeper wins by default.
The absent agent
What happens when something goes wrong after an agent-mediated transaction?
When the service delivers something different from what was agreed. When the terms change after the contract is signed. When a cancellation triggers a rebooking. When a dispute arises over whether the agent accepted a condition it should not have accepted. At that moment, everyone needs to know what the agent saw, what alternatives it rejected, what instruction it was following, and why it chose the option it chose.
But the agent that made the original decision may no longer be there. The session has closed, or the context was cleared. The documents it retrieved may have changed and the tools it called may return different results now. What remains is whatever record was preserved from it.
So the human falls back on channels built for human transactions. A support ticket, a chargeback form, a phone call, an email thread, all the familiar channels that can handle a failed delivery or a disputed payment. But these where not designed to resolve a dispute about a decision made by an AI agent acting under delegated authority, using context that may no longer exist.
The higher-stakes version of this is procurement. An AI procurement autopilot selects a supplier, negotiates terms, handles amendments, and later the project fails. The vendor has the negotiation history, the rejected alternatives, the risk notes, and the sequence of exceptions. The buyer has the signed contract and scattered logs. When the dispute arrives, the party with the fuller record has the stronger position.
That asymmetry is the system working as designed. But it was designed for a world where both parties to a negotiation kept their own records and could reconstruct their own reasoning. Agent commerce breaks that assumption.
The legal framework we have today for AI-mediated transactions was built for a simpler problem. The UETA, enacted in 1999, and the federal E-SIGN Act define an “electronic agent” and recognise that contracts can be formed by interacting electronic systems without a human reviewing every step. Current law is good at saying that a transaction happened but it is much less clear about what happens when the transaction was negotiated by an agent that no longer exists in the form that made the decision.
Agency law puts the responsibility with the human or organisation that delegated authority, and with the service provider where appropriate, not with the AI as if it were a legal person. But that answer assumes the responsible party can explain what the agent did and why. No jurisdiction has yet settled what proof is required when the agent session that made the decision cannot be recreated. The FTC has made clear that there is no AI exemption from consumer protection law. The gap here is whether anyone has the record needed to understand what happened.
The EU AI Act comes closest to this problem, but only for a narrow class of systems. High-risk AI systems must keep automatic logs, retain records for a minimum period, maintain technical documentation, and give affected people some right to explanation when AI plays a role in a consequential decision. That is the right direction. But most commercial autopilots will not be classified as high-risk systems. For them, the record-keeping duty is much weaker or unclear.
The older and simpler idea came from robotics. The Ethical Black Box proposal, published in 2018, argued that autonomous systems should carry something like an aircraft flight recorder. It should preserve what the system sensed, decided, and did, so investigators can understand the decision after the fact. The point was not to interrogate the robot later and hope it explains itself. The point was to keep a record at the time, because the system may be unavailable, changed, or unreliable by the time something goes wrong.
Agent commerce needs the same idea. Not a way to revive the old session or a screenshot of the final answer. But a durable record of what the agent decided and why, created when the decision happened and kept whether or not the session still exists.
Some standards are moving in this direction. IETF SCITT provides a way to create signed statements and receipts that can be retained over time. VCAP and ADRP propose structures for post-settlement state and dispute resolution. Singapore’s 2026 Model AI Governance Framework for Agentic AI calls for step-level tracing, alert thresholds, fallback paths, and escalation contacts for persistent agents. These are useful pieces but they do not yet add up to a mature, cross-vendor agent receipt: one record that captures the inputs, tool calls, authorisations, decisions, and redress paths of a completed agent action in a form that survives the session.
The memory systems now being deployed make the problem sharper. Anthropic’s “dreaming,” OpenAI Memory, and stateful agent systems like mem0 and Letta all process what agents did across sessions and turn that activity into memory. That memory persists but it does so inside the vendor’s system.
When the agent that acted is gone, and the memory of why it acted is locked in the same vendor’s system, the absent agent problem and the memory lock-in problem become the same problem. A dashboard that lets you inspect the memory while subscribed is not portability. A log view is not a handoff and an audit trail inside the vendor’s system is still the vendor’s record.
The test you can do here is simple: can another provider, auditor, court, regulator, or internal team use the record after the relationship ends? If not, the record only remained visible while the vendor allowed you to look at it.
There is one more complication. Even with logs, exact replay may be impossible. Models, tools and retrieved documents change. APIs return different results. The same agent may not make the same decision twice, even with similar inputs. So the standard for proof has to be stricter than ordinary software logging. The system needs to preserve the actual inputs, retrieved documents, tool outputs, model identifiers, instructions, approvals, and environment details from the moment the decision was made.
That is rarely how current autopilot systems are built.
The asymmetry compounds with every transaction. The service provider maintains a fuller record of every interaction while the buyer holds whatever the session produced before it closed, plus a notification that something changed.
What a handoff requires
Health records already have a formal transfer standard: HL7 FHIR. It gives hospitals, insurers, and health systems a shared way to move structured medical data between systems.
And yet medical handoffs still fail because the structured record is not the whole story. It can say what medication was prescribed, what test was ordered, what diagnosis was recorded. But it often does not carry why one treatment was chosen over another, what risks were discussed, what the clinician was watching for, or what accumulated judgment shaped the decision.
If an organisation wants to move from one autopilot provider to another, the new provider does not only need the transaction log but also enough context to continue the work without relearning everything from scratch.
That handoff would need at least five things.
The transaction history: what was agreed, with whom, under what terms.
The reasoning trace: why this option was chosen over the alternatives available at the time.
The preference model: what the autopilot learned about how the organisation actually behaves, not just what the policy says.
The exception history: where defaults were overridden, why, and what precedent that created.
The relationship state: ongoing obligations, pending disputes, amendments, cancellations, renewals, and anything else that depends on what happened after the first agreement.
The goal is not to standardise the entire autopilot before the category has settled. That would probably fail. Different providers should still compete on models, workflows, interfaces, automation quality, and domain expertise.
The narrower demand is a minimum handoff record. Not a full clone of the service or the vendor’s internal system. Just enough portable state for another provider, auditor, regulator, court, or internal team to understand what happened and continue from there.
No mature format for this exists yet. Some proposals cover pieces of it. VCAP describes post-settlement state: transaction status, amendments, dispute initiation, proof hashes, and action logs. ADRP describes dispute records: evidence, rulings, and appeals. Together, they cover part of the transaction history and part of the relationship state. But they do not cover the reasoning trace, the preference model, or the accumulated exception history.
The Accord Project offers a useful analogue from machine-readable legal agreements. Its model combines human-readable text, typed data for machines, and executable logic for validation. That is close to the shape agent commerce will need: a record that both people and machines can use. But there is no equivalent implementation yet for post-transaction agent state.
The first standards will probably capture what happened more easily than why it happened. Transaction status is easier to export than judgment. Amendments are easier to record than the reasoning behind them. A dispute file is easier to move than the preference model that shaped the original decision.
The handoff will be built around what the service can export. But the dependency lives in what the service learned and did not give back.
The format question
There is a reason why the answer at the post-transaction layer probably looks more like a document than a new protocol.
A protocol is useful while systems are interacting. It tells one system how to call another system, what endpoint to use, what fields to send, what response to expect. That matters for discovery, negotiation, payment, and execution.
But after the transaction, the problem changes. The record has to survive the interaction. It has to be readable months later, after the agent session has closed, after the model has changed, after the vendor dashboard has moved on, and after the people involved are arguing about what was agreed.
That record has two audiences.
The first audience is machines. Another agent, provider, auditor, or regulator needs to process the record without guessing what each field means. It needs enough structure to understand the transaction, the authority used, the terms, the amendments, the exceptions, and the dispute path.
The second audience is humans. A person needs to be able to read the record under adversarial conditions: during a dispute, an audit, a legal review, or a procurement investigation. They need to see what was decided, what changed, who approved it, what evidence was used, and what obligations remain.
Machine-readable alone is not enough but human-readable alone is not enough. The post-transaction record has to be both.
This is why a plain document matters. It should not be an informal note, or a PDF graveyard, but a structured document: dated, signed or hashed where needed, readable in plain language, and carrying machine-readable fields underneath. Something an agent can process, but also something a human can inspect, contest, and hand to another party without needing the original vendor’s system.
The history of web services is useful here because we have seen part of this ambition before. In the early 2000s, SOAP and WSDL tried to make software services describable in a formal way. A service could publish what it did, how to call it, what operations it exposed, and what messages it expected. UDDI went further. It tried to create a universal registry where services could be discovered automatically.
Agent commerce will need something similar: services that describe themselves, publish their capabilities, and let other systems discover what they can do.
But the old stack mostly described interfaces. It told software how to call a service but did not tell software enough about whether the service was suitable for a specific transaction. It did not express the practical meaning that matters in commerce: what authority the service has, what constraints apply, what obligations are created, what liability exists, what remedies are available, what evidence would support a dispute.
That is why UDDI failed as an automated discovery layer. WSDL and UDDI could describe the shape of a service, but not enough of the meaning around it. They could tell a machine where the door was but they could not tell it whether walking through that door created a binding obligation, what risks attached to that obligation, or what happened if the service failed.
The same risk exists now. New agent discovery drafts such as APIX and the agent:// URI scheme are useful because they describe identity and capability. They help agents find services and understand what those services claim to do. That is necessary but it is not enough for the post-transaction layer.
Identity and capability tell the agent who it is dealing with and what that party can do. They do not by themselves preserve what was agreed, what authority was used, what conditions applied, what could be revoked, what obligations remain, what remedies exist, or what evidence supports the decision after something goes wrong.
Agents do not have the same constraint that weakened SOAP and WSDL. They can read formal structure, parse long documents and combine prose, schemas, logs, hashes, and signatures in ways ordinary software could not. That means the old ambition is more feasible now than it was twenty years ago.
But the lesson from that earlier failure still matters. The right format is not determined only by what machines can parse but also by what the accountable party needs to keep.
At the post-transaction layer, the accountable party is still human. A procurement officer, regulator, auditor, judge, buyer, or operator may need to understand the record without rerunning the agent and without trusting the vendor’s dashboard. The amendment record, the exception log, the relationship state, the dispute history, all of these need to live in a form that survives outside the system that produced them.
So the format should not be just a protocol call but also a record. A document with structure that is plain enough for humans to read but formal enough for agents to process. Durable enough to survive the session and portable enough to leave the vendor.
What can be demanded now
There is no standard enterprise framework for AI switching costs yet. But buyers do not have to wait for one.
The building blocks already exist. Public-sector AI procurement terms are beginning to name the problem directly, the vendor lock-in, export rights, deletion, open formats, and dependency on proprietary systems. The European Commission-backed model contractual clauses for AI procurement address vendor lock-in and require rights in datasets beyond the agreement term. The U.S. General Services Administration’s draft AI terms go further. They define “Government Data” broadly enough to include prompts, system prompts, knowledge bases, outputs, logs, and metadata. They also require export in open machine-readable formats and prohibit proprietary technologies that create vendor dependencies.
Government buyers are already asking questions that banks, insurers, hospitals, universities, and large companies should also ask. The question is no longer only “Is our data safe?” but “Can we leave without losing the working memory of the service?”
That can be turned into three practical vendor questions.
First: what do we get back if we terminate?
Not in general terms but exactly what do we get back, in what format, by what deadline? Do we get prompts, system prompts, knowledge bases, workflows, logs, outputs, metadata, decision histories, exception histories, approvals, overrides, and pending obligations? Do we get them in an open format another provider can use? What do you certify deleted, and when?
Current vendor practice varies. Writer’s enterprise agreement makes customer materials available for export for thirty days after termination and promises secure destruction on request. Harvey’s platform terms confirm customer ownership and thirty-day deletion. Sierra’s public materials, by contrast, do not clearly describe what a customer can export at termination. The platform evidently stores operational context, but the exit deliverables are not specified publicly.
Second: what do you keep or use after we leave?
This is where the “no training on your data” reassurance stops being enough. A vendor may not train its frontier model on your records and still retain useful operational metadata. It may keep aggregated or de-identified information about how the platform was used, which workflows ran, which errors appeared, which interventions improved performance, or which patterns repeated across customers.
That may be acceptable but it needs to be explicit. The buyer should know what the vendor retains, what it reviews, what it aggregates, what it uses to improve the service, and whether any of that can be opted out of. Writer’s enterprise agreement illustrates the gap: the customer owns materials and outputs, and Writer says it will not train on customer data, but it may aggregate and de-identify “Platform Metadata” and use it for any purpose, including improving the platform. That carve-out is not automatically disqualifying but it should be understood, negotiated, and priced before signing.
Third: what would it take to move to another provider?
This should be answered before the contract is signed.
The buyer should ask for a dependency schedule: which third-party models, vector stores, guardrail layers, connectors, identity systems, data stores, workflow engines, evaluation tools, and proprietary components does the service depend on? Which parts are portable? Which parts are not? What would a replacement provider need in order to continue the work? What transition support is included? What would additional transition support cost?
If the vendor cannot produce a dependency schedule, a migration plan, and transition-support terms, that opacity is itself a procurement risk.
The minimum contract position is no longer “export our data.”
It should be:
customer ownership of data, prompts, workflows, outputs, logs, and customer-specific operational state;
no training or cross-customer use without written opt-in;
clear rules for retained, aggregated, or de-identified metadata;
continuous export during the contract, not only after termination;
a post-termination export window;
deletion certification;
transition assistance at pre-agreed rates;
and a dependency schedule showing what is portable, what is not, and what another provider would need to continue the work.
This is the practical version of the argument this article has been making. If the autopilot is going to learn how your organisation works, the contract has to say what happens to that learning when you leave.
The pattern holds
Parts 1 and 2 each described a capture point with a real argument behind it.
In Part 1, the argument was security. Agents need credentials and credentials need to be protected. So the identity vendor becomes the obvious place to manage them.
In Part 2, the argument was efficiency. Agents need to pay, compare offers, verify services, and resolve trust. So the payment rail, registry, and commerce platform become the obvious places to coordinate them.
Security and efficiency matter. The question was whether they require centralisation, or whether the same protections can be built with infrastructure the user or organisation controls.
But the post-transaction layer is different.
Here, the capture mechanism is accumulation. The autopilot remembers because remembering makes it better. The broker assembles the graph because each party finds it useful to share a slice. No one has to argue for capture or announce a strategy. The record builds up as a side effect of competent service.
That makes this the hardest layer to defend.
The counter-position is simpler and harder: keep the record from the start.
If the decisions from every close, contract, exception, amendment, and dispute are kept in a record you control while the work is happening, the switching cost cannot compound in the same way. If the record only appears as an export after you decide to leave, it is already too late. The useful history has already settled inside the vendor’s system.
The portable record is a choice made at the beginning: who keeps the working memory of the service? The first open alternative only needs to keep the record the autopilot would otherwise own.
Post-transaction capture is harder to see because it looks like service and takes longer to complete. The autopilot that knows your operations better after three years is not doing anything strange. It is just doing its job well, but doing the job well produces a record. And whoever keeps that record keeps the advantage.
The infrastructure being assembled now will decide where those records accumulate. The autopilot services, analytics providers, dispute platforms, risk brokers, the defaults for them are still being written and the choice is still available.
But defaults harden quickly because institutions build habits around what works first. Procurement templates adapt, compliance teams approve familiar vendors and gradually migration becomes more and more expensive. The open option can remain technically possible and still become practically disadvantaged.
The open web was captured through convenience. The AI auth layer is closing through security. The AI commerce layer is forming around efficiency.
The post-transaction layer is subtler than all three. The capture is the record you never kept, while the AI service kept it quietly in the background.
It becomes visible only later, when something changes, something fails, or someone asks why the agent made the choice it made.
And by then, the question is no longer who ran the service.
It is who can explain the work.
Published: May 2026 · Author: Lida Liberopoulou · License: CC BY-SA 4.0