“Continue where we left off.”

Six words, and a sizeable engineering specification. We expect the agent to know what we were doing, where we stopped, what we decided, which approaches failed, and what has changed since. Ideally, it should also remember that we prefer short answers. We did mention it once, three weeks ago.

As agents become collaborators, our expectations of their memory grow. A colleague who repeatedly asks for the project brief is frustrating. An agent that does the same feels broken, especially when it can otherwise produce impressive work. We want the competence of a specialist and the recall of someone who has taken perfect notes at every meeting.

Meanwhile, the model at the centre of the agent remains, in the ordinary inference setting, stateless across independent calls. Working with us does not automatically update its weights. Whatever makes the relationship continuous has to be provided by the system around it.

To understand agent memory, we should start there.

What information can the model use?

At each invocation, we can account for the model’s available information with a simple expression:

Available information = information encoded in the weights + information supplied in the input.

The weights encode patterns, capabilities and knowledge acquired during training. The input supplies the material for this particular invocation: instructions, messages, images, documents, tool results, and any previous work brought back into context. This is an accounting model, rather than a literal addition of independent quantities; some information appears in both places.

The useful work a model can produce depends on both its capabilities and its available information. A capable model can reason about a deployment, but it cannot reliably infer the private decision your team made yesterday. Conversely, giving an underpowered model the complete project history does not guarantee that it can solve the problem. Information has to be available and used correctly. Tools, permissions and execution budgets further constrain what the agent can accomplish.

Consider a running example. We are preparing a proposal for a fictional customer, Northstar. Yesterday, the customer asked about a private deployment. Our team discussed the request and agreed to investigate feasibility before promising anything. Today, we ask the agent to finish the proposal.

The model may know a great deal about private deployments. It still needs our particular discussion to know what Northstar requested and what we actually agreed to do.

Within a conversation, continuity can be achieved by supplying earlier messages again. Anthropic’s Messages API documentation describes this explicitly: multi-turn conversations are built by sending conversation history to a stateless API. A service can also manage history or continuation state on the caller’s behalf. In either case, the system carries information forward; the interaction has not, by itself, trained the model.

Here, “input” means the context actually made available for inference, including any context reconstructed by the service. We do not mean only the latest message visible in the chat box.

The input grows as the agent works

Initially, information comes from two directions. The user provides a request and perhaps explanations or attachments. The system provides instructions and context: the date, available tools, a project brief, the user’s preferences, or records selected for this task. Some of this system contribution is fixed; some is assembled dynamically for the user and situation. These are sources of information, not necessarily API message roles.

An agentic workflow adds a third source: information obtained during execution. The model can request a search, inspect a file, ask a question, or run a test. The surrounding software—the harness—executes those requests and supplies the results to a subsequent invocation. It can also add information without a model request: a background job finishes, a collaborator posts an update, or the environment changes.

For our proposal, that might look like this:

When Information supplied How it arrives
At the start “Finish the Northstar proposal” and the draft User request and attachment
At the start Project identity, writing preferences and a short decision summary Context assembled by the harness
During work Yesterday’s discussion about private deployment Search requested by the model
During work A feasibility investigation has just completed Update supplied by the harness

Each new result can change the next action. The agent does not need every relevant fact before it starts, but it needs a way to discover what is missing. Nor does the context have to grow forever: the system may remove old outputs, summarise progress, or replace earlier context as it proceeds. Anthropic’s context-engineering article describes implementations combining information supplied up front, retrieval during work, and persistent notes.

This is the broader information problem. Memory occupies a particular part of it.

What makes something a memory?

An agent looking up a public article on Google has acquired information. Calling every such lookup “memory” would make the word rather unhelpful.

For this article, memory is information retained from earlier experience for later use, whether that experience belongs to the agent, its user, or a group they work with. Retrieving yesterday’s Northstar discussion is an act of recall. Searching for a deployment guide the agent has never encountered is fresh research. Saving a useful conclusion from that research can create a memory for next time.

The mechanism may be identical: a search returns some text. What distinguishes memory is its relationship to prior experience. A company document can serve as shared memory when it preserves a decision or lesson from the organisation’s work, even if this particular agent did not participate.

There are also different things to retain. “Yesterday I studied thermodynamics” records an event. “The entropy of an isolated system does not decrease” records something learned. In our example, “Northstar asked about private deployment on Tuesday” preserves a recollection; “Private deployment is a Northstar requirement that still needs validation” extracts a useful piece of project knowledge.

