Agent permissions ride on agent memory

Your multi-agent roadmap has two hard problems on it. One is memory: getting your AI agents to remember what happened three steps ago, after the work has bounced across four different machines. The other is permission: making sure an agent only does what the person who set it loose is actually cleared to do. Most plans treat these as separate tracks. Two teams, two roadmaps, integrate at the end.

That plan has a bug in it, and the bug is the word “separate.”

First, the world these agents live in, because it moved fast this year. A modern AI system is often not one model answering one question. It’s a chain. Agent A takes your request, hands part of it to Agent B, which calls Agent C, and the answer comes back assembled from all three. To work at any real scale, that chain needs two hard things. It has to remember what’s been decided, what’s half-done, and what failed, across steps that may run on different servers. Engineers call that state persistence. And it has to carry your permissions the whole way, so Agent C doesn’t quietly do something only you were cleared to do. Call that authorization.

Both are genuinely hard, and both are where multi-agent projects are dying right now. Gartner projects that over 40% of agentic AI projects will be canceled by the end of 2027, and separately that 40% of enterprises will demote or decommission autonomous AI agents by 2027 after governance gaps surface in production [both reported]. So the instinct to staff both problems hard, in parallel, is sound. The instinct to call them independent is where it goes wrong.

Permission is built on top of memory. The identity your system carries from Agent A to Agent C is itself a piece of memory, so a lost credential and a forgotten fact are the same bug underneath.

Walk the chain and you can see it. Authorization in a multi-agent system isn’t one agent checking one password. Single-agent tools already do that fine. The hard part is that the identity, meaning who’s really behind this action and what they’re cleared to do, has to survive the hops from A to B to C. Surviving the hop is exactly what state persistence means. The delegated credential, the calling context, the record of who touched what: those are things the chain has to remember across the same servers, retries, and handoffs that lose everything else when the memory layer is weak.

And a weak memory layer loses things constantly. The failure modes have names: stale data from two agents overwriting each other, half-finished updates, race conditions, and the vivid one, “localized amnesia,” which is what happens when an agent’s memory lives only on the machine it started on and the work moves to a different machine [reported]. If the credential travels through that same leaky layer, it gets dropped the same way everything else does. You can’t hand a permission down a chain that doesn’t reliably remember anything.

This is where the field’s tidy answer breaks. The vendors who actually run agents in production have started saying the order out loud. Letta, a startup building agents designed to remember across sessions, and Augment Code, which runs fleets of coding agents in the cloud, both argue that teams have to solve state persistence first and layer authorization on top [reported]. The setup underneath them is boring and consistent: a fast in-memory store called Redis for what the agent needs this second, and a durable database called PostgreSQL for the record that has to outlast it [verified]. Get that foundation wrong and the permission layer has nothing to stand on.

The case for “separate” is real, and worth stating at its strongest. The symptoms don’t overlap. A race condition on a shared counter is not a permission bug. A miscoped credential is not a stale cache. You can build flawless memory and still hand Agent C a key it should never have held. On the list of things that go wrong, state failures and permission failures are genuinely different entries, and that’s why they get two teams.

But different symptoms is not the same as no order. One camp says design permission in first. The production camp says get memory working first. Those are opposite claims about the same build order, and the only way to call them both correct is to insist neither comes first, which is a third claim rather than a compromise. The mechanism breaks the tie, and it breaks against designing permission first. If the identity you propagate is carried in memory, then memory comes first by construction.

The sharpest evidence is sitting inside the permission-first argument’s own favorite example. The most-cited version, from 2026 research on authorization in agent chains, leans on this: when Agent A calls B calls C, the combined output has “no canonical identity,” so nobody can say who’s accountable for the final result. Read it slowly. The identity was present at every single step and didn’t survive being combined into the final answer. Not surviving is a memory failure. The permission camp has been using a state-persistence bug as its flagship example for a year and filing it under authorization.

Which leaves one question that decides the whole thing, and it’s answerable. In a live A-to-B-to-C chain, is the identity that gets propagated carried in the agent’s remembered state, or in something else, like a fresh token the system re-checks from scratch at every hop? If it rides in the remembered state, memory sits upstream of permission in every deployment, of every size, and “build them in parallel” is wrong for reasons that have nothing to do with scale. If it rides in a separate token that never touches the agent’s memory, then the two really are independent, and “design permission in first” survives.

That’s not a matter of taste or company size. It’s a question about where one specific thing lives, and any team building this can open the code and look. Until someone does, “staff two teams and integrate later” is a quiet bet that the permission team isn’t building on the memory team’s output. If it is, and you scale your agents before the memory layer is solid, the permission failures you hit won’t be permission failures at all. They’ll be the same amnesia wearing an identity mask, and no amount of permission work fixes a key that the memory layer already dropped. The build order decides which team inherits the other’s bugs. Treating it as a scheduling detail is how you inherit them without seeing them coming.