You know how to use subagents. You know the frontmatter format, the Agent() tool, the five built-in types. But there's a deeper question: why do fork agents exist at all?

The answer, buried in Claude Code's source, is not architectural. It's economic. Fork agents exist to exploit Anthropic's prompt cache.

The cache exploitation mechanism. When Claude Code forks a subagent, the child inherits the parent's exact rendered system prompt bytes, exact tool array, and exact message history. Every byte is designed for identical prefixes. This is not a side effect — it's the primary design constraint.

Here's the math. A typical parent session has ~48,500 tokens of shared prefix (system prompt + tools + conversation). The first child pays full price for those tokens. But children 2, 3, 4, and 5? They hit a prefix cache. Anthropic charges 10% for cached input tokens. That's a 90% cost reduction on the shared prefix for every child after the first.

For Max plan users, the economics work differently — you don't pay per-token, but cache hits still reduce latency (cached prefixes process faster) and reduce load on Anthropic's infrastructure, which means fewer rate-limit hits.

The architectural compromises this creates. Every design decision in the fork agent system traces back to preserving byte-identical prefixes:

1. The Agent tool stays in the child's tool pool — even though children are forbidden from spawning their own agents. Removing it would change the serialized tool array and bust the cache.

1. Placeholder tool results are used instead of real ones. When the parent passes conversation context to a child, certain tool results are replaced with placeholders that are byte-identical across all children.

1. The session date is memoized. If midnight passes during a long session, the date doesn't update — because changing the date string in the system prompt would invalidate the entire cached prefix. A stale date is cosmetic; a cache bust reprocesses the entire conversation.

1. Sticky latch fields. Five boolean flags that, once set to true, never revert to false for the lifetime of the session. Same reason: flipping a flag would change the system prompt bytes.

The 15-step runAgent() lifecycle (from claude-code-from-source) reveals the full sequence: routing → model resolution → context preparation → permission isolation → tool pool assembly → system prompt rendering → hook registration → skill preloading → MCP initialization → execution → cleanup. Steps 4-6 are where cache alignment happens — permission isolation strips sensitive state, tool pool assembly preserves forbidden tools, and system prompt rendering produces byte-identical output.

Recursive fork prevention uses a dual guard: a fast querySource check (is this already a fork?) plus a fallback message history scan for the fork boilerplate tag. The belt-and-suspenders approach exists because a single guard caused infinite fork loops in production — one of five documented "death spiral" guards, each added because someone hit that failure mode.

What this means for your agent design. If you're building multi-agent systems with claude -p, the cache exploitation pattern applies to you. Design your orchestrator so that all child invocations share a common prefix: same system prompt, same tool configuration, same conversation preamble. Vary only the final user message. The cache TTL is 5 minutes — launch children within that window to maximize hits.

Two independent analyses — Anthropic's internal memory system (documented in claude-code-from-source) and the community-built Collabmem — arrived at the same architectural conclusion: flat files on disk, searched by an LLM, beat vector databases and embedding-based retrieval.

This is counterintuitive. RAG is the default architecture for AI memory. Embed everything, store vectors, retrieve by cosine similarity. But both systems chose plain markdown files. Here's why.

The derivability test. Claude Code's memory system uses a four-type taxonomy (user, feedback, project, reference) with a strict filter: if knowledge can be re-derived from the current codebase, it is excluded. Code patterns, architecture, file structure, recent changes — all excluded. The memory stores only what cannot be recovered by reading files or running git log.

This is a profound design choice. Most memory systems try to store everything and retrieve intelligently. Claude Code's approach inverts this: store almost nothing, but store the right things. The result is a memory that never becomes a stale parallel copy of information better sourced from its origin.

LLM-powered recall beats embeddings. Instead of vector similarity search, Claude Code uses a Sonnet side-query to read frontmatter manifests and select up to 5 relevant memories per turn. The recall runs as an async prefetch in parallel with the main model call.

Why not embeddings? One word: negation. The embedding for "do NOT mock databases in tests" is nearly identical to "mock databases in tests." Cosine similarity can't distinguish them. An LLM can. This isn't a theoretical concern — it was validated through evals (3/3 correct recall with LLM, 0/3 with embedding-based retrieval on negated instructions).

Collabmem's awareness-over-retrieval philosophy arrives at the same destination from a different starting point. Instead of treating memory as a search problem (store then retrieve), Collabmem keeps compact index tables always loaded in the context window. The indexes create continuous awareness — the model's attention mechanism naturally matches relevant topics before any explicit retrieval happens.

graph TD
    A[New Information] --> B{Can it be derived
from codebase?}
    B -->|Yes| C[Don't Store]
    B -->|No| D{What type?}
    D --> E[user: role, preferences]
    D --> F[feedback: corrections, confirmations]
    D --> G[project: decisions, deadlines]
    D --> H[reference: external pointers]
    E & F & G & H --> I[Markdown file + frontmatter]
    I --> J[LLM reads manifest at recall time]
    J --> K[Up to 5 memories selected per turn]

Two-tier context management. Collabmem divides memory into:

• Tier 1 (always loaded): Compact indexes and current state (~5,000 chars each). These live in the context window permanently via @import directives in CLAUDE.md.
• Tier 2 (searched on demand): Full notes, how-tos, domain knowledge. Grow without limit. Accessed via index → grep → read when the model's attention identifies a relevant topic from Tier 1.

Episodic memory is append-only. Notes are never rewritten. Old notes about code that was later changed remain as history — the reasoning, the alternatives considered, the decisions made. When knowledge matures, it's extracted upward into the "world model" (current truth). When the world model gets too large, compressed knowledge flows back down as episodic notes. Nothing is ever deleted.

The sentinel token pattern. Collabmem uses three explicit words — readmem, updatemem, maintainmem — that trigger memory operations when they appear in your message. The methodology document (imported into CLAUDE.md) instructs the model to act on these with MUST-level priority. It's a creative alternative to MCP tools: no infrastructure, no API calls, just words that activate behavior through instruction following.

Practical takeaway. If you're designing memory for your own agents, both systems validate the same principles:

1. Store only what can't be re-derived. Your codebase is the source of truth for code patterns. Memory is for decisions, preferences, and external references.
2. Use LLMs for recall, not embeddings. Especially when your instructions contain negations or nuanced conditions.
3. Keep indexes in context, details on disk. Awareness is cheap (compact indexes). Full retrieval is expensive (loading entire files). Let the model decide when to drill down.
4. Separate "what happened" from "what's true now." Episodic memory (append-only history) and world model (maintained current state) serve different purposes and have different staleness characteristics.