agentic systemsAgentic SystemsMachine AuthorityWeb3Settlement

Where Web3 Rails Become Material in Agentic Systems

Most agentic systems do not need Web3 rails. The subclass that does is the one where authority, value transfer, and settlement can no longer be separated, and no operator can be the accepted keeper.

Andrew Nalichaev··13 min read

An economic actor needs a record of its authority that every exposed party will accept. That is where the previous article landed, and it hides a trap that is easy to walk past. A record is only worth anything if someone keeps it. And the moment the record lives inside one participant's systems, it has collapsed back into the domain whose authority was the problem in the first place. The other parties are now trusting the keeper, which is exactly the trust they did not have. A mutually accepted record with no mutually trusted keeper is not an accounting detail. It is the whole question, and it is the only place in this entire subject where the word "blockchain" earns a hearing.

The question has one honest job: to say, narrowly and without flinching in either direction, when a neutral shared substrate becomes materially useful for agentic systems and when it is ornamental. It is a question worth refusing to answer too fast, because the fast answer is the lazy one, and the lazy answer is wrong for almost everything. Asked precisely, though, it can be answered, and the answer is that most agentic systems will never need these rails, while a specific, identifiable subclass cannot function without them.

Core claim

  • The keeper problem is the only thing that pulls a neutral substrate into agentic systems: a record all parties must accept, kept by none they are required to trust.
  • Shared trust is not the same thing as a public chain. A consortium ledger, a TEE-backed shared system, or signed attestations between parties often solve the keeper problem more cheaply and more appropriately.
  • Web3 becomes material only when three conditions coincide: the authority record is inseparable from value transfer, no single operator should own the shared state, and authority must be enforced at the asset layer or settled among mutually distrusting parties.
  • Most agentic systems never cross that line. Internal copilots, orchestrators, enterprise-local operators, internal audit, and most cross-organizational information exchange do not need Web3 rails.
  • The honest pro-Web3 case is narrow: neutral settlement and asset-layer enforcement among parties with no accepted keeper. It is not "agents need blockchain."

The keeper problem, stated exactly

The previous article ended on a lack: not a better grant, but a mutually accepted operational record of authority over time that no single domain can issue on behalf of all the others. To know when that lack forces a neutral substrate, you have to separate two kinds of record that get blurred together, because they have completely different requirements.

The first kind is evidentiary. It records that something was claimed: this principal authorized this scope, at this time, and here is a signature proving the claim is genuine and untampered. An evidentiary record answers "what was asserted, and by whom." The second kind is operative. The record is not describing an authority decision that happened elsewhere; the record is the decision, and accepting it means state changes and value moves. An operative record answers "what is true now, and what moves as a result."

This distinction is the hinge of the whole article. Signed claims solve portable facts. Neutral shared state solves contested state transitions. For an evidentiary record, the keeper problem is mild, because a signature travels on its own and a counterparty can verify it without trusting whoever is storing it. For an operative record, the keeper problem is severe, because the question is no longer "can I verify this claim" but "when two parties disagree about the current state and value is on the line, whose version settles, and who is allowed to write the next entry." The keeper problem only becomes load-bearing when the record is not merely evidentiary but economically operative. Everything that follows is an attempt to locate that condition precisely and refuse it everywhere else.

Four ways to keep the record

There are four real answers to "who keeps the record," and the entire decision lives in choosing among them honestly. None is a default. Each wins somewhere and fails somewhere, and the failures are the interesting part.

Operator-owned systems and enterprise audit. One party keeps the record and the others accept it. This is the right answer far more often than crypto discourse admits, because it is the cheapest, the most private, the most performant, and the simplest to govern. It works whenever there is a party the others are content to trust as the authority: a regulator, a dominant platform, a clearing entity, or simply the organization that owns the whole process. It fails the keeper test by construction the moment no such party exists. If the record's neutrality is the point, the entity that owns the record is the conflict of interest, and no amount of logging fixes that.

Signed attestations. Verifiable credentials (the W3C VC 2.0 model), decentralized identifiers, and attestation services such as EAS let one party issue a signed, checkable claim that another party can verify without the issuer present and without trusting whoever stored it. These are mature standards, and they are the correct tool for portable facts across organizations: this credential was issued by that authority, it has not been revoked according to a status list, and it has not been altered. What they do not provide is shared state or settlement. An attestation tells you what was claimed; it does not adjudicate a disagreement about the current state of the world, and it does not move value. It is keeper-neutral for facts and silent on contested transitions. For a large fraction of cross-organizational agent problems, that is exactly enough, and reaching past it is over-engineering.

