Memory-system engineering
Decide what should be remembered, retrieved, corrected, and removed in this deployment
When an agent needs information across interactions, this area becomes relevant. For the AI product and data platform owner, the concern is specific: persistent memory preserves an outdated inference and repeatedly presents it as a current fact. The engineering design starts from that consequence and follows the relevant evidence through the customer workflow. Design memory around customer tasks and data responsibilities. Compare behaviour with memory enabled and disabled, and include stale or corrupted entries; the objective is a justified deployment design rather than endorsement of a memory product.
The engineering decisions relationship
- Memory write rules
Establish the basis for write eligibility.
- Retrieval contribution
Check whether retained context helps the current task.
- Memory lifecycle design
Retain the scoped finding and its unresolved dependencies.
Decision
Frame the decision around write eligibility
Questions and the evidence they need
- Write eligibility
- Inspect memory write rules for the relevant constraint or observation.
- Retrieval contribution
- Inspect identity boundaries for the relevant constraint or observation.
- Lifecycle propagation
- Inspect retention and correction expectations for the relevant constraint or observation.
For the AI product and data platform owner, this becomes relevant when an agent needs information across interactions. The immediate decision is what should be remembered, retrieved, corrected, and removed in this deployment. The scope should be narrow enough that the engineering team can identify a meaningful alternative, including continuing the current approach if the available evidence already supports it.
The practical failure to challenge is that persistent memory preserves an outdated inference and repeatedly presents it as a current fact. That concern gives the work a concrete direction: establish what the relevant boundary should do, inspect how it behaves or would operate, and identify the owner of any gap. It should not be diluted into a broad transformation exercise before the specific question has been answered.
Mechanism
Memory design must cover correction and removal
Relationships within engineering decisions
- Write eligibility
- Decide which information may become persistent memory.
- Retrieval contribution
- Check whether retained context helps the current task.
- Lifecycle propagation
- Carry corrections and deletion through derived state.
Write eligibility
For this scope, write eligibility should be examined alongside memory write rules. Define what can become memory: an explicit statement, verified fact, task state, or qualified inference. Each type may need different provenance and correction rules. The design should avoid treating every useful-looking sentence as a permanent instruction for future interactions.
Retrieval contribution
For this scope, retrieval contribution should be examined alongside identity boundaries. Specify retrieval according to the acting identity, current task, and relevant time. Compare behaviour with memory enabled and disabled before assuming persistent context adds value. A correct entry can still be irrelevant or inappropriate for a particular task or user.
Deletion and update propagation
For this scope, deletion and update propagation should be examined alongside retention and correction expectations. Map retention, correction, deletion, and derived representations together. An entry removed from one store may remain influential in a summary or later rewrite. The proposed design should identify lifecycle owners and verification points in the actual deployment rather than rely on product-level feature claims.
Preparation
Connect the working inputs to the boundary being examined
Evidence packet for write eligibility
Illustrative working format
- Memory write rules
- Confirm the applicable revision and who resolves disputed interpretation.
- Identity boundaries
- Use nonsecret metadata to trace issuance, acceptance, and withdrawal responsibility.
- Retention and correction expectations
- Confirm the applicable revision and who resolves disputed interpretation.
The starting material is memory write rules, identity boundaries, and retention and correction expectations. Review these together rather than assuming one document tells the whole story. A stated rule may differ from a configured behaviour, and a proposed responsibility may not yet have an available owner. Identify those differences before selecting the detailed work.
Participation should include a workflow owner, an implementation lead, an eventual maintainer, and qualified control reviewers where needed. The customer should define which information and environments may be used. Synthetic or sanitised examples can support preparation when they preserve the relevant behaviour; if they omit a material dependency, record the limitation and agree how the missing evidence would be obtained.
How the work proceeds
Carry write eligibility through to an accountable finding
From the scoped material to a decision record
- Memory write rules
Make the component and operating boundary explicit.
- Retrieval contribution
Apply the scoped check to lifecycle propagation.
- Memory lifecycle design
Record the evidence, open dependencies, and the owner’s next decision.
Write eligibility should be a deliberate part of the design. Identify whether an entry represents an explicit user statement, a verified system fact, or an inference, and define how each can be corrected. The proposed memory contract should also show which identities can retrieve the entry and when its purpose ends.
A practical first slice would focus on write eligibility and then follow its consequences into retrieval contribution. Keep deletion and update propagation visible as a separate review question rather than assuming it is satisfied by the first result. The engineering team should record observations, competing explanations, and changes to the original assumptions. A second reviewer can challenge whether the evidence supports the recommendation and whether an apparently successful example omitted the condition that matters most.
Indicative artefact
Make the memory lifecycle design usable by its owner
Memory lifecycle design
Illustrative working format
- Memory lifecycle design
- Identify the assessed workflow, revision, and decision boundary.
- Deployment flow map
- Link supporting and contrary observations to inspectable evidence.
- Lifecycle verification plan
- Name the unresolved condition, next action, and accountable owner.
Indicative outputs include memory lifecycle design, deployment flow map, and lifecycle verification plan. Their form should follow the decision and the customer’s existing operating records. The first should establish the assessed boundary and relevant observations; the second should make material gaps or dependencies inspectable; the third should identify the action, owner, and evidence needed to revisit the decision.
Acceptance should be tested through use: can the responsible owner explain what was examined, identify an unresolved issue, and act on the next step without reconstructing the whole engagement? Findings should preserve counterevidence and limits. A polished document is insufficient if it does not help resolve the customer’s specific question.
Illustrative scenario
Examine lifecycle propagation through a constructed exception
A constructed case and its decision paths
Illustrative scenario
- Write eligibility
A customer changes a preference that the agent previously remembered.
- Retrieval contribution
Update the customer's preference and inspect derived retrieval paths.
- Lifecycle propagation
Verify the correction reaches later use rather than only the primary store.
Consider an illustrative situation in which an account-support agent remembers a preference that the user later changes. This is a constructed example, not a client engagement or an observed Softlander outcome.
For the changed-preference example, the illustrative sequence would write the original preference, use it, receive a correction, and repeat the task. It would inspect derived summaries and caches as well as the primary store. The design decision is whether the deployment can preserve useful continuity without treating old information as permanent authority.
The useful learning would be the difference between the expected behaviour and the behaviour or responsibility actually demonstrated. If the exercise leaves deletion and update propagation unresolved, that should remain a named next step. A recommendation to narrow the scope, improve a prerequisite, or hold the decision can be appropriate when the example exposes a material dependency.
Scope and next action
Keep the conclusion within the defined workflow and configuration
Confirm fit before the next commitment
- Write eligibility
- This review is limited to the defined workflow and configuration.
- Memory write rules
- The relevant owner must confirm access and the intended operating conditions.
- Memory lifecycle design
- Production acceptance needs separate scoped evidence.
The method described here is proposed engineering work. Scope, staffing, implementation access, acceptance, and commercial terms require a readiness review. A design or lab result does not establish production suitability, guaranteed reliability, or security certification.
Ways to engage
Related engagement scopes
AI Fractional Agentic AI Office
Create a regular place for agentic AI decisions. Connect initiative priorities, architecture questions, risk ownership and evidence reviews.
AI Fractional Agentic Transformation Office
Coordinate the operating changes behind agent adoption. Align workflow redesign, ownership, dependencies and adoption measures.
AI Harness Engineering Pod
Engineer a bounded AI execution harness with tool adapters, context handling, orchestration, recovery and observable traces.
Continue exploring
Related insights and resources
Engineer the harness, not just the prompt
Define the contracts around an agent's decisions: what state it trusts, which actions can execute, how interrupted work resumes, and what evidence an operator needs to recover safely.
Governing agent decisions
Governance becomes useful when it changes a decision. Connect each agent workflow to an accountable owner, explicit operating conditions, proportionate evidence and a practical route for exceptions and withdrawal.
Do you need an agent centre of excellence?
A centre can concentrate scarce expertise and reusable controls, or become an approval queue detached from real work. Choose the mandate before the structure.