当代理共享状态时，一切都会崩溃

The database choice that ages poorly

A company builds one agent for customer support. It stores observations in a database, Postgres, Mongo, Redis, whatever the team already runs. Months later, another team builds an account health agent. Someone connects them because a human got tired of copy-pasting context between tools. That connection, a shared database table, becomes multi-agent shared state by accident.

Three agents now share state about customer accounts: inbound support, health scoring, and renewal recommendations.

The support agent processes a frustrated customer and stores: "customer expressed dissatisfaction with pricing, considering alternatives." The health-scoring agent reads this, downgrades the account. The renewal agent reads the downgraded score, generates and sends a discount offer. All within minutes. No human in the loop.

The support agent's initial observation was wrong. The customer was frustrated with a billing error, not pricing. But the LLM-mediated memory extraction compressed the interaction into a misleading summary, and that summary propagated through shared state as ground truth.

Retrieval worked at every step. The failure was in the write. Nothing in the system could detect that the initial observation was unfaithful to its source, or trace the causal chain from bad write to bad action.

Why single-agent systems mask the problem

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

This is where almost everyone is today. The pain is latent. Nobody can answer basic questions: what did the agent learn, when, from what source, did it contradict something it stored last week. But the system doesn't visibly break. Trust erodes subtly.

What changes with multiple agents

When Agent A writes observations that Agent B reads and acts on, a different failure topology emerges.

Contradiction amplification. Two agents store conflicting facts about the same entity from different interactions. A third agent arrives to take action and sees whichever fact the retrieval layer surfaces, with no basis for adjudicating between them. Without an append-only observation log with timestamps and source attribution, there's no forensic path to understand the contradiction.

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. In a mutable database, this is nearly undetectable. In an append-only log with hash-linked observations, it's structurally impossible.

Trust boundary collapse. Shared state means each agent trusts the other's writes. But agents have different capabilities, prompt contexts, and error profiles. A specialized financial analysis agent and a general-purpose support agent probably shouldn't have equal write authority over the same entity state. In a flat database with no schema constraints on who can write what, they do.

The four phases

The industry is moving through a predictable arc.

1. "Just use Postgres" (or just use a markdown file)

Manus, Claude Code, and OpenClaw all use plain text files for memory. Convergent evolution, not a shared playbook. When a team reaches for a database, memory gets bolted onto whatever is already there: RAG over Postgres with pgvector, Redis for session state, embeddings in Pinecone. Either path works for simple use cases. The mental model is agents need to remember stuff, files or databases store stuff, problem solved.

2. Retrieval optimization

Products like Mem0, Zep, and MemPalace accept that agents need a dedicated memory abstraction but frame the problem as retrieval quality. How to get the right context into the prompt at the right time. This solves a problem developers can already feel: bad recall, bloated context windows, irrelevant retrievals. But this phase leaves the write path unaudited. Whatever the LLM extracts is treated as ground truth.

This phase will dominate for the next year or two because retrieval pain is legible. Developers notice when the agent forgets or retrieves the wrong thing. Write corruption is illegible. The agent acts confidently on bad state and nobody realizes until downstream consequences surface.

3. The trust crisis

This arrives when agents move from low-stakes assistants to high-stakes actors, managing money, making procurement decisions, handling compliance workflows, operating autonomously over days or weeks. The question shifts from "did the agent retrieve the right thing?" to "can I prove what the agent knew, when it knew it, and whether that knowledge was legitimate?"

High-profile failures where agents acted on corrupted memory state will force this shift. Enterprise buyers will demand audit trails. Regulators in finance and healthcare will require deterministic provenance.

4. The bifurcation

The industry splits. Path A: existing databases add agentic primitives. Postgres gets extensions for observation logging and entity resolution. Supabase or PlanetScale ships an "agent memory" product layer. This captures many use cases where trust requirements are moderate.

