What an agent remembers

An AI agent has just booked your flight, and the airline has confirmed it. The agent hasn’t written that down yet.

It’s Friday, 4:40 in the afternoon. You need to be in Chicago on Monday, and the fare is $980, above your company’s $600 travel limit, so it waited for your manager. Your manager has just approved it. The booking agent picks up where it left off, books the flight, and the airline confirms. Then, before the agent writes down that it booked, its process crashes.

A minute later it restarts. Its last saved note says: approved, about to book.

Does it book again?

The model can’t tell you. It doesn’t remember anything between steps. Whatever the agent knows about this trip, something outside the model has to keep, and keep correctly.

In What is an enterprise agent? I said an agent is stateful: each step starts from what the last one left behind. This series is about the data layer: where the agent keeps its memory, its progress and its record, and what has to survive a crash. Most teams already run databases for familiar jobs: application backends, analytics, serving features to models. Agents add a newer one. They need somewhere to keep what they remember, and somewhere to try things before they touch real data. Three parts, starting with memory.

What an agent remembers

Think about what Maya, the travel coordinator, relies on while she books your trip. There are four kinds of thing:

On the desk. This trip: Chicago, Monday, the approved $980 fare, ready to book.
Past cases. Last time, you said you’d never take a red-eye.
About the business. The travel policy caps domestic economy flights at $600 round trip. The Chicago office moved in June.
How the job is done. The skills she arrived with, and the booking procedure she follows.

A new employee at a desk with four labelled things: an open folder (on the desk, working memory), a notebook (past cases, episodic memory), a pinboard (about the business, semantic memory) and a binder on a shelf (how the job is done, procedural memory, alongside the skills the employee arrived with).

These four help me think about what a booking agent needs. Researchers call them working, episodic, semantic and procedural memory, in the CoALA paper. That’s a way of thinking about agents, not a storage design.

One distinction matters here. The model arrives with what it learned in training, like Maya’s education. Unlike Maya, it doesn’t learn on this job: its trained knowledge stays fixed while it works. It only sees what’s on the desk right now, its context, and the instructions you give it are one thing on that desk. The trip’s notes live outside the model, in the filing cabinet. They only help once the right file is pulled onto the desk.

When memory has to be right

Where that filing cabinet lives is up to you. Frameworks keep it in Postgres, in vector stores or in graph databases. What changed my thinking wasn’t the choice of store. It was the crash.

I hit it in my own work. My orchestrator runs long jobs, and long jobs crash. When an agent restarts from its last saved checkpoint, anything it did after that checkpoint isn’t in it. LangGraph’s own docs warn that the step can run again. Without protection, our booking agent could buy a second $980 ticket.

The careful agent doesn’t trust its note. It checks the original booking request with the airline, the source of truth. If the answer is unclear, it pauses. If it retries, it reuses the same request number, so the booking service can spot a duplicate. All of that depends on its memory saying what was in flight, and on that note surviving the crash. At that point memory isn’t just something you hand the model. It records what’s done and what’s still in flight. And it has to survive crashes, retries and two agents touching the same trip.

Scratch or record

So for any piece of agent memory I now ask one question:

If this were lost, or quietly changed later, could I rebuild it safely and cheaply?

If yes, it’s scratch. The fares the agent compared, its draft itinerary. Keep it fast and let it go. If no, it’s a record. The manager’s approval, the ticket, your answer that Monday works. Keep it durably, with a clear rule for how long and who may change it.

That split, scratch versus record, turns out to shape the whole data layer.

Open questions

Deciding what to keep raises two questions about what the record preserves, and what it should forget.

When an agent summarises its own past, who checks that the summary didn’t drop the one detail that mattered?
When a traveller asks to delete their preferences, how do you keep the booking record without keeping more personal detail than you need?

Now multiply one trip by every trip a company books, with an agent behind each one. In part 2 I look at what happens to the database when agents become its newest users.