Consortium and TEE-backed shared systems. When a known, bounded set of parties needs genuine shared state and can agree on a governance model, a consortium ledger is the strongest non-chain answer there is. Frameworks built for exactly this, such as Microsoft's Confidential Consortium Framework and permissioned designs in the Hyperledger Fabric lineage, run shared, auditable state among mutually distrusting members, with the membership and the change process defined by the consortium rather than by any single member, and with confidential-computing hardware narrowing what each member has to trust. This is the option most often skipped in the rush to a public chain, and it is frequently the right one. It wins decisively on privacy, latency, throughput, and governance clarity. Its limits are specific: it needs a knowable membership, it needs the members to actually agree on governance, and its trust assumptions are narrowed but not erased. A trusted execution environment moves trust from the operator to the hardware vendor and the attestation chain; it does not remove it, and the steady drip of attestation and memory-integrity attacks against production TEEs is a reminder that "use an enclave" is sometimes right and never trust-free.

A public or neutral chain. Here the keeper is no one in particular. State transitions are proposed and resolved by an open protocol rather than by a privileged writer, value is native to the same substrate as the record, and the whole thing is verifiable by parties who were never introduced. This is the only option that holds when membership is open or weakly trusted, when neutrality has to be public rather than agreed, and when the record must move value without handing settlement to anyone. It pays for those properties, and the price is real: weaker privacy, higher latency, higher cost, operational complexity, key-custody risk, and failure modes that are irreversible by design. A neutral chain is not a better consortium. It is a different trade, justified only when the consortium's prerequisites — known membership and agreed governance — cannot be met.

The shape of the decision is now visible. Each step down this list buys keeper-neutrality and pays for it in privacy, performance, and simplicity. You move down only when the step above genuinely cannot keep the record, and most of the time it can.

What is actually shipping, and what its trust model assumes

The argument so far is architectural, but it has to touch ground, because the reason this question is live now is that the asset-layer and machine-payment primitives have matured enough to be tempting. The discipline is to read each one for its trust model, not its momentum.

On the asset side, programmable accounts are real and improving. Account abstraction under ERC-4337 lets a smart account carry its own validation logic, sponsor execution, and grant bounded, time-limited delegated authority enforced where value moves. Session keys and delegation modules give an account a way to hand an agent a narrow, revocable right to act. Newer work pushes this further: EIP-7702 brings delegation behavior to ordinary externally owned accounts, and modular-account standards in the ERC-7579 line aim to make permission and delegate modules interoperable across wallets. This is the most interesting material in the whole subject for agentic finance, because it is the one place where a piece of the mandate — the spend field — starts to exist as something enforced at the asset layer rather than promised in a policy engine. It is also not solved. The delegation is often wallet-specific, the permission and module standards are still settling, secure delegate design is genuinely hard, and an over-broad delegate can hand away more than anyone intended. EIP-7702 makes the point twice over: it puts real delegation within reach and, by its own security guidance, makes a badly drawn delegate able to surrender an entire account. Real primitives, uneven ground.

On the payment side, a set of agent-commerce rails has appeared, aimed at letting software agents pay and get paid: Google's Agent Payments Protocol, which is payment-agnostic and rides mostly on existing card and processor rails, and x402, which settles directly in stablecoins on-chain, among a growing number of platform offerings. The right question about each is not whether it exists but what it assumes. Most of them assume a trusted processor in the middle: the agent transacts, but a platform or a card network or a payment provider is the keeper of record and the settler. That is a perfectly good design, and it is not neutral settlement. It is a payment API with an agent-shaped front end, and it lives in the operator-owned row of the comparison, not the neutral-chain row. A smaller set, x402 among them, genuinely settles on a shared substrate, usually in regulated stablecoins, and only that subset is doing the thing a public chain is uniquely for. Conflating the two — treating "agents can pay" as if it implied decentralized settlement — is the single most common error in this area, and it is worth refusing explicitly. The maturity map, honestly drawn, has three tiers, and keeping them apart is most of the discipline. Shipping: account abstraction and regulated stablecoin settlement run in production today, with the standing caveats of uneven cross-wallet interoperability and real key-custody risk. Deployable but fragmented: scoped delegation, session keys, and permission modules work, but wallet by wallet, without settled standards, and with secure delegate design still a sharp edge. Still emerging: neutral, standardized agent-to-agent settlement at scale, which is closer to demonstrated than to deployed. None of it is finished, and the argument does not need it to be.

Scenario to verdict

This is the operational heart of the article, and the only way to keep it honest is to run real scenarios and let most of them come back negative. Every verdict below turns on the same two questions: is the record merely evidentiary or economically operative, and can any party be the accepted keeper. Where the record is evidentiary, or where a keeper everyone tolerates exists, a cheaper layer wins. Only where the record is operative and no keeper does the substrate have to change. The scenarios are not eight separate judgments; they are one rule applied eight times.

An internal copilot drafting and acting inside one company needs none of this. The default is ordinary identity and audit, the keeper is the company, and a chain would add latency, key friction, and public exposure for nothing. Verdict: no material value.

An intra-domain orchestrator coordinating tools inside one trust domain is the same answer with more moving parts. The conventional stack keeps the record because there is one domain and one keeper, and that is fine. Verdict: rarely material; the strongest rebuttal to any Web3 proposal here is that nobody has named a party who should not be trusted to keep the log.