Path B: purpose-built agentic state infrastructure for agents operating across trust boundaries, maintaining long-running autonomous state, or needing cryptographic provenance. The key invariants (append-only, hash-linked, schema-constrained, deterministic entity resolution) are architectural commitments that can't be reliably retrofitted as database extensions.

This is the path where agentic systems reach their full potential. Agents that can trust their own state, trace their own reasoning, and coordinate with other agents without silent corruption are qualitatively more capable than agents running on best-effort memory.

Write integrity isn't a safety feature bolted on after the fact. It's the foundation that makes autonomous operation possible.

How multi-agent systems will actually get built

Most won't be designed as multi-agent systems. They'll accrete.

Hub-and-spoke with a human hub is the current dominant pattern. One primary agent faces the user and delegates subtasks to specialized agents. Shared state is the primary agent's context window. Write-integrity risk is low. But this topology has a hard ceiling: the hub agent bottlenecks and can't maintain context across long-running workflows. This maps to phases 1 and 2: "just use Postgres" or a retrieval layer works fine because one agent controls the state.

Pipeline agents come next. Sequential handoffs where each agent processes and enriches a work item. Lead qualification to company research to outreach drafting to meeting scheduling. Write integrity starts mattering here. If the research agent stores incorrect company data, every downstream agent calibrates wrong. This is where teams start sliding from phase 2 into phase 3: retrieval still works, but the trust crisis is building beneath the surface.

Event-driven agents with shared context follow. Multiple agents subscribe to events from a shared environment (CRM, codebase, communication channel), maintain their own perspectives, and write observations back to a common store. No orchestrator. This is phase 3 in full: concurrent writes from agents with different interpretive frameworks, no coordinator to catch contradictions, and write integrity becomes genuinely dangerous.

Persistent autonomous agents with long-running state are the end state. Agents running continuously, maintaining evolving world models, periodically synchronizing with other agents or a shared truth store. Context windows can't serve as memory. These agents need persistent storage with real integrity guarantees. This is phase 4: the bifurcation. Either your infrastructure was built for this or it wasn't.

A key tension is that many developers choose their storage at topologies one and two, when shared-state risk is mild. They pick whatever database they already have and add a memories table. By the time they reach topologies three and four, the architectural commitments are baked in. Migrating from mutable to append-only state isn't a library swap. It's a rearchitecture.

The integration surface that matters

The winning architecture is probably not "replace your database" but "sit between your agents and your database."

Agents write observations to a write-integrity layer: append-only, schema-constrained, provenance-tracked. That layer manages agent-readable state. The developer's existing database remains the system of record for business data, customer records, transactions, product catalog. But agent-generated state, observations, inferences, entity resolutions, decisions, lives in a purpose-built layer.

In practice, the two layers talk to each other. An agent reads a customer record from Postgres, runs an analysis, and writes its observations (health score, churn risk, recommended action) to the write-integrity layer with a reference back to the source record. A second agent queries the integrity layer for all observations about that customer, gets a consistent snapshot with provenance, and acts on it. If something goes wrong, you trace the chain: which agent wrote what, when, based on which source data. The business database never gets polluted with agent-generated state, and the agent layer never loses track of where its observations came from.

The distinction between "human-written business data" and "agent-written observational state" is the clearest framing for why a new data layer is needed. You're not replacing their database. You're adding a layer for a category of data that didn't exist before agents started writing autonomously.

What I'm building

This is what Neotoma does. Append-only observations. Hash-linked provenance. Schema-constrained writes. Deterministic entity resolution. Every observation an agent writes is traceable, auditable, and consistent from day one.

I've been running my own agentic stack through it. Multiple agents (email triage, task management, finance, content planning) all writing to the same store. The multi-agent shared-state problem isn't hypothetical for me. It's the thing I hit every week when one agent's extraction contradicts another's, or when a stale read produces a downstream action on bad state.

The cost of waiting to adopt write integrity isn't technical debt you can pay down later. It's a gap in your audit history. Everything before the migration is a black box. That gap is permanent.

要点