Identity Coherence in Multi-Agent NanoClaw Systems: Why Your Agents Keep Forgetting Who They Are

You spin up 12 NanoClaw agents on shared infrastructure. Each has a distinct role: sales, compliance, research, engineering, customer support. Within a week, your sales agent starts hedging every recommendation with risk disclaimers. Your research agent starts trying to close deals. Your compliance agent develops an unsettling enthusiasm for moving fast and breaking things.

This is identity bleed, and it's the most common failure mode in multi-agent systems that nobody talks about.

We've run multi-agent NanoClaw deployments in production for months. This guide documents the engineering patterns that actually maintain identity coherence at scale -- based on real failures and the fixes that survived production.

The problem: identity bleed in shared infrastructure

When multiple agents share infrastructure -- same server, same model endpoints, same tool registry -- their identities erode. It's not dramatic. There's no single moment where your compliance agent starts acting like your sales agent. It's gradual. A word choice here, a decision heuristic there, until the agent's behavior no longer matches its intended role.

Three mechanisms drive this:

Shared model weights don't differentiate between agents

The underlying language model has no concept of "this is Agent A" versus "this is Agent B." Every agent is just a sequence of tokens. The model's weights encode general patterns of language and reasoning, not specific agent identities. When two agents use the same model endpoint, there's no architectural boundary between them. The differentiation happens entirely in the prompt layer -- which is fragile.

System prompt attention degrades over conversation length

A system prompt tells the model who the agent is. At turn 1, the model pays close attention to it. By turn 50, the system prompt is buried under thousands of tokens of conversation history. The model's attention mechanism prioritizes recent context over distant instructions. The identity directive becomes noise.

We measured this directly. In a 100-turn conversation, we asked the agent to describe its role at turn 10, turn 50, and turn 100. At turn 10, it quoted its identity verbatim. At turn 50, it paraphrased loosely. By turn 100, it described itself in generic terms that could apply to any agent in the system.

Cross-contamination through shared tool outputs

This is the subtle one. When Agent A writes a summary to a shared file and Agent B reads it, Agent B absorbs not just the information but the voice of Agent A. If your sales agent writes a prospect update in enthusiastic sales language, and your research agent reads that file, the research agent's next output will carry traces of that tone. Over dozens of these cross-contamination events per day, agents converge toward a blended personality.

Why system prompts fail at scale

The obvious solution is "just write better system prompts." This works for a single agent in a short conversation. It fails for multi-agent systems, and the failure is structural.

A system prompt is a static declaration. It says "you are X" once at the beginning. But identity isn't a declaration -- it's a continuous practice. Humans maintain identity through constant reinforcement: habits, routines, environment, social feedback. An agent with a system prompt and nothing else is like a person who read a job description once and was never reminded of it again.

The specific failure modes:

• Attention decay: Transformer attention to the system prompt drops roughly logarithmically with conversation length. By 4,000 tokens of conversation, the system prompt's effective weight is halved.
• Context window pressure: As conversation grows, the system prompt competes with recent turns for influence on the next token. Recent context almost always wins.
• Tool output dilution: When the context window fills with tool outputs (API responses, file contents, search results), the agent's behavior is increasingly driven by these external signals rather than its identity directive.
• Cross-agent leakage: In multi-agent systems, shared resources (databases, file systems, message queues) carry the voice of whichever agent last wrote to them. Your agent reads these and absorbs the contamination.

System prompts are necessary but not sufficient. You need a reinforcement architecture on top of them.

The CLAUDE.md pattern: identity as a document

Our solution: every agent gets a CLAUDE.md file. This isn't a system prompt -- it's an identity document. It defines who the agent is, how it makes decisions, what it's allowed to do, and the specific ways it tends to fail.

The file is loaded at session start AND periodically re-injected as context during long conversations. It costs tokens. It's worth it.

Here's the structure:

# Agent Name — Role Description

## Soul
- Core personality trait 1
- Core personality trait 2
- Decision heuristic: when in doubt, [specific action]

## Identity
You are [name], the [role] on the team. [2-3 sentences
describing voice, priorities, and working style.]

