An agent can have access to every message a person has ever sent and still fail to understand the relationship. The missing ingredient is not more text. It is a durable model that keeps identity, time, evidence, uncertainty and authority explicit as the world changes.
That distinction matters whenever an agent is expected to exercise judgment around people: preparing a customer review, recovering a commitment, briefing a founder before a meeting, or deciding whether a new signal materially changes an account. In those situations, retrieving a similar paragraph is useful but insufficient. The agent needs to know which person the paragraph refers to, whether it is still current, what supports it, and whether the present task is authorized to use it.
This is the core idea behind people-aware memory: memory organized around durable people and relationships rather than isolated message fragments.
Start with the decision, not the archive
The cleanest way to design memory is to begin with a decision the agent must support. Suppose a customer-success agent is preparing for an executive business review. It may need to know that the executive sponsor now measures success by weekly adoption rather than purchased seats; that two administrators are blocked by permissions; and that the account owner promised a written rollout plan by Friday.
Those are not three “relevant chunks.” They are three different kinds of state:
- a changed priority, with an effective time;
- an operational problem, with a current status and affected people;
- a commitment, with an owner and due date.
A transcript-only system tends to flatten these distinctions. A maintained memory model preserves them, making it possible to retrieve a concise, task-shaped answer instead of forcing the agent to reconstruct the relationship every time.
The five properties of useful people memory
A people-aware memory system needs at least five properties.
Canonical identity. Repeated mentions of “Maya,” “M. Chen,” a calendar attendee and a CRM contact should resolve to the same person only when the evidence supports that merge. Ambiguity should remain ambiguity. A mistaken identity merge is more damaging than a missed match because it can contaminate every downstream conclusion.
Temporal qualification. A role, preference or priority is not eternally true. Memory should distinguish current, historical, superseded and unresolved state. “Prefers email” may have been true last year; “asked for Slack during the launch” may be a temporary task instruction rather than a stable preference.
Provenance. Every consequential memory should retain enough source information to answer, “Why does the system believe this?” Provenance does not require exposing all raw content in every response. It requires a traversable connection from the concise memory back to supporting evidence.
Epistemic status. Facts, explicit direction, hypotheses and contradictions are not interchangeable. “Maya said adoption is the renewal measure” is different from “Maya may be losing confidence.” The latter can be useful, but it should remain qualified and should not silently harden into fact.
Authority scope. Memory availability is not permission to use it for every task. Personal context, organizational context and account-specific context may have different owners and boundaries. The retrieval request needs an explicit agent, purpose and scope. You can see how these constraints fit together in how the memory loop works.
Store claims, not personality profiles
A dangerous shortcut is to build an opaque profile: “Maya is skeptical, detail-oriented and risk-averse.” Even when such a summary sounds plausible, it hides the evidence, mixes observations with interpretation and encourages the agent to treat a person as static.
A better memory stores bounded claims. For example:
- “On 14 May, Maya asked for the adoption report before discussing renewal.”
- “Across the last two executive calls, Maya redirected seat-count discussion toward weekly active use.”
- “Hypothesis: confidence in the rollout may be weakening; support is two delayed approvals and a request for a smaller pilot.”
The hypothesis remains useful because its support and uncertainty are visible. A future signal can strengthen, weaken or supersede it. This is more operationally valuable than a confident adjective because it tells an agent what to verify and what evidence would change the conclusion.
Separate event memory from durable memory
Not every event deserves promotion into durable memory. A robust system usually has at least two stages.
First, it captures events: messages, meeting moments, document changes, explicit user corrections and system updates. Events are time-bound and source-bound. Second, it promotes selected information into maintained claims, commitments, preferences or relationships. Promotion should depend on repetition, consequence, explicitness or user direction—not on whether a sentence looks memorable to a language model.
This separation limits noise. A one-off joke, a temporary scheduling constraint or an assistant’s speculative summary should not automatically become a durable property of a person. Conversely, an explicit commitment with a deadline may deserve promotion after a single occurrence because the operational consequence is high.
A useful promotion policy asks:
- Is the subject identity sufficiently resolved?
- Is the information explicit, inferred or merely generated?
- Does it have an effective time or likely expiry?
- Is it material to a known task?
- Can it be corrected or superseded later?
Retrieval should prepare judgment
Memory retrieval should not return everything known about a person. It should prepare bounded context for the present decision.
For an executive review, the agent may need current priorities, open commitments, unresolved risks, recent material changes and source links. It probably does not need casual conversation, unrelated personal details or every historical version of a role. For a founder’s morning briefing, the same memory foundation may produce a different slice: people with upcoming meetings, promises due soon, relationship changes and decisions waiting on the founder.
This is why memory and retrieval cannot be designed separately. If the stored representation lacks time, provenance and scope, the retrieval layer cannot reliably reconstruct them later. Semantic similarity can rank candidates, but task-aware retrieval has to filter and shape the answer using structured state.
Correction is part of memory, not an exception
A memory system will be wrong sometimes. The key product question is whether mistakes can be found, understood and corrected without corrupting the history.
Correction should support at least three operations:
- edit the claim when the underlying statement was recorded incorrectly;
- supersede the claim when it was once true but is no longer current;
- split or merge identity when entity resolution was wrong.
Corrections should preserve an audit trail rather than silently rewriting the past. A user who says, “That is not Maya Chen; it is Maya Patel,” is providing high-value supervisory data. The system should fix the identity boundary, revisit derived claims and prevent the same evidence from continuing to support the wrong person.
Our memory-quality model treats inspectability and correction as core behavior rather than administrative cleanup.
Evaluate memory on decisions over time
Typical retrieval metrics are useful but incomplete. A people-aware memory system should also be evaluated on temporal and relational failures.
Ask whether it can:
- retrieve the current fact rather than the most frequently repeated old fact;
- avoid combining two people with similar names;
- distinguish an explicit preference from a model inference;
- surface a contradiction instead of choosing whichever source was embedded last;
- recover a commitment with the correct owner and deadline;
- exclude context outside the current authority scope;
- update a briefing after a correction without leaving stale derived claims behind.
These tests are closer to the failures users actually notice. An agent that retrieves a semantically relevant but superseded priority is not “mostly correct”; it is operationally wrong.
A practical implementation sequence
Teams do not need to solve every memory problem at once. A disciplined sequence is:
- Choose one decision surface, such as account preparation or a morning briefing.
- Define the small set of durable objects it requires: people, organizations, claims, commitments and relationships.
- Add provenance and effective-time fields before adding sophisticated inference.
- Establish conservative identity resolution with a review path for ambiguous cases.
- Define promotion and expiry rules for durable memory.
- Retrieve by subject, task and authority scope.
- Build corrections and temporal tests before broadening source coverage.
This approach produces less impressive demos than dumping a whole inbox into a vector database, but it produces a more dependable system. The objective is not to make the agent appear omniscient. It is to give the agent enough qualified relationship context to make the next decision with better continuity—and to show its work when that context matters.
If that is the problem you are building for, the developer model describes the boundary between existing agents and a dedicated memory layer.