The agent economy is being built from the outside in
There is a genuine infrastructure buildout happening around autonomous agents, and it is worth being specific about what it currently contains. MIT Sloan’s survey of the emerging agent economy, drawing on work from the MIT Media Lab, describes a market forming around agent identity and discovery, dispute resolution and repair services for agents that fail, and micropayment rails for transactions between them. The framing shift it identifies is the useful part: the move from “let us build agents for X” to “let us build X for agents.”
The forecasts attached to this, billions or trillions of agents, are projections rather than observations, and nothing below depends on them being right. The argument holds at a thousand agents inside one company.
What is notable about the emerging stack is not what it contains. It is what it assumes.
Three questions the current stack answers
Take the infrastructure categories that already have credible products and standards behind them, and reduce each to the question it answers about an agent.
Identity answers: who is this agent, and on whose behalf does it act? Authorization answers: is this agent permitted to call that tool, touch that repository, spend that budget? Observability answers: what did it actually do, and can we reconstruct the sequence afterwards?
These are real problems and the work on them is serious. Together they give an organization an agent that is known, scoped, and auditable.
None of the three answers the question that determines whether the agent’s work is any good.
An agent can be correctly identified, fully authorized, and completely observable, and still produce a change that contradicts a decision the organization made two years ago and still relies on.
Permission is not correctness
Authorization is a statement about capability: this agent may write to this repository. It is not a statement about the content of what gets written.
Consider an agent with entirely legitimate write access to a payments service. It is authorized. Every action it takes will be logged. Its identity is attested. It adds a feature that reaches around the service boundary and queries another domain’s database directly, because that was the shortest path to a working implementation.
Nothing in the identity layer objected, because the agent was who it claimed to be. Nothing in the authorization layer objected, because the agent was permitted to modify those files. Observability recorded the change faithfully, which is how somebody will eventually find it. The decision that was violated, that this domain does not reach into that one, was real, deliberate, and load-bearing. It simply was not represented anywhere the agent’s action passed through.
This is the gap. Permission systems govern reach. They do not govern compatibility with prior decisions, and the second is where most of the organizational risk in autonomous software work actually lives.
The missing primitive is decision authority
Add a fourth row to the stack and the omission becomes obvious.
| Layer | Question it answers | Timing |
|---|---|---|
| Identity | Who is this agent? | Before |
| Authorization | Is it permitted to act at all? | Before |
| Observability | What did it do? | After |
| Decision layer | Is what it is about to do consistent with what this organization already decided? | Before |
The first two rows are about the actor. The third is about the record. Only the fourth is about the content of the proposed change, evaluated against commitments the organization made earlier and has not withdrawn.
Note the timing column. Observability is the only layer in the current stack whose answer arrives after the fact, and it is the only one that speaks to what was actually built. That is an uncomfortable arrangement. It means the stack’s substantive judgement about work quality is, by construction, retrospective.
Why this cannot live inside the agent
The intuitive response is to put the decisions in the agent: system prompts, instruction files, a project memory, a fine-tune. This fails for a structural reason rather than a quality-of-implementation reason.
Everything inside the agent is mutable by the agent’s operator, and increasingly by the agent. Models are swapped. Harnesses are rewritten. Instruction files are edited by the same automated workflows they are meant to constrain. Context is compacted, and compaction drops whatever the summarizer judged least relevant to the immediate task, which is frequently the constraint rather than the task.
A constraint that lives in the thing being constrained is not a constraint. It is a default. Defaults are useful and they are not the same as guarantees, which is why we keep returning to the distinction between an agent recalling a decision and being bound by it.
For the decision layer to mean anything it has to be external to the agent, durable across model and harness changes, and evaluated at a point the agent does not control. That is an architectural requirement, and it is the same requirement that makes architectural governance a separate layer rather than an agent feature.
What a decision layer actually has to do
Four things, in order.
Represent a decision in a form that survives being read by a machine: what was decided, why, what it applies to, what it replaced, and whether it is still in force. Resolve which decisions apply to a specific proposed action, because a decision that applies to everything gets enforced nowhere. Evaluate the proposed action against the applicable subset, deterministically, so that the same change against the same decision set produces the same verdict every time. Record the verdict, so the organization can demonstrate afterwards what was checked and what was permitted.
The determinism in the third step is not a stylistic preference. A governance layer that asks a model whether a change is acceptable has reintroduced the variance it was deployed to remove. Some decisions genuinely require human judgement and cannot be compiled into a mechanical check. Those should be labelled as guidance and left to review rather than dressed up as enforcement.
Software engineering is the proving ground
Of all the domains where agents are being given autonomy, software engineering is the one where this layer can be built first, for three reasons.
The decisions are unusually well-formed. Architecture decision records already encode a decision, its rationale, and its consequences, which is most of the representation problem solved by convention rather than by new tooling. The actions are inspectable: a proposed code change can be parsed and reasoned about mechanically in a way that a proposed business action usually cannot. And the verdict has somewhere to land, because the change has to pass through a commit, a review, or a pipeline before it becomes real.
That combination does not exist yet in most other agent domains. It means the software case is not a narrow corner of the agent economy. It is the place where the decision layer gets specified, tested against real systems, and shown to work before anyone attempts it for procurement, finance, or operations.
Where we sit
Mneme HQ implements this for one class of decision: architectural decisions in a codebase. It compiles the ones that can be expressed mechanically into constraints, enforces them deterministically against proposed changes, and keeps the result. The scope is deliberately narrow and it is shipped and runnable today.
The broader claim in this piece, that autonomous systems across an organization will need an independent source of decision authority, is a thesis about direction rather than a description of what we have built. We think the architecture generalizes. We have not demonstrated that it does, and it would be premature to say otherwise.
What we would push back on is the assumption that identity, permissions, and traces are sufficient. They give an organization an agent it can name, contain, and audit. They do not give it an agent whose work is consistent with what the organization already decided. That is a different question, it is answered before the action rather than after, and at the moment very little in the emerging stack is built to answer it.