The extraction matters. A record of an event and a conclusion drawn from it can answer different questions. The event lets us revisit the evidence; the conclusion lets us work without rereading the entire discussion. A saved procedure can go a step further and describe how to handle a similar situation next time.

“Learned” here means retained by the agent system for future use. The underlying model’s weights can remain exactly the same.

A brief objection to the borrowed neuroscience

You will often see these distinctions described as episodic, semantic and procedural memory. LangChain’s memory overview, for example, explicitly borrows this taxonomy from human memory research.

These labels can describe useful differences. Our distinction between a recollection and an extracted fact covers similar ground. But the vocabulary can give an architectural sketch more explanatory power than it has earned.

Calling a conversation log “episodic memory” gives it a distinguished psychological pedigree. It still leaves us to decide what to store, when to retrieve it, and how to stop yesterday’s mistake from becoming tomorrow’s instruction.

Our preference is to begin with those decisions. A taxonomy becomes useful when it changes what the system does. If the implementation is a folder of notes, we should be able to explain why those notes help without first giving the folder a hippocampus.

Reading memory: bring back what matters

The first implementation is straightforward: save the conversation and supply it again. For a short task, that may be all we need. The record contains the original wording and lets the model follow how the discussion developed.

Over weeks of work, however, it also contains failed attempts, duplicated documents, temporary assumptions, and decisions that were later reversed. Replaying all of it consumes context and processing, and leaves the model to reconstruct the current situation each time. A larger context window increases what we can supply; it does not decide which statement still applies.

We can instead maintain a concise project brief and make the detailed record available on demand. The brief might say that Northstar’s private deployment request is under investigation, with a reference to the discussion. The model can then retrieve the original exchange if it needs to understand the exact wording or rationale.

This creates two complementary reading paths. Automatic recall supplies information the system expects to be useful: the project brief, active constraints, a few relevant preferences. Requested recall lets the model investigate a question that emerges during work: “What did we promise Northstar?” or “Why did we reject the earlier approach?”

Both have costs. Automatic recall can repeatedly insert irrelevant or stale information. Requested recall can miss a fact the model does not realise it should look for. A useful starting point is to supply enough context to orient the agent, including pointers to more detailed records, then let it investigate specific questions.

Storage choices follow from those questions. An exact project status can live in a structured record. A decision and its rationale fit a written note. Previous discussions can be searched by words, meaning, date or participant. An identifier can connect the note to the right customer. One memory system may use all of these, without requiring a separate product for each.

At the moment of use, the important information must reach the model. A fact stored somewhere in a database is only potentially available until the system retrieves it and places it in context.

Writing memory: decide what survives

Reading gets most of the attention because we notice when an agent fails to recall something. But every useful retrieval depends on an earlier writing decision.

Return to yesterday’s meeting. The conversation includes a request for private deployment, an engineer’s concern about support costs, and an agreement to investigate. A summary that says “We agreed to provide private deployment” is compact, relevant and wrong. Better retrieval would simply deliver the mistake more reliably.

Writing memory therefore requires more than shortening a transcript. It requires deciding what was observed, what was concluded, and how far the conclusion applies. A useful project note could look like this:

Project: Northstar proposal
Observation: The customer asked about private deployment.
Decision: Investigate feasibility before making a commitment.
Status: Open; feasibility has not been confirmed.
Source: Tuesday's customer meeting and internal follow-up.
Owner: Delivery lead.

In a real system, the source should point to the actual records. The separation between observation and decision is doing useful work: the customer’s request cannot silently become our promise.

Some writes can be mechanical, such as recording that a test failed. Others require interpretation, such as extracting a preference from several interactions. The model may propose a note itself; the harness may capture an event or run a consolidation step after the task. In each case, the system needs a rule for what becomes durable. A verified result, an explicit instruction and a tentative inference deserve different treatment.

A single failed deployment is also weak evidence for a universal lesson. “Deployment failed with this configuration” can be a valuable recollection. “This platform cannot support private deployments” needs much stronger support. Persistent memory can make an agent repeat its own overgeneralisation across many otherwise independent sessions.

Useful memory has to change

Now the feasibility investigation finishes. Private deployment is possible under particular conditions, and the delivery lead approves including it in the proposal.

If we only append that result, a future search may return either the old uncertainty or the new approval. If we replace every old record, we lose the explanation of why the proposal took an extra week. We need both a current view and enough history to understand how we reached it.

The current project record can move from “under investigation” to “approved under these conditions”. The earlier decision remains in the history, marked as superseded and connected to the new one. A future question about today’s proposal reads the current status; a question about the delay follows the history.

