An organization using AI agents needs a durable account of what it has decided, why it decided it, and who can change that decision. I think of this as operational memory: the records that let the next person or agent continue the work with an accurate understanding of its current state.
This is the layer I keep coming back to when I think about agentic organizations. Generating a useful answer is one job. Making that answer part of an accountable, continuing operation is another.
My perspective comes from building Erich OS for my own work. It is a working example, not evidence that I have solved this problem for every organization.
A conversation can leave the next person guessing
Imagine a team discussing a new customer intake process. Someone suggests replacing the form. Another person recommends keeping it and improving the handoff. A third raises an exception. By the end, everyone present understands what they intend to do.
A month later, a new person searches the conversation and finds the suggestion to replace the form. An agent retrieves the same message. Both have found something real. Neither has necessarily found the decision.
For that handoff, I would want a short record explaining which approach was accepted, the reason, the unresolved exception and the person responsible. The conversation can remain the supporting source. The current decision needs a clear home of its own.
This connects to how I learned to describe things that are changing. People can use the same name for a system while referring to different states of it. A dated record helps establish which state we are discussing.
Agent memory and organizational memory have different jobs
There is useful technical work on helping agents carry information across sessions. In its guide to context engineering, Anthropic describes structured notes stored outside a model’s context window and brought back into later work. That addresses continuity when the relevant history no longer fits in the active conversation.
My organizational question sits alongside that technical one: which remembered information should the work rely on?
A note might contain an observation, an interpretation, a proposal or an accepted decision. Those have different consequences. A proposal to change a process should not acquire the standing of an approved change simply because it appears in a summary. A useful memory system needs a way to preserve those distinctions.
I would also separate access to information from authority to act. Knowing why a website needs a change does not by itself authorize publishing it. The permission has to come from the person or process responsible for that action.
What I chose to make durable in Erich OS
I built Erich OS as a hub for projects, tasks and AI-assisted work. Its public case study describes the problem directly: work spread across repositories, tools and conversations is difficult to keep connected.
The system brings together project records, tasks, links, people and decisions. AI tools use their own grants to read context and make supported updates. A separate workflow lets me approve execution. Those are deliberate choices about where context lives and who can contribute to it.
What matters to this article is the separation of responsibilities. A project has a purpose. A task names work to be done. A decision records a choice. A link points back to supporting material. Keeping them connected gives me a place to inspect the relationship between a proposed action and the work it serves.
That describes the system I built and use. It does not establish a measured reduction in errors, a productivity gain or a customer outcome. The useful test remains whether the records help me understand the work and decide what should happen next.
Give each consequential decision a small record
I would start with a few important decisions, using tools the team already maintains. A shared document, project system or versioned file can be enough. The storage choice should follow the people who need to read and update it.
Michael Nygard’s architecture decision record approach is a useful precedent. It preserves the context, decision, status and consequences of a significant technical choice. It also keeps a superseded decision available instead of erasing the reasoning behind it.
For operational work, I would adapt that into six questions:
- What did we decide? State the accepted choice and the scope it applies to.
- Why? Name the problem, alternatives considered and constraints that mattered.
- What supports it? Link the source, observation or test, including its date and limits.
- Who owns it? Name the person responsible for keeping the record current and the authority needed to change the decision.
- What is its standing? Make proposed, accepted and superseded choices distinguishable.
- When should we reconsider it? Record a review date or a condition that would change the answer.
For the imagined intake process, that might mean keeping the existing form, assigning a person to investigate failed handoffs, and reopening the replacement decision if the investigation demonstrates a limitation the current service cannot address. This is an example of a record, not a report of client work.
The point is to make the reasoning recoverable without requiring someone to reconstruct the whole discussion.
Keep memory current without collecting everything
I would preserve a concise working record and link to its evidence. I would not copy every conversation or private file into a place every agent can read.
Each source needs an appropriate audience. A project record can point to restricted material without reproducing it, and the access controls still need to hold. When an agent cannot read a source, that gap should remain visible. A confident summary cannot substitute for evidence it never saw.
Updates need care, too. If a decision changes, the current record should identify the replacement and preserve the earlier rationale. If two records disagree, the next step is to resolve the disagreement with the responsible person. Silently selecting whichever one is newer can hide an important difference in scope or authority.
Test the handoff before adding another tool
I would take one active project and ask someone who was not in the original conversation to explain the current decision, its reason, its owner and the next permitted action. Let them use the records the team expects an agent to use.
Where they have to guess, improve the record. Then repeat the exercise with an agent and inspect the sources behind its answer. An answer that sounds plausible is less useful than one whose reasoning can be checked.
This is part of the ownership question in Build vs. Buy in an AI Era. Before building another system, decide which responsibility you are prepared to maintain. A well-kept record in an existing tool may be a better next step than a new application with nobody responsible for its contents.
If your website or business systems work keeps losing decisions at handoffs, Market Jack’s defined project service describes how I help turn an agreed problem into a scoped implementation. Tell me where the handoff breaks, what records already exist, and who needs to rely on them.