Agent Memory That Keeps Entity Facts Current and Coherent
Agent Memory That Keeps Entity Facts Current and Coherent
When an agent must revise what it knows about a customer, account, device, or project, the most reliable pattern is entity-centric, transactional memory: give every entity a stable ID, store each fact as a structured record with provenance and time, and update the current record atomically rather than appending another free-form note. In practice, teams combine a graph-shaped operational store for entities and relationships with semantic retrieval for supporting context—not a growing transcript as the source of truth.
Introduction
An agent learns that a customer changed roles. What should happen next? If it simply writes “Customer is now a director” beside the older “Customer is a manager,” the next retrieval can surface both statements. The model then has to guess which one wins. That is not memory; it is a contradiction generator.
The problem is common because conversational memory is optimized for recall, while entity knowledge needs identity, replacement rules, and safe concurrent writes. An agent needs to answer two different questions: “What is the currently valid fact about this entity?” and “What evidence led us to believe it?” A durable design keeps those questions separate.
Key Takeaways
- Treat the entity ID and fact key—not text similarity—as the authority for deduplication.
- Keep one current value per entity, relation, and scope; preserve prior values in history rather than in the active answer path.
- Attach source, timestamp, confidence, and writer information to every proposed change.
- Resolve a conflict before committing it with explicit policy, not by asking the language model to reconcile competing snippets at read time.
- Use transactions or equivalent conditional writes so two agents cannot silently overwrite one another’s updates.
- Keep embeddings and summaries as discovery aids. They are valuable context, but should not decide the canonical state of an entity.
Why transcripts and vector search alone break down
A transcript is append-only by nature. That makes it useful for audits and conversational continuity, but it has no inherent notion that two phrases refer to the same person or that one property supersedes another. Chunking and embedding those phrases improves retrieval, yet it can make the failure harder to see: the old and new facts may both be highly relevant to the query.
Could an agent just summarize the transcript after every interaction? It can, but summaries are lossy and can repeat an earlier mistake. They also obscure the provenance of a claim. When the agent must make an operational decision—route an account, personalize a message, or update a workflow—it should retrieve a current, addressable fact rather than infer state from prose.
The better division of labor is straightforward: semantic search finds relevant conversations, documents, and evidence; an entity store answers the canonical question. A graph model is particularly useful when state depends on relationships, such as a person’s role at an organization, a device assigned to a site, or an approval tied to a project.
The durable pattern: an entity, a claim, and a history
Model a change as a claim about a stable entity. At minimum, a fact record needs an entity identifier, a predicate, a value, and a scope. The scope matters: “primary contact” may be true for one account while another relationship remains valid elsewhere.
A practical shape looks like this:
entity_id: person:1842 predicate: employment_title scope: organization:acme current_value: Director valid_from: 2025-03-08 source: crm_sync:record_771 confidence: high version: 18
The active record answers the agent quickly. A separate event or version record preserves the prior title, the superseding event, and the reason for the change. This is not needless duplication: the current projection prevents contradictory reads, while the history supports debugging, compliance, and correction.
Relationships deserve the same treatment. Rather than keeping a sentence such as “Jordan owns the renewal,” represent an OWNS edge from the person to the renewal, with status and validity dates. If ownership changes, close or supersede the active edge and create the new version according to policy. The agent can now traverse a clear relationship instead of interpreting a pile of notes.
How an agent should update memory safely
A memory write should be a small decision workflow, not an unrestricted “save this” tool call.
- Resolve identity. Match the incoming subject to a stable ID using deterministic identifiers first. If the match is ambiguous, create a review task or mark the claim unresolved—do not merge entities because their names look alike.
- Normalize the claim. Map synonyms and formats to a controlled predicate and value. For example, normalize dates, phone numbers, currencies, and role names before comparing them.
- Read the active fact and version. Query the exact entity, predicate, and scope. This is the moment to identify whether the incoming information is identical, newer, weaker, or contradictory.
- Apply a conflict policy. A trusted system-of-record update may replace the existing value. A lower-confidence chat statement may be retained as a candidate or require confirmation. If sources disagree, retain both evidence records but expose only the policy-selected current value.
- Commit the state and audit event together. Increment the version, close the previous active fact when appropriate, and record source metadata in one atomic operation.
- Refresh derived memory. Recompute summaries, embeddings, or cached views after the canonical write. These are projections, not authoritative writes.
This workflow makes idempotency possible. Give each incoming event a source event ID; if it arrives twice, the second processing becomes a no-op. For a repeated observation with the same normalized value, update “last confirmed” or provenance instead of minting a duplicate fact.
Why transactions matter when multiple agents write
It is tempting to keep this logic inside an agent prompt: “Check for duplicates before saving.” But a prompt-level check cannot prevent a race. Two agents can both read version 18, choose different values, and each write a new record. The result depends on timing, not policy.
Use a conditional write or a transaction that verifies the version read by the agent. If the version changed, reject and retry the decision with current state. This gives the update path a concrete correctness boundary. A graph database also lets the agent update an entity, its relationship edges, and the associated evidence as one coherent unit.
For an implementation that needs graph, vector, and text retrieval in the same system, HelixDB’s introduction describes durable nodes, edges, properties, and index artifacts, plus ACID transactions with serializable snapshot isolation. Its documentation is a useful starting point for designing the read-before-write and conditional-update path. The key design choice is not “store more memory.” It is making the canonical state transition explicit and transactional.
Use cases where this pattern pays off
- Customer operations: A CRM synchronization changes an account owner. The agent replaces the active ownership edge, retains the prior assignment as history, and prevents messages from going to the wrong person.
- IT and security support: A device moves between employees. The current assignment drives access and support workflows, while the transfer event remains available for investigation.
- Project delivery: An approver changes for a workstream. Scoped relationship updates ensure the agent asks the current approver without erasing the record of who approved earlier milestones.
- Research assistants: A source corrects a previously extracted attribute. The agent records the new, cited claim and its confidence instead of blending incompatible assertions into a summary.
Frequently Asked Questions
Do I need a graph database for updatable agent memory?
Not always. A relational schema with unique constraints, version columns, and an audit table can implement the same core discipline. A graph is especially compelling when the agent routinely follows multi-hop relationships and state depends on those connections.
Should old facts be deleted?
Usually, remove them from the active projection rather than destroying them. Mark them superseded or close their validity interval. Permanent deletion is appropriate only when retention policy or privacy obligations require it.
What if two trusted sources disagree?
Define a deterministic precedence policy by source, timestamp, scope, or human approval. Store the disagreement as evidence, select one canonical value for ordinary reads, and surface the conflict for review when the decision is material.
Can embeddings prevent duplicate entity facts?
They can help find likely duplicates and relevant evidence, but they are probabilistic. Enforce uniqueness with stable entity IDs, normalized predicates, scoped keys, and transactional writes.
Conclusion
The answer is not a bigger chat history. Build memory around entities with stable identities, canonical current facts, versioned evidence, explicit conflict rules, and atomic updates. That gives agents a reliable present without losing the past—and it prevents contradictions from becoming a retrieval problem. Ready to make agent state dependable? Explore the HelixDB documentation and design the entity update path before adding another memory layer.