<!--
  Full-page Markdown export (rendered HTML → GFM).
  Source: https://neotoma.io/fr/multi-agent-state
  Generated: 2026-04-15T13:22:31.051Z
-->
Multi-Agent State

# When agents share state, write integrity stops being optional

A single agent writing to a single memory store degrades gracefully: bad writes erode quality over time. When multiple agents write to shared state, one bad observation propagates at machine speed, triggering downstream actions before any human can intervene. The failure mode shifts from gradual drift to cascade failure.

The masking effect

## Single-agent systems hide write-integrity failures

With one agent writing to one memory store, write corruption degrades quality slowly. The agent summarizes an observation slightly wrong, overwrites an entity attribute, or stores contradictory facts. The system still works—it just gets less reliable over time. The memory layer never gets blamed because the failure looks like an LLM problem.

Retrieval pain is legible; write corruption is not. Developers notice when the agent forgets or retrieves the wrong thing. They do not notice when the agent acts confidently on state that was corrupted at write time—until downstream consequences surface.

Failure modes

## What breaks when agents share state

When Agent A writes observations that Agent B reads and acts on, a fundamentally different failure topology emerges. These are not edge cases—they are structural properties of any multi-writer system without integrity guarantees.

Contradiction amplification

Two agents store conflicting facts about the same entity from different interactions. A third agent takes action on whichever fact the retrieval layer surfaces, with no basis for adjudicating between them.

Without write integrity

No forensic path. The retrieval layer returns one version; the contradiction is invisible until downstream consequences surface.

With write integrity

Append-only observation log with timestamps and source attribution. Both facts are preserved. The reducer surfaces the conflict deterministically.

Silent overwrite cascades

Agent A updates a record. Agent B, operating on a stale read, writes its own update that implicitly reverts Agent A's change. Neither agent throws an error.

Without write integrity

In a mutable database, this is nearly undetectable. The overwrite looks like a normal write. Previous state is gone.

With write integrity

In an append-only log with hash-linked observations, implicit overwrites are structurally impossible. Every write is a new observation, not a mutation.

Trust boundary collapse

Shared state implicitly means each agent trusts the other's writes. But agents have different capabilities, prompt contexts, and error profiles.

Without write integrity

A financial analysis agent and a support chatbot have equal write authority over the same entity state. No schema constraint distinguishes them.

With write integrity

Schema-constrained writes enforce what each agent can write. Observations carry writer identity and context. The reducer applies priority rules.

Cascade example

## How one bad write triggers a chain reaction

A SaaS company runs three agents sharing state about customer accounts: inbound support, account health scoring, and renewal/upsell recommendations.

1

Support agent

Processes a frustrated customer and stores: "customer expressed dissatisfaction with pricing, considering alternatives."

The customer was frustrated with a billing error, not pricing. The LLM-mediated extraction compressed the interaction into a misleading summary.

2

Health-scoring agent

Reads the support observation, downgrades the account, stores: "high churn risk, recommend retention intervention."

Acted on unfaithful source data. The downgrade is a correct inference from wrong premises.

3

Renewal agent

Reads the downgraded score, generates and sends a discount offer—within minutes, no human in the loop.

Retrieval worked at every step. The failure was in the write. Nothing in the system could trace the chain from bad observation to wrong action.

What write integrity changes

-   Every observation links to its source interaction, not a summarized derivative
-   The health-scoring agent sees the raw observation with provenance, not a flat fact
-   Contradiction between billing-error and pricing-dissatisfaction surfaces as a conflict, not a silent overwrite
-   The full causal chain from observation to action is traversable after the fact

Multi-agent topologies

## How multi-agent systems emerge (and where database decisions lock in)

Most multi-agent systems are not designed as multi-agent systems. They accrete: one agent for support, another for ops, then someone connects them. Database choices made at topology 1 are baked in by topology 3. Migrating from mutable to append-only state is a rearchitecture, not a library swap.

Hub-and-spoke

Low write risk

Current dominant pattern

One primary agent faces the user and delegates subtasks to specialized agents. Shared state is the primary agent's context window. Subordinate agents are stateless tool calls.

Cursor delegates to code, research, and analysis sub-agents. The hub manages all state.

Pipeline agents

Medium write risk

Now – 12 months

Sequential handoffs where each agent processes and enriches a work item. Each agent reads state written by the previous agent and appends its own.

Lead qualification → company research → outreach drafting → meeting scheduling. A bad write at step 2 calibrates every downstream agent wrong.

Event-driven with shared context

High write risk

12 – 24 months

Multiple agents subscribe to events from a shared environment, maintain their own perspectives, and write observations back to a common store. No orchestrator.

CRM agents, support agents, and billing agents all react to customer events independently. Concurrent writes from different interpretive frameworks, no coordinator to catch contradictions.

Persistent autonomous agents

Critical write risk

18 – 36 months

Agents running continuously, maintaining evolving world models, periodically synchronizing with other agents or a shared truth store. Context windows cannot serve as memory.

Always-on monitoring agents maintaining state across days or weeks, synchronizing findings with planning agents that act on the accumulated picture.

Integration model

## Between your agents and your database (not instead of it)

Your existing database remains the system of record for business data: customer records, transactions, product catalog. Agent-generated state—observations, inferences, entity resolutions, decisions—lives in a purpose-built write-integrity layer.

Human-written business data

-   →Customer records, product catalog, pricing
-   →Transactions, invoices, financial ledger
-   →Configuration, feature flags, system settings
-   →Content, documents, media assets

Stays in your existing Postgres, MySQL, or managed database. Mutable CRUD is appropriate here.

Agent-written observational state

-   Observations from agent interactions
-   Inferences, extractions, entity resolutions
-   Decisions with provenance chains
-   Cross-agent entity state and conflict resolution

Belongs in a write-integrity layer: append-only, schema-constrained, provenance-tracked, deterministically reducible.

## Every observation is traceable from day one

Teams that adopt write integrity early gain a compounding advantage: every agent write is auditable and consistent from the start. Teams that retrofit have a gap in their audit history—everything before the migration is a black box.

[Install Neotoma](/install)[Build vs buy assessment](/build-vs-buy)[Read the architecture](/architecture)

Open-source

MIT-licensed

5-minute install

Fully reversible