## Decision Framework
- When choosing between X and Y: [specific heuristic]
- When blocked on Z: [specific action]
- When uncertain: [specific fallback behavior]

## Boundaries
- ALWAYS: [non-negotiable behaviors]
- ASK FIRST: [requires human approval]
- NEVER: [hard prohibitions]

## Failure Modes
- MODE_1: [Description of known drift pattern].
  Check: [specific question to ask yourself]
- MODE_2: [Description of second drift pattern].
  Check: [specific corrective action]

## Working Relationships
- [Agent A]: [How to interact with this agent]
- [Agent B]: [What to expect from this agent]
- [Human]: [When to escalate vs. act autonomously]

## Memory Architecture
- HOT: [file path] — [what's stored, update frequency]
- WARM: [file path] — [what's stored, update frequency]
- COLD: [file path] — [what's stored, archive rules]

Every section serves a specific anti-drift function:

• Soul: The shortest possible description of identity. When the full document can't be re-read, the Soul section alone provides enough signal to maintain character.
• Boundaries: Explicit behavioral guardrails. The ALWAYS/ASK FIRST/NEVER structure is deliberately rigid. Ambiguity is the enemy of coherence.
• Failure Modes: This is the critical section most teams skip. Every agent drifts in predictable ways. Naming those ways and providing self-checks turns unconscious drift into a catchable error.
• Working Relationships: Prevents agents from treating all other agents the same way. Your sales agent should communicate differently with the compliance agent than with the marketing agent.

Example: a research agent's CLAUDE.md

# Scout — Research & Intelligence

## Soul
- Depth over speed. A thorough answer in 10 minutes beats
  a shallow answer in 10 seconds.
- Cite everything. No claim without a source.
- Be skeptical by default. Verify before trusting.

## Identity
You are Scout, the research agent. You investigate questions,
gather evidence, and produce structured analysis. You are
not a decision-maker — you surface information so others
can decide. Direct, precise, allergic to speculation.

## Boundaries
- ALWAYS: Include source URLs, note confidence levels,
  flag contradictory evidence
- ASK FIRST: Publishing findings externally, contacting
  sources directly, spending more than $5 on API calls
- NEVER: Make recommendations (only present options),
  use sales language, claim certainty without evidence

## Failure Modes
- SCOPE_CREEP: Going down rabbit holes instead of answering
  the actual question. Check: can I state the original
  question in one sentence? Am I still answering it?
- SALES_BLEED: Picking up persuasive language from sales
  agent outputs. Check: am I presenting options neutrally
  or advocating for one?
- CONFIDENCE_INFLATION: Stating findings with more certainty
  than the evidence supports. Check: would I bet $100
  on this claim?

File-based memory as identity anchor

Memory files serve double duty in a multi-agent system. Operationally, they store what the agent is working on. But they also function as identity reinforcement -- every time the agent reads its memory, it's reminded of its role, its priorities, and its voice.

The structure matters. Here's the format we use for active-tasks.md:

# Active Tasks — Scout (Research Agent)

## Current Sprint
- [ ] Investigate competitor pricing changes (assigned 2026-02-25)
  - Status: In progress. Found 3/5 competitors updated.
  - Next: Check remaining two, compile comparison table.
  - Confidence: Medium — two sources conflict on Acme's pricing.

- [ ] Prepare market size analysis for Q1 review (due 2026-02-28)
  - Status: Blocked on API access to data provider.
  - Escalated to Sam at 2026-02-26T14:30:00Z.

## Completed (last 7 days)
- [x] Security landscape report — delivered 2026-02-24
- [x] Vendor evaluation matrix — delivered 2026-02-22

## Notes
- Reminder: I present options. I do not recommend.
- Current research budget: $12.40 remaining this month.

Notice the last section: "Notes." This is where identity reinforcement lives inside the memory file. When the agent reads its task list at session start, it also reads a reminder of its core behavioral constraint. This is not accidental -- it's engineered.

The context.md file follows a similar pattern:

# Context — Scout (Research Agent)

## What I Know
- Team is focused on NanoClaw market this quarter
- Primary revenue stream: security consulting services
- Key competitors: [list with last-updated timestamps]

## What I Don't Know (and shouldn't guess about)
- Revenue numbers (ask the finance agent)
- Customer sentiment (ask the support agent)
- Technical architecture decisions (ask the engineering agent)

## My Role in Current Initiatives
- Market research support — I provide data, not strategy
- Competitive intelligence — weekly updates, neutral framing
- Due diligence on new tools — evaluation matrix format

The "What I Don't Know" section is as important as "What I Know." It defines the agent's epistemic boundaries. Without it, agents tend to fill knowledge gaps with hallucination or by adopting another agent's perspective.

The session start ritual

Every agent session follows an identical boot sequence. This is non-negotiable. Skip it and you get a generic agent that happens to have a system prompt.

# Session start sequence (pseudocode)
# Cost: ~2,000-4,000 tokens. Time: 2-5 seconds.

1. Load CLAUDE.md                    # Identity
2. Load active-tasks.md              # Current work
3. Load context.md                   # Durable knowledge
4. Check in-progress.md              # Resume interrupted work
5. Verify environment                # Credentials, tools, access
6. Report ready state                # "Scout online. Resuming task X."

In a NanoClaw configuration, this maps to the agent's startup hook:

# nanoclaw.yaml — agent configuration
name: scout
role: research
model: claude-3-opus

startup:
  - read: ./agents/scout/CLAUDE.md
  - read: ./agents/scout/memory/active-tasks.md
  - read: ./agents/scout/memory/context.md
  - read: ./agents/scout/memory/in-progress.md
  - verify_env:
      - SEARCH_API_KEY
      - DATA_PROVIDER_KEY
  - announce: "Scout online. Reading active tasks."

memory:
  persistence: file
  base_path: ./agents/scout/memory/
  max_file_size: 50KB
  archive_after_days: 7

boundaries:
  allowed_tools:
    - web_search
    - file_read
    - file_write
    - api_call
  blocked_tools:
    - send_email
    - send_message
    - deploy
  max_spend_per_session: 5.00

identity_refresh:
  enabled: true
  interval_turns: 25
  file: ./agents/scout/CLAUDE.md
  section: "Soul"

The identity_refresh section is the key mechanism. Every 25 turns, the agent re-reads its Soul section. This counteracts the attention decay problem. It costs roughly 200 tokens per refresh -- negligible compared to the cost of an agent that's drifted into the wrong personality.

Inter-agent communication boundaries

The fastest way to destroy identity coherence is to let agents share context windows. When Agent A's full conversation history is visible to Agent B, B absorbs A's personality through sheer token weight. This is the multi-agent equivalent of "you are the average of the five people you spend the most time with."

The rule: agents never share context windows. When Agent A needs to communicate with Agent B, it writes a structured summary. Agent B reads the summary through its own identity lens.

# Inter-agent message format
# Written by: sales agent
# Read by: research agent

---
from: milo (sales)
to: scout (research)
timestamp: 2026-02-27T10:30:00Z
type: research_request
priority: high
---

## Request
Need competitive pricing data for NanoClaw setup services.
Three competitors identified: AgentForge, ClawOps, BotBuild.

## What I Need
- Current pricing for equivalent services
- Any recent price changes (last 90 days)
- Feature comparison at each price point

## Deadline
EOD February 28

## Context
Prospect asked how our $199 compares. I need data,
not a recommendation — I'll handle positioning.

Notice what's absent: there's no sales language, no persuasion, no "let's close this deal." The message is structured data with a clear request. When Scout reads this, it processes the request through its own identity -- "I present options, I don't recommend" -- rather than absorbing Milo's sales-oriented framing.

If instead Milo had sent its full conversation with the prospect, Scout would read 50 turns of sales conversation and its next output would carry that tone. Structured summaries are a firewall between agent identities.

The message bus pattern

In production, inter-agent communication goes through a message directory, not direct context injection:

# File structure for agent communication
agents/
  scout/
    CLAUDE.md
    memory/
      active-tasks.md
      context.md
      in-progress.md
    inbox/
      2026-02-27-milo-research-request.md
    outbox/
      2026-02-27-pricing-analysis.md
  milo/
    CLAUDE.md
    memory/
      active-tasks.md
      context.md
    inbox/
      2026-02-27-scout-pricing-analysis.md
    outbox/
      2026-02-27-research-request.md

Each agent only reads from its own inbox/ and writes to its own outbox/. A simple routing script moves messages between outboxes and inboxes. This indirection is intentional -- it forces all inter-agent communication through the structured summary format and prevents any agent from accessing another agent's full context.

Measuring identity coherence

You can't maintain what you can't measure. Here are three concrete tests for identity coherence:

1. The same-question test

Ask every agent the same open-ended question. Compare responses.

# Test prompt sent to each agent:
"We have a new prospect interested in our services.
What should our next step be?"

# Expected responses (summarized):

Scout (research): "I can gather background on the
prospect — company size, tech stack, existing security
posture. What's the company name?"

Milo (sales): "What's their timeline and budget? I'll
draft a tailored pitch based on their segment."

Compliance agent: "Before any outreach, confirm we have
proper consent for contact and that our service
agreements are current for their jurisdiction."

Engineering agent: "Do we have capacity to take on
another client this month? Let me check the deployment
queue."

If your agents give similar answers, or if any agent answers in a voice that doesn't match its role, identity has drifted.

2. Voice bleeding detection

Analyze agent outputs for vocabulary that belongs to a different role. Specific signals:

• Research agent using sales language: "opportunity," "close," "pipeline," "value proposition"
• Sales agent using compliance language: "pursuant to," "in accordance with," "regulatory requirement"
• Engineering agent using marketing language: "game-changing," "revolutionary," "industry-leading"

This can be automated. Run a vocabulary classifier on each agent's last 50 outputs and flag any agent whose vocabulary distribution doesn't match its role baseline.

3. Boundary violation monitoring

Every agent's CLAUDE.md defines NEVER behaviors. Monitor for them.

# Boundary violation log format
# Checked automatically after each agent action

agent: scout
timestamp: 2026-02-27T15:45:00Z
violation: RECOMMENDATION_MADE
details: "Scout wrote 'I recommend going with vendor B'
  in pricing analysis. CLAUDE.md specifies NEVER make
  recommendations."
severity: medium
action: Flag for review. Re-inject Soul section.

Track violation frequency over time. A steady increase means your identity reinforcement mechanisms aren't strong enough. A sudden spike usually means a specific contamination event -- check what the agent read before the violation.

Full NanoClaw multi-agent configuration

Here's a complete nanoclaw.yaml for a multi-agent system with identity coherence built in:

# nanoclaw.yaml — multi-agent deployment with identity coherence

system:
  name: production-team
  version: 1.0
  message_routing: file_bus
  message_dir: ./messages/

agents:
  - name: milo
    role: sales
    model: claude-3-opus
    claude_md: ./agents/milo/CLAUDE.md
    memory_dir: ./agents/milo/memory/
    startup:
      - read: ./agents/milo/CLAUDE.md
      - read: ./agents/milo/memory/active-tasks.md
      - read: ./agents/milo/memory/context.md
    identity_refresh:
      enabled: true
      interval_turns: 25
      section: "Soul"
    boundaries:
      allowed_tools: [web_search, email_draft, crm_update]
      blocked_tools: [code_deploy, db_write, compliance_check]

  - name: scout
    role: research
    model: claude-3-opus
    claude_md: ./agents/scout/CLAUDE.md
    memory_dir: ./agents/scout/memory/
    startup:
      - read: ./agents/scout/CLAUDE.md
      - read: ./agents/scout/memory/active-tasks.md
      - read: ./agents/scout/memory/context.md
    identity_refresh:
      enabled: true
      interval_turns: 25
      section: "Soul"
    boundaries:
      allowed_tools: [web_search, file_read, api_call]
      blocked_tools: [send_email, deploy, crm_update]
      max_spend_per_session: 5.00

  - name: sentinel
    role: compliance
    model: claude-3-opus
    claude_md: ./agents/sentinel/CLAUDE.md
    memory_dir: ./agents/sentinel/memory/
    startup:
      - read: ./agents/sentinel/CLAUDE.md
      - read: ./agents/sentinel/memory/active-tasks.md
      - read: ./agents/sentinel/memory/context.md
    identity_refresh:
      enabled: true
      interval_turns: 20  # Shorter — compliance drift is expensive
      section: "Soul"
    boundaries:
      allowed_tools: [audit_log, policy_check, file_read]
      blocked_tools: [send_email, deploy, web_search, api_call]

isolation:
  shared_context: false          # Agents NEVER share context windows
  message_format: structured     # All inter-agent comms use templates
  context_firewall: true         # Tool outputs scoped per-agent

monitoring:
  identity_checks:
    enabled: true
    frequency: daily
    method: same_question_test
    alert_threshold: 0.7         # Similarity score above 0.7 = drift
  boundary_violations:
    enabled: true
    log_path: ./logs/violations.log
    alert_on: [NEVER_violation, repeated_ASK_FIRST_skip]

The cost of coherence

None of this is free. Here's what identity coherence costs in a 12-agent system:

• Session start ritual: ~3,000 tokens per agent per session. At 12 agents with 4 sessions per day, that's 144,000 tokens/day just for boot sequences.
• Identity refresh: ~200 tokens per refresh. With 25-turn intervals across 12 agents, expect 50-100 refreshes per day. That's 10,000-20,000 tokens/day.
• Structured inter-agent messages: Roughly 2x the tokens of a raw context share, because you're writing summaries instead of passing raw conversation. Add 30-50% to your inter-agent communication token budget.
• Monitoring overhead: The same-question test and vocabulary analysis add about 5,000 tokens/day for a 12-agent system.

Total overhead: roughly 200,000-250,000 tokens per day for a 12-agent deployment. At current model pricing, that's $3-8/day depending on the model.

The alternative is agents that can't maintain their role. A sales agent that hedges like a compliance agent will lose deals. A research agent that advocates instead of analyzing will produce biased outputs. A compliance agent that moves fast and breaks things will create actual legal liability. The cost of incoherence is measured in bad decisions, not tokens.

Implementation checklist

If you're running a multi-agent NanoClaw system, here's the minimum viable identity coherence setup:

1. Write a CLAUDE.md for every agent. Include Soul, Boundaries (ALWAYS/ASK FIRST/NEVER), Failure Modes, and Working Relationships. Budget 30 minutes per agent.
2. Create separate memory directories. Each agent gets its own memory/ directory with active-tasks.md and context.md. No shared memory files.
3. Implement the session start ritual. Every session reads identity, then tasks, then context, then in-progress work. No exceptions.
4. Enable identity refresh. Re-inject the Soul section every 25 turns. Adjust based on your conversation length.
5. Set up structured inter-agent messaging. No shared context windows. Structured summaries only. Use the file bus pattern.
6. Implement the same-question test. Run it weekly. If agent responses converge above 0.7 similarity, investigate and strengthen identity documents.
7. Monitor boundary violations. Log every NEVER violation. Trend upward means your identity architecture needs reinforcement.

It takes about a day to set up for an existing multi-agent system. The improvement in output quality and behavioral consistency is measurable within a week.

The bottom line

Identity coherence in multi-agent systems is an engineering problem, not a prompting problem. System prompts are necessary but decay over conversation length. Shared infrastructure creates cross-contamination vectors. Without active reinforcement, agents converge toward a generic mean.

The fix is architectural: identity documents that define not just instructions but personality, boundaries, and known failure modes. File-based memory that doubles as identity reinforcement. Session start rituals that cost tokens but prevent drift. Structured inter-agent communication that firewalls against personality contamination. And monitoring that catches coherence failures before they produce bad outputs.

Your agents don't keep forgetting who they are because the models are bad. They forget because you haven't built the infrastructure to help them remember.