Orchestrator-worker systems are often introduced with a simple picture: a lead agent delegates work to specialists, gathers their answers, and produces a final result. The diagram is useful, but it omits an important design choice:
What should each specialist remember after it returns?
It is tempting to answer “everything.” Persistent state sounds safer, and an agent that remembers may appear more capable. In practice, indiscriminate memory can increase context cost and preserve stale assumptions or coordination conflicts.
For many bounded specialists in orchestrator-worker systems, forgetting after a task is a sensible default. That scope does not fit every subagent: a specialist with a genuine continuing relationship may need durable state. The point is that memory should have an explicit job.
Memory is a scope decision, not a feature toggle
LangGraph’s subgraph documentation makes the choice unusually visible. A subgraph can run statelessly, inherit persistence for a single invocation, or retain its own state across calls. These modes have different implications for interruptions, parallel work, and multi-turn continuity.
The same distinction applies even if you are not using LangGraph. “Does this agent have memory?” is too broad a question. Ask instead:
- Is the work independent every time it runs?
- Does it need to resume a partially completed task?
- Does it need a private conversation over many invocations?
- Does the parent need to inspect or reuse its internal reasoning state?
- Would retained context make the next task worse rather than better?
Virillio Code Editorial proposes the following four-scope model. It draws on documented persistence modes and adds shared artifacts as a separate handoff category; it is not a standardized multi-agent memory taxonomy.
- Scope: Stateless — What survives: Nothing after the call — Best fit: Pure transformations, deterministic checks, cheap lookups — Main risk: Cannot resume after interruption
- Scope: Per-invocation — What survives: State during one parent task — Best fit: Independent research workers, one-off specialists — Main risk: Repeating work across calls
- Scope: Per-thread — What survives: Private state across related calls — Best fit: A specialist that truly needs a continuing dialogue — Main risk: Context contamination and coordination conflicts
- Scope: Shared artifact — What survives: Explicit output passed through a durable store — Best fit: Handoffs, plans, findings, approvals, deliverables — Main risk: Artifact sprawl without ownership rules
Stateless: use it when memory would be accidental
A stateless subagent behaves like a plain function. It receives its input, produces an output, and does not retain internal state after the call. That is the right choice when the task is independent and the cost of rerunning it is small.
Examples include normalizing a document, checking a narrow policy rule, extracting a field from a file, or reviewing one bounded diff. The system can make the outcome durable if needed; the subagent does not need to carry the full path it took to get there.
The tradeoff is clear: a stateless worker cannot pause and resume itself. But that is not a defect when the parent can retry or reassign the bounded task safely. It is a way to prevent unnecessary history from becoming hidden state.
Per-invocation: a strong default for bounded parallel specialists
For many bounded orchestrator-worker tasks, a worker needs context during an invocation but not after it. A research worker may search several sources, compare them, and return a structured synthesis. A code-review worker may inspect a subsystem and report risks. The next invocation can start fresh when the parent owns the durable task and consumes an explicit result.
This mode has three advantages:
- It supports a coherent task-local context without polluting later work.
- It makes parallel delegation safer because each worker has its own invocation scope.
- It turns the output into the handoff contract, rather than relying on private, implicit memory.
Anthropic’s account of its multi-agent research system illustrates one implementation of this pattern: an orchestrator delegates specialized exploration in parallel and uses returned findings to shape the next decision. That vendor example supports task-scoped delegation for its research workload; it does not establish that every worker in every multi-agent system should be ephemeral.
Per-thread: earn it with a real continuity requirement
Per-thread memory is appropriate when a specialist must maintain a genuine multi-turn relationship with a domain of work. A research agent might build and revise a source map over several sessions. A planning agent might maintain an evolving execution plan with unresolved dependencies. A user-facing specialist may need to remember prior clarifications in a long-running conversation.
But this mode deserves a higher bar. Long-lived private state creates questions that a simple workflow cannot answer automatically:
- Who owns the memory when the parent task changes?
- What happens when two invocations of the same specialist run in parallel?
- How does the parent audit or correct a stale assumption inside the subagent?
- When should that history be compacted, reset, or moved?
If the answer is “we hope the model remembers the important parts,” the scope is too broad.
Shared artifacts: make handoffs inspectable
The fourth option is often the most important: retain the *artifact*, not the subagent’s private state.
A plan, source ledger, test result, architecture decision, or approval record can be stored with a stable identity and clear ownership. The parent can inspect it, other workers can reference it, and a later run can decide whether it is still relevant. This is the structured-handoff pattern emphasized in work on long-running agent harnesses.
Shared artifacts have a crucial property that private memory lacks: they are addressable. A new worker can receive a concise artifact with provenance instead of inheriting a large, opaque transcript. Human reviewers can inspect the same material. Recovery logic can distinguish a completed finding from an unfinished internal thought.
A simple selection rule
Use the smallest memory scope that makes the task reliable.
- If the worker needs…: No cross-call continuity — Prefer…: Stateless
- If the worker needs…: Continuity only while finishing one delegated task — Prefer…: Per-invocation
- If the worker needs…: An ongoing private dialogue or plan that must survive new calls — Prefer…: Per-thread
- If the worker needs…: A durable result other agents or humans must inspect — Prefer…: Shared artifact
This rule reduces both context cost and operational ambiguity. It also makes the system easier to evolve: a stateless worker can later gain an explicit artifact contract; a per-invocation specialist can be promoted to per-thread only when evidence shows continuity is necessary.
Memory should be evaluated, not presumed
One important risk of persistent agent memory is false confidence. Retained context can preserve a useful decision, but it can also preserve an outdated plan, a wrong assumption, an inapplicable preference, or a tool result that no longer reflects reality.
Treat memory scope as part of the evaluation plan. For every persistent subagent, test whether it improves task success compared with a fresh worker plus a well-designed artifact. Measure the cost in token usage, recovery complexity, and error propagation. If memory does not produce a clear benefit, remove it.
That is not anti-memory. It follows the curation principle in Anthropic’s context-engineering guidance: retained material still has to earn space in the next inference.
What we are learning building Virillio Code
Virillio Code’s session architecture remains in development. Its current direction reinforces this distinction: durable work needs durable facts, but not every local execution path needs a durable identity or a growing private transcript. This is a design preference under evaluation, not a claim that one memory scope is universally best.
For teams adding subagents, the practical next step is modest: classify every specialist by memory scope before adding another persistent store. You may find that the best way to make a multi-agent system more reliable is to let more of its agents forget.
Sources and further reading
- LangGraph subgraphs — Stateless, per-invocation, and per-thread persistence have different multi-agent tradeoffs.
- How we built our multi-agent research system — An orchestrator-worker architecture can delegate specialized work in parallel.
- Effective context engineering for AI agents — Context must be curated over long horizons rather than accumulated indiscriminately.
Editorial disclosure
This article was substantially researched, drafted, and revised with AI through the Virillio Code editorial workflow. Virillio Code publishes the final text under its editorial byline, and the supporting primary sources are linked above.