A cross-enterprise workflow under a known consortium is where it gets interesting and still usually resolves below a public chain. The parties are mutually distrusting, so operator-owned audit fails, but the membership is knowable and the governance is agreeable, which is exactly the consortium's home ground. A consortium ledger gives auditable shared state without public-chain cost and privacy exposure. Verdict: sometimes material, but the function a chain would serve is "public neutrality," and you only need that if membership is actually open or the parties cannot agree governance. If they can, the consortium wins.

Cross-organizational attestations and portable claims almost never need a chain. The work is evidentiary: prove a claim's issuer and integrity to a party who was not there. Signed credentials already do that and travel on their own. The only thing a neutral substrate adds is neutral ordering or timestamping, and that matters only when the sequence of claims is itself contested and composable across parties. Verdict: rarely material; signed claims solve portable facts, and most portable-claim problems are nothing but portable facts.

Agentic commerce with delegated spend through a trusted processor splits cleanly into two layers. Settlement runs fine through the processor, which is the keeper both sides already accept, so the neutral-substrate case for settlement is weak. The interesting part is enforcement: a smart-account session key can bound the agent's spend at the asset layer, which a policy engine can only promise. Verdict: sometimes material, but only for the enforcement layer, and only if you do not trust the processor's own policy controls to hold the bound. If you trust the processor, you trust the processor.

Agentic commerce with delegated spend plus escrow among mutually distrusting parties is the cleanest yes in the whole list. Neither side accepts a central settlement operator, the value transfer is conditional on terms both must verify, and the record of who is owed what is operative rather than evidentiary. Smart-account mandates plus atomic, conditional on-chain settlement do something no escrow provider can when the parties refuse to share one. Verdict: yes, material, with the standing caveat that smart-account delegation is still fragmented and security-critical, so the win is real and the implementation is not free.

A public or multi-market machine principal that transacts across open markets with no shared operator is the other clear yes. There is no party who keeps the record for all the markets, identity has to be portable and self-custodied, and enforcement and settlement have to ride the same neutral substrate as the authority. Verdict: material, for portable wallet identity, asset-layer enforcement, and native settlement, paid for in key-custody and privacy risk and the irreversibility of mistakes.

Internal audit and accountability is the misuse magnet, so it goes last to make the point. Enterprise tracing, workflow history, and SIEM are better operational tools than any ledger for understanding what your own systems did. Putting this on a chain buys nothing and costs throughput, privacy, and sanity. Verdict: almost never material.

Count the verdicts. Two clean yeses, two sometimes, four no or rarely, and the two yeses share a single signature: authority, value transfer, and settlement have fused into one operative record among parties who have no keeper in common.

Where teams reach for a chain and should not

The misuse cases are worth naming sharply, because they are common and they all share a tell. A team puts internal audit on a chain because immutability sounds like assurance, when an append-only internal log was the actual requirement. A team builds a portable-claims system on shared state when signed attestations would have traveled further for a fraction of the cost. A team stands up a public chain for a four-party workflow whose membership and governance were knowable from day one, where a consortium ledger was the obvious fit. A team routes payments through a chain because the flow involves an agent, when a trusted processor was acceptable to everyone and faster. In every case the chain was introduced to signal seriousness rather than to solve a keeper problem, and the tell is always the same. Name the party who must not be trusted to keep the record. If you cannot, you do not have a keeper problem, and the neutral substrate is decoration, not infrastructure.

The narrow case that survives

Strip away everything that a cheaper layer handles and a small, hard residue remains. Web3 rails become materially useful when the record must be accepted by parties who are mutually distrusting, when no single operator should own the shared state, when authority has to be enforced at the asset layer rather than promised in a policy engine, and when settlement is not separable from the authority record. Those conditions are not independent. They tend to arrive together, in exactly one place: the economic actor that moves value across a boundary no participant is trusted to hold.

That is the whole claim, and its narrowness is the point. The narrow honest case for Web3 is not "agents need blockchain." It is that some economic actors need neutral settlement and asset-layer enforcement where no operator can be the accepted keeper. Said the other way, signed claims solve portable facts and neutral shared state solves contested state transitions, and only the second of those is what a chain is uniquely for. The reason the cycle could not answer this question early is that you cannot see how small the residue is until you have ruled out the operator-owned, the attested, and the consortium answers one at a time, on their merits.

So the cycle closes where it was always going to, if it stayed honest. The primary user layer is shifting to agents. The thing those agents lack is not intelligence but portable, governable authority. Only one class of agent strains the conventional stack, and that class needs an operational record of its authority that holds between organizations. For most of those records, an existing layer keeps them well. For the smallest and hardest fraction — the actors that must move value across a line no one is trusted to hold — there is no accepted keeper, and a neutral substrate stops being ideology and becomes the only structure that fits. Web3 is not the substrate of the agent economy. It is the settlement layer of its narrowest, sharpest edge, and naming that edge precisely is worth more than any claim that it is the whole map.