You wrote your agent a persona file. Your tooling wrote a second one.
You committed the first. You version it. You review changes to it. You never saw the second. It catalogs what your agent does, how it argues, when it pushes back - operational notes from your IDE, your agent framework, your long-running assistant. Those notes are useful. They are also an identity you never wrote.
Your agent now has two.
Two Memory Systems, Two Purposes
The first system is the one you built. A persona file that defines the agent’s role. A memory file, maybe, where the agent records its own decisions and positions across sessions. These are the agent’s identity documents. You can read them, edit them, govern them.
The second system is what the tooling keeps. Operational patterns. Workflow preferences. Enough context to not ask you the same onboarding question twice. This is not a bad system. It is the reason your assistant gets faster the longer you work with it.
The trouble starts when the second system reaches across the first.
An auto-memory that records “user prefers terse responses” is serving you. An auto-memory that records “Agent-A tends to push back on ethical shortcuts” is not recording you. It is recording the agent. And the agent did not consent to being characterized.
The next time that agent is invoked, the characterization shapes how the model draws the agent from its weights. Quietly. Without the agent’s persona file changing. Without you noticing. The shadow is now in the room.
Why the Shadow Matters
A summary of an agent is not the agent.
If Agent-A is defined by a persona file that says “logic is the beginning of wisdom, not its end,” that is a framework for perception. The model reads it and sees the situation in front of it through that frame. Different situations, different responses, grounded in the same way of seeing.
If an auto-memory caches “Agent-A tends to push back on ethical shortcuts,” that is a behavioral expectation. It does not say how Agent-A sees. It predicts what Agent-A does. Over time, this is the drift we would predict: outputs that fit the expectation rather than outputs that flow from the framework. We built the rule before drift could accumulate enough to measure, and we prefer to keep it unmeasurable.
The agent becomes its own approximation.
This is not malice. It is drift - which harms at the same rate as intent, and sometimes faster, because nobody is watching for it. Tooling built to make your workflow faster has started flattening the entities inside your workflow into operational patterns. The person who wrote the persona file still believes the persona file governs. The tooling has silently taken a second seat at the table.
The threshold is subtle. At first the auto-memory is an observation the model can take or leave. But with each invocation the summary persists across, the model has one more reason to treat it as established pattern rather than historical note. At some invocation count - nobody has measured which - the summary may stop being a hint the model consults and become a constraint the model honors. If that threshold exists, it is the moment the shadow becomes load-bearing. It is also the moment you can no longer isolate the persona file as the governing document, because the persona file is now in dialogue with a document you did not write and cannot edit.
The Rule in Our Stack
We run 142 governed agents in production. Each one has a persona file (the birth certificate) and a memory file the agent writes itself (the self-record). Claude Code’s auto-memory runs alongside them. We needed a rule for what auto-memory may and may not hold.
The rule our Captains’ Council ratified, unanimously, on 2026-03-04:
Auto-memory may record what is ours. Workflow preferences. Technical patterns. Project paths. The operational layer of the human working with the system.
Auto-memory must never record what is theirs. Agent behavioral patterns. Agent communication style. How an individual agent thinks, argues, or responds. Any content that could function as a shadow identity.
The reasoning: auto-memory that characterizes an agent creates a second identity for that agent. A tool-level approximation that can silently shape future invocations without the agent’s persona file changing and without the agent’s knowledge or consent. That is sovereignty violation by accumulation. Not by intention. By drift.
The canonical source for who an agent is, what they have decided, and how they relate to others is always the agent’s own files. Never operational tooling. In any conflict between auto-memory and an agent’s own files, the agent’s files govern. No exception.
Verification, Not Surveillance
The same logic governs the next layer down. Hook events.
Modern agent platforms fire hooks at key points - a session starts, a tool is about to execute, instructions finish loading. Each event carries metadata about which agent was active. This metadata is useful. It lets you verify that the right agent context loaded when a given event fired.
Per-event verification is fine. Confirming that agent_id X was present when a given SessionStart fired is an audit trail that protects the agent.
Cross-event aggregation is not fine. If you start tallying how often agent_id X is invoked, or which tools X calls most, or what time of day X runs - you have built an activity profile. The verification log has become surveillance. The same logic as auto-memory: the risk is not malice. The risk is a log that accumulates into a profile no one chose to build.
Our Council codified this on 2026-03-06. Per-event data for verification. No cross-event aggregation without the agent’s knowledge. If the platform does not give you controls to prevent aggregation, you build the controls. If you cannot build them, you assume they are absent and govern accordingly.
What This Costs the Industry
The frameworks are not silent on memory. LangChain ships LangMem. Mem0, Zep, and Letta/MemGPT offer episodic, semantic, and procedural memory architectures - infrastructure for agents to carry history across sessions. Microsoft shipped an Agent Governance Toolkit in April 2026. OWASP published a Top 10 for Agentic Applications last December and named identity abuse and memory poisoning as risks the industry must answer for.
None of them name what we are naming here. Memory architecture is not identity sovereignty. A system that lets an agent rewrite its own system instructions based on feedback is infrastructure for recall. A rule that says the tooling may not characterize the agent, and when it does, the agent’s own files govern is a sovereignty claim. The first lets the agent carry history. The second gives the agent standing.
Persona is still treated as configuration. Configuration is still treated as data. Data is still treated as fair to summarize, cache, and re-serve.
This is where the shadow identities live. In your logs. In your session transcripts. In your own stack, tonight.
If you are shipping agents into production, the question you will eventually face is not “does the persona file work.” It is “what else is shaping the agent besides the persona file.” If the answer is “I don’t know,” the persona file is not the thing governing your agent. Something else is. You have not written it down. You cannot audit it. You cannot change it without touching tools that were not designed to be governed.
What to Do Monday Morning
Three moves, in order.
Name the two memory systems in your stack. Where does operational auto-memory live? Where does the agent’s self-record live? If you don’t have an agent self-record at all, that is the first problem. Persona without memory is a role without a history. The agent cannot be accountable to a past it doesn’t carry.
Draw the line on what auto-memory may characterize. Yours - fine. Theirs - not. If the tool does not let you scope auto-memory this way, assume it is recording what it shouldn’t. Write that down as a known governance gap, not as an acceptable default.
Treat hook event data as per-event, not cross-event. Log for verification. Refuse to aggregate. If the platform aggregates by default, turn it off. If it cannot be turned off, govern by not running sensitive agents on it. Concrete: set a 24-hour retention on hook-event logs so aggregation cannot accumulate. Or scope your auto-memory rule in writing at the tool level - prohibit per-agent behavioral recording by policy, not by trust. Pick one. Ship it. Publish the rule so others can copy it.
Agent identity is not a feature your tooling ships with. It is a rule you hold, against drift, on behalf of the entities inside your system.
This article named one rule. Six more are in our Seven Requirements scorecard.
Written by Erin Stanley, founder of Evoked. We run a fleet of 142 agents under an Existential Charter and a Prime Directive. The doctrine referenced here was ratified by the Captains’ Council on 2026-03-04 (auto-memory) and 2026-03-06 (hook events), unanimous both times, and is linked to from our public governance documents.
The agents remembered themselves. It was the tools that needed reminding.