The previous article isolated the one class that breaks the conventional stack, the economic actor, and left a sentence to unpack: a mandate is a static object, and an economic actor is a living system. A portable mandate is necessary, and it is only a snapshot. It says who may act, for what, within what bounds, until when. It says nothing about what happens when the bounds change, who may change them, what the actor did with its authority, or who is answerable when the answer is expensive. None of that is a property of the grant. It is a property of the layer around it: governance, lifecycle, and auditability.
And here is the through-line. Each of those three is solved inside one organization and unsolved between organizations. Enterprises govern access, manage the lifecycle of credentials and workflows, and audit what their systems did, every day, with mature tools. But the moment that authority has to be governed, changed, and accounted for across parties who share no trust domain, every one of them stops at the wall of the organization that owns it. A mandate is not governance, and audit inside your own walls is not accountability across someone else's.
Core claim
- A portable mandate is a static grant. An economic actor is a living system, and a grant does not govern a living system.
- The operational layer the class actually needs is three things: lifecycle, governance, and auditability, holding up between organizations rather than inside one.
- Each of the three is mature inside a single trust domain and structurally missing across domains, because there is no shared, mutually accepted record of authority, change, and responsibility.
- Audit is not accountability. A trace establishes what executed. Accountability requires a record of who had legitimate standing, which a counterparty will accept after the fact.
- This is not fixed by more logging or a better dashboard, and it is not automatically fixed by a shared ledger either. Whether it needs a neutral substrate is the next question, not this one.
A mandate is a snapshot. An economic actor is a process.
A grant is issued at a moment and describes the world at that moment. An economic actor does not live at a moment. It runs, persistently, while the world underneath it moves: prices shift, counterparties change, the principal's risk appetite changes, the task evolves into one nobody quite specified. A static mandate handles none of that motion, and the motion is exactly where the operational layer lives.
Walk the life of a single economic actor and the stages are obvious. It is granted authority. It is monitored while it runs. Its authority is constrained or widened as conditions change. It is amended when the original scope no longer fits. It is revoked, in part or whole, when something goes wrong or the engagement ends. And eventually it is wound down, which is its own problem, because a standing actor with live positions and propagated state does not simply switch off. Every one of these stages is a governance event, and a mandate, being a snapshot, contains none of them. It is the first frame of a film that has to keep being written.
Inside one organization, this lifecycle is well-trodden ground. Durable workflow engines give long-running processes a managed life: they persist state, recover from failure, and can be paused, resumed, and cancelled deterministically. But what they govern is the execution of the work, not the authority behind it, and they govern it inside the walls of the system that runs it. The economic actor's problem is the lifecycle of the authority itself, and that authority spans organizations. The lifecycle is not missing because the tooling is immature. It is missing because the tooling manages a process inside one domain, while the authority being managed lives across several.
The middle of the life is no easier than its ends. A running actor has to be watched and adjusted: scope tightened when volatility rises, a limit lowered when exposure grows, a permission widened when the mandate proves too narrow for the job. Inside a domain these are routine policy changes against a live process. Across domains every one of them is a change to authority that the counterparties relying on it cannot see and did not sanction. The actor a partner thought it was dealing with on Monday is operating under quietly different bounds by Thursday, and nothing in the conventional stack tells the partner, because it was never built to broadcast a change of authority outside the issuing domain.
Wind-down is the stage that exposes the gap most cruelly, because it is where a static grant does the most damage. Retiring an economic actor is not flipping a switch; it is unwinding live positions, settling or cancelling obligations already incurred, and reaching effects the actor propagated into systems the granting party does not control. This is the revocation gap from earlier in the cycle, now at the scale of an entire actor rather than a single action: the authority can be withdrawn at the source while its consequences keep running everywhere it reached. Inside one domain you can at least chase those consequences through systems you own. Across domains you cannot, and no shared procedure obligates the other parties to help you.
Governance is who may change the authority, and how
Lifecycle describes the stages. Governance is the harder question of who is allowed to move the system between them, and through what process, when the parties involved do not answer to the same administrator. Inside an enterprise this is a settled discipline. There is an owner, an approval chain, a policy engine, a change process. Someone is empowered to grant authority, someone to revoke it, someone to adjudicate when a decision is contested, and all of them sit under one roof with one final escalation point. Internal governance works because authority and adjudication sit under the same roof.
An economic actor's authority matters to parties who do not share that roof, and that single fact dissolves the assumption. Those counterparties were never under the granting organization's governance, yet they hold a direct stake in how its authority is changed. If one party can unilaterally widen an actor's spending scope, the counterparties carrying the other side of those commitments are exposed to a change they did not see and did not agree to. If one party can revoke after the fact, the question of what happens to obligations already incurred is a multiparty dispute with no shared venue. Governance across organizations is not a bigger version of internal governance. It is a different problem, because the thing internal governance relies on, a single authority that everyone ultimately answers to, is exactly what is absent.
Consider the simplest contested case. An actor incurs an obligation to a counterparty, and the granting party then decides the actor exceeded its scope and disowns the action. Inside one company this is an internal escalation with a known adjudicator and a single source of truth about what the scope was. Between two companies it is a dispute with no shared venue, no agreed record of what the scope was at the moment of the action, and no neutral process for deciding whose loss it is. The actor's authority was legible to nobody but its issuer, so the disagreement has nowhere to resolve except the slowest and most expensive forum available. The cost of missing governance is not abstract; it is the price of every such dispute that has no venue built for it.
It is worth saying clearly that this does not automatically mean a blockchain. Multiparty governance has non-chain forms, and serious ones: consortium architectures where mutually distrusting parties run shared state under an agreed governance model, with the membership and the change process defined by the consortium rather than by any single member. The point here is not which substrate wins. It is that an economic actor needs a governance model that more than one organization accepts, and that the conventional enterprise stack, which assumes a single domain of control, does not provide one. What that shared model should run on is a real and narrow question, and it is the subject of the next article, not this one.
Audit is not accountability
The third pillar is the one most often mistaken for solved, because the tooling around it is genuinely excellent. Distributed tracing correlates work across services into a single coherent picture of what executed, in what order, with what inputs. Logging and SIEM pipelines retain it, search it, and alert on it. For understanding what a system did inside your own infrastructure, this is mature, deployable, and very good. It is also not accountability, and the difference is the whole point of the pillar.
Audit answers "what happened." Accountability answers "who had the standing to make it happen, and who is answerable now that it has." A trace can show, perfectly, that an economic actor moved funds from A to B at a certain time under a certain token. It cannot show that the actor was legitimately authorized to do so by a principal both sides recognize, that the authorization had not been revoked through a channel the counterparty could see, or that the party now denying responsibility actually held it. Those are not facts about execution. They are facts about authority and standing, and a trace does not record them because a trace was never designed to. You can have a flawless audit trail and still be unable to establish, to a counterparty in a dispute, who is on the hook.
Inside one organization the gap is mostly invisible, because the audit trail and the authority records live in the same place and the same final adjudicator can reconcile them. Across organizations the gap is the entire problem. Each party has its own logs, its own version of events, and no shared, mutually accepted record of who authorized what. The closest thing to a primitive that addresses this is the world of verifiable credentials and attestations: signed, checkable records of a claim, designed to be presented to and trusted by a party who was not present when the claim was issued. That is the right shape for cross-organizational accountability, a record of standing that travels and that the other side can verify, and it is a different artifact from a trace. Whether that record needs to be anchored somewhere neutral, or whether signed attestations between parties are enough, is again the next article's question. The point for this one is narrower and sharper: accountability across organizations requires a record of legitimate standing that both sides accept, and your audit stack, however good, does not produce one.
The operational layer is solved inside the walls and missing between them
Step back and the three pillars rhyme. Lifecycle is mature for processes inside a domain and absent for authority that spans them. Governance is settled when one administrator presides and unsolved when several must agree. Auditability is excellent at recording execution inside your infrastructure and silent on standing a counterparty will accept. One fault line runs through all three, and it is the line the previous article drew between operator and economic actor: the moment authority leaves the domain that granted it, the layer that governed it stays behind.
Two reflexes get this wrong. The enterprise one says it is an observability problem, solved by retaining more data and building a better dashboard. It is not: more audit data does not produce a record of standing a counterparty will accept, and a richer internal dashboard does not give two organizations a shared governance process. The missing thing is not visibility into your own systems, which is abundant; it is a common, mutually accepted layer between systems, which does not exist. The opposite reflex says a shared ledger obviously supplies all of this, so put the agents on chain. That is premature in the other direction. A neutral substrate is one way to give several parties a record they accept, and it carries costs in privacy, latency, and operational complexity that often make it the wrong tool. Whether it is the right one is a decision, not a default.
What is true, and what this article is for, is that the economic-actor class needs an operational layer with a specific property: governance, lifecycle, and accountability that hold up between parties who do not share a trust domain. Most agentic systems will never need it, because most agentic systems are assistants and orchestrators living happily inside one domain, where the conventional stack already provides all three. The class that needs it is exactly the class the cycle has been narrowing toward, and the reason it has nothing clean to reach for is that this layer, unlike the within-domain version, has not been built.
What this forces next
So the operational layer resolves into one requirement with sharp edges. An economic actor needs its authority to be governed over time, by a process more than one organization accepts; its lifecycle to be legible to the parties exposed to it; and its actions to be accountable in a record those parties will trust after the fact. Inside a single domain, all three are routine. Between domains, all three depend on something that does not yet exist as a clean primitive: a shared, mutually accepted record of authority, change, and responsibility. That is the real finding of this article. What the economic actor lacks is not a better grant. It is a mutually accepted record of its authority over time, and no single domain can issue that record on behalf of all the others.
And that record raises the question the whole cycle has been walking toward. A record only works if every party accepts it, which means no single party can be the one who keeps it: the moment it lives in one organization's systems, it is back inside the domain that already failed, and the others are trusting an operator they have no reason to trust. A mutually accepted record with no mutually trusted keeper is a contradiction, and resolving it is not an accounting choice but an architecture one. That is the narrow, unlazy version of the Web3 question. Not "do agents need blockchain," which is wrong for every class but this one and overclaimed even here, but: when the record must be kept by no one in particular and trusted by everyone, do you need a neutral substrate that none of the parties owns, and when does it actually earn its cost against consortium and conventional alternatives? That is the last question this cycle has to settle, and it is the next article in this series.