How do you keep agents' shared memory consistent?

Give each kind of fact one owner that may write it, version every change, attach a source to every entry, and settle conflicts by rules people set rather than by whichever agent wrote last. Where the rules cannot decide, the conflict goes to a person. Expiry and erasure must reach every copy, not just the first one found.

Why does shared memory drift?

Because several agents write to it from different inputs at different times. A support agent records that a customer has moved, based on a phone call. A collections agent, reading an older letter, records the previous address as current. A third agent reads whichever came last. Nobody did anything wrong in isolation; the memory is simply inconsistent.

Shared memory differs from a system of record in one important way: agents write to it freely, often as notes or summaries, and those writes rarely pass the validation a core system applies. That makes it fast to use and easy to corrupt. The concept is covered in what agent memory is.

What are the steps that keep it consistent?

1. Assign an owner per fact type. Only the address agent writes addresses; only the onboarding agent writes verification status. Other agents may propose changes, which the owner applies or rejects.
2. Attach a source to every write. Each entry records where the fact came from and how far it can be trusted: read from a system of record, signed by a known party, declared by the customer, or from outside.
3. Version, never overwrite. Every change creates a new version with author and time. The old one remains readable.
4. Rank sources for conflicts. A people-approved rule decides which wins: a fact read from the core system beats a customer's declaration in an email; a newer signed document beats an older one.
5. Lock while in use. When an agent is acting on a customer's case, other agents' writes to the same facts queue until it finishes or releases.
6. Reconcile against systems of record. A scheduled check compares memory with the authoritative systems and flags differences.
7. Expire and erase everywhere. Facts carry expiry dates, and erasure requests reach every store and every copy.

What may agents do, and what stays with a person?

What does this look like in practice?

Take an operations team that uses one agent to triage a shared operations mailbox and another to update customer records. An email arrives saying a business customer's finance contact has changed. The triage agent does not own contact facts, so it proposes the change with the email attached as its source, marked as external.

The records agent owns contacts. It sees the proposal, checks the ranking rules, and finds that an external email cannot replace a contact confirmed through the customer's logged-in portal. It holds the proposal for a person, who calls the customer on the number already held and confirms. Memory updates once, with a new version, the email and the call both recorded as sources.

How does consistency relate to policy answers?

Support agents often share reference memory as well: product rules, fees, eligibility. Here consistency means every agent reads the same current version. If one agent's notes override the published policy, customers get different answers to the same question. The fix is to keep policy as owned reference data with a version, never as agent notes, as discussed in keeping an AI support agent's answers consistent with policy.

Which controls leave evidence?

• Ownership rules, versioned, with an approver.
• A source and version on every memory entry.
• A record of every conflict, how it was resolved and by whom.
• Reconciliation results against systems of record.
• Erasure records showing every store reached, which matters when a person exercises their rights, as covered in GDPR erasure requests and AI agent memory.

The governing layer that enforces ownership and records conflicts is described in the governed agentic operating system guide.