Shared State Management

What it is

The data that several agents, or several turns of one agent, both read and write while pursuing a single objective — the work list, accumulated findings, intermediate artefacts, claims on items, decisions already taken — together with the rules that keep it coherent when more than one writer is active. It is the working record of one effort, held outside any participant's own context.

Why it matters

As soon as a second worker exists, something has to be the authority on what has been established, and a model's context is not that: contexts diverge, get trimmed, and are discarded at the end of a turn. The shared record is also the only durable thing — it is what a restart recovers to and what an audit reads. And it brings the classic concurrent-access problems along with it, now with writers that are non-deterministic, occasionally wrong with great confidence, and capable of rewriting a field they were only asked to append to.

Working record versus long-term memory

This is scoped to one objective and has a defined end: when the effort finishes, the record is archived or deleted, and nothing later reads it as fact. Memory persists across runs, accumulates about a user or a domain, and is retrieved into contexts that have nothing to do with the run that produced it — see Shared Agent Memory for that problem. Conflating them is how a provisional finding from one run becomes a remembered fact cited confidently in another.

Key decisions

• The scope and lifetime of the record: one turn, one run, one conversation thread, or one tenant — and what deletes it when that scope ends.
• Who may write which parts: a single owner per key, append-only for everyone, or open writes with a conflict rule.
• Whether writes are schema-validated structures or free-form text, which determines whether a bad write can be rejected at all.
• What a participant is guaranteed to see of another's writes, and whether anything depends on that guarantee being stronger than eventual.
• How disagreement is settled when two participants assert different values: last writer wins, versioned claims retained with provenance, or escalation to a person.
• What is persisted versus recomputed on resume, and how large the record may grow before it stops fitting in the context of whoever must read it.

Failure modes

• Two participants read the work list, each takes the first unclaimed item, and both perform it — including both halves of its side effect.
• The record is a free-text scratchpad; a participant "updates" it by rewriting the whole thing and silently drops three facts it did not judge relevant.
• Last-writer-wins discards a correction because the writer with the stale value happened to finish second, and the wrong value is the one that survives.
• Participants read the record once at the start of a long run and act for the next twenty minutes on a snapshot that stopped being true.
• The record grows without limit across a long effort until it no longer fits the context of the participant whose job is to summarise it.
• Provenance is absent: a statement appears in the record and nobody can tell whether a tool produced it, a model asserted it, or a user said it.
• Scoping is enforced in application code rather than in the store, and one missing filter mixes two runs or two tenants.
• The record outlives the run with no deletion path, so personal data accumulates in a store nobody has documented.

Related capabilities

• Multi-agent Orchestration — determines how many writers there are
• Parallel Execution — the source of simultaneous writes
• Interrupt and Resume — resumes from this record rather than from a context
• Agent Lifecycle — this record outlives the instances that wrote it
• Task Decomposition — supplies the work items that are claimed here

Applies: Production readiness · Design questions