This is why memory is a dynamic system. Information can become outdated, be contradicted, change scope, or turn out to have been false from the beginning. “Recorded on Friday” and “effective from Monday” may both matter. The latest message is not automatically the most authoritative source, especially when it contains a suggestion rather than a decision.

Forgetting belongs in this lifecycle too. A temporary outage need not remain in every project brief forever. Removing it from the default context can be enough while the incident report remains retrievable. Deleting a record entirely is a different operation, with consequences for any summaries or indexes that copied its contents.

The read and write sides continuously affect each other. What the agent recalls shapes its next action. The action produces new evidence, which may change the memory used on the next task.

When one agent remembers for another

Once memory lives outside the model, its writer and reader need not be the same agent. The assistant that attended the Northstar meeting can preserve a decision for the assistant that prepares the proposal. A human can correct the same record. A delivery agent can add the result of the feasibility investigation.

For our purposes, collective memory is information retained for a group to use. Collaborative memory adds the process through which several participants maintain it. These are working definitions: the distinction helps us separate shared access from shared responsibility for updates.

Sharing raises the stakes of writing. A sales assistant’s inference can become a delivery agent’s assumption, then appear in a customer’s proposal. The problem began before the final model invocation, when a tentative interpretation was promoted into shared knowledge.

We therefore need to know who said something, what supports it, which project it concerns, and who can change its status. The sales assistant may record a customer request; the delivery lead may be responsible for approving feasibility. Access also has to follow the information: a summary derived from a restricted discussion should not become visible to everyone simply because an agent rewrote it.

The group need not share one giant context window. Participants can retain local working notes while contributing selected facts and decisions to shared records. Common identifiers let their contributions refer to the same customer and project. Clear update rules keep two agents from silently overwriting each other’s work.

At this point, “what does the agent remember?” has become an organisational question: who can turn an observation into something the team treats as true?

Before giving the company a brain

The phrase “company brain” is an attractive destination for this discussion. For example, Glean’s Enterprise Graph presents a product built around relationships between people, projects, teams and processes, combining organisational context with individual work patterns. Its claims about understanding a company are vendor positioning; they are not evidence that a collective intelligence has emerged.

We can assess the underlying proposition through the information flow we have already established. What sources are connected? Which past decisions and lessons are retained? How are current facts retrieved? Who maintains them? Which information can each participant see?

There is another requirement underneath all of those: participants need compatible meanings for the information they exchange.

Suppose sales uses “customer” to mean any organisation in an active conversation, while delivery reserves it for an organisation with a signed contract. A request to list customer commitments is now ambiguous before the agent starts searching.

Before giving the company a brain, it would help to agree on what “customer” means.

An ontology makes concepts and their relationships explicit. In our example, we can distinguish an organisation, a proposal, a requirement and an approved commitment. We can specify that a requirement belongs to a proposal, that a commitment has an approving owner, and that both refer to an identifiable organisation. The records then describe particular instances: Northstar, this proposal, this deployment request.

Palantir’s Ontology is one concrete implementation, connecting data to objects, properties and links, and extending that representation with actions and functions. Its particular product goes beyond the basic conceptual vocabulary we need here.

An ontology helps the memory system identify what a statement is about and how it relates to other statements. It does not establish that the statement is true, resolve every disagreement, or keep the records current by itself. Those remain responsibilities of the surrounding processes. A graph is one way to represent relationships; storing notes in a graph does not automatically supply shared definitions.

For Northstar, the pieces now have distinct jobs. The ontology distinguishes a request from a commitment. The current record tells us whether the commitment is approved. The retained discussion explains why, and the original source lets us check what was actually said. A future agent can use that information without having attended the meeting.

What we should expect from a remembering agent

We began with a stateless model and an expectation of continuity. The bridge between them is a system that selects information from experience, stores it in useful forms, brings it back at the right time, and changes it when the evidence changes.

Its quality becomes visible when work resumes. Does the agent preserve a decision and its rationale? Does it respect a correction? Can it distinguish what the customer requested from what we approved? Can another agent continue the work without inheriting an unsupported assumption?

Those are useful tests even for a system made of a few files. More elaborate storage should earn its place by helping answer them.

When we say “continue where we left off”, we are asking the agent to reconstruct the relevant state of our work and act on it. The model supplies the ability to reason. The memory system makes our shared experience available for that reasoning, and keeps it worth relying on.

Sources and further reading

Documentation and product pages checked 5 September 2026. Northstar and its project history are illustrative; this article reports no experimental results.