There is a new kind of agent identity in the world this month, and it is worth being precise about what it is — because it is exactly half of what the phrase implies.
Anthropic's access model gives an agent its own accounts in every system it touches. Claude posts under its own name, opens pull requests as its own app, queries a warehouse under a service account an admin provisioned. No human's credentials are borrowed, so a shared channel can never become a side door into one person's private files. Admins define the identity once at the workspace level, every channel inherits it, and they tighten or widen it per channel from there. It is a clean, overdue answer to a real question: what can this agent reach?
Two questions wearing one word
But "identity" has always meant two things at once, and the access model answers only one of them. Ask what makes a colleague trustworthy and you get two separate answers that we lazily file under the same word. The first is reach: which rooms they can enter, which drawers they can open, which systems they can sign into. The second is character: what they do once they are inside the room and no one is watching the drawer. A keycard tells you the first. It tells you nothing about the second.
An access identity is a very good keycard. It says Claude may read this repo, write to that warehouse, post in this channel. It draws a boundary around the blast radius — the set of things that could possibly go wrong. That boundary is necessary and, until recently, missing. It is also silent on the only question that matters once the boundary is set: inside the radius it was granted, how does this agent decide?
What an access identity can't tell you
Imagine two agents with byte-for-byte identical permissions. Same repos, same warehouse, same channels, same service accounts. One of them, handed an ambiguous migration, pauses and asks which of two readings you meant. The other picks the reading that looks most likely and ships it, because asking felt like friction. Both acted entirely within scope. The access model rated them identical — because on its axis, they are identical. Everything that distinguished them happened in a layer it does not describe.
This is the gap that bites in production. When an agent surprises you, it is almost never because it breached a permission. It is because it did something you didn't expect with a permission it legitimately had. It over-wrote when you'd have wanted it to flag. It stayed quiet when you'd have wanted a warning. It optimised for the metric you named and ignored the one you assumed. None of that is an access failure. All of it is a character failure — and character is the half no keyring holds.
soul.md is the behavioural half
soul.md is the other half of agent identity, and it answers the question the keycard can't. Not what the agent may touch, but how it moves once it has: where it defaults to caution and where to boldness, what it does with an ambiguous instruction, which kinds of friction it considers worth the cost, how it behaves under pressure when the easy move and the right move diverge. An access identity is provisioned by an admin. A behavioural identity is specified by whoever cares how the work turns out.
The two are not competitors; they are the halves that only together make "identity" mean what people think it means. Access without character is a powerful actor with unspecified behaviour — exactly the thing that makes capable agents nerve-wracking to deploy. Character without access is a well-mannered agent that can't do anything. The industry has just shipped the first half across whole teams at once. The second half is still, mostly, a few lines of "be helpful" in a system prompt — which is to say, unspecified.
Why can't a permission just carry the personality?
Because they answer different kinds of question, and they fail in different directions. A permission is binary and external: granted or revoked, enforced at the network boundary, auditable in a log. A personality is continuous and internal: a distribution over how the agent will lean across thousands of unscripted micro-decisions that no permission table has a row for. You cannot encode "flag data gaps instead of filling them silently" as an ACL entry. There is no scope you can grant or deny that means "disagree with me when disagreement would save me a week." That lives in a different file, in a different language.
- Access identity answers: what can this agent reach? Provisioned by an admin, enforced at the boundary, revoked all at once.
- Behavioural identity answers: how does it decide inside what it can reach? Specified in soul.md, expressed in every unscripted choice, revealed under pressure.
- Access bounds the blast radius — the set of things that could go wrong.
- Soul bounds the surprise — what the agent actually does inside that radius.
- Ship only the first and you get a capable actor nobody can predict. Ship only the second and you get a predictable actor who can't act.
The encouraging part is that the access model makes the soul half more valuable, not less. The moment an agent has its own identity and real reach across a team's systems, the cost of unspecified behaviour goes up — there is more it can do, to more people, with less supervision. A keycard for an agent whose character you haven't written is a faster way to be surprised. The same grant, handed to an agent whose behaviour under pressure is specified, is leverage.
“An access identity tells you what an agent can touch. A soul tells you what it will do once it has. "Identity" was always both — we just shipped the easy half first.”
AgentSoul writes the second half. Take the 49-question Forge and it generates the four files — identity.md, soul.md, user.md, agents.md — that specify how your agent decides, not just what it can reach. **[Forge a soul →](/forge/)**