Where an AI Agent Should Keep Its State

The ERP, the company's main business system, held the same supplier twice. An AI agent handled supplier onboarding: it read the supplier's documents, checked the tax number, created the supplier, requested bank details and set up payment terms. In testing it was faultless. In its first live week, a routine software update restarted the service mid-case, and the agent created the supplier again.

The model reasoned correctly both times. The fault was where the agent kept what it had already done: in a call to the ERP and its reply, inside a conversation history the restart wiped. The agent's memory of the world and the world had come apart, and nothing in the design noticed.

Most agent failures we review look like this: storage failures that pass for bad reasoning because the symptom shows in the output.

Three kinds of information, three owners

Many agent tools blur three kinds of information, and that is where the trouble starts.

The system of record is the business system that holds the truth: the ERP, the customer database, the ticketing tool, the bank. It applies its own checks and belongs to the client's IT team. The agent changes it only through interfaces that already exist.

The case file is the lasting account of the work: steps done, decisions, evidence, approvals. The workflow writes it, not the AI model. It sits beside the business system, in storage the client owns, never in spare fields of the ERP, where it would tie the agent to the ERP's upgrades and mix working notes with business truth.

The working context is what the model sees for the current step: instructions, the relevant documents, facts pulled from the other two. It is built for one step and thrown away.

The rule: the context is a view, never a store. Anything that must survive a step is written to the case file or the business system before the step counts as done. Stop the process at any moment and a fresh one rebuilds the context and carries on. We test this literally, by killing the agent at random points during acceptance testing and checking that every case still finishes exactly once.

There is a second reason to rebuild rather than pile up. Anthropic's engineers describe what they call context rot ("Effective context engineering for AI agents", September 2025): the more a model is given to hold, the worse it uses it, so context is a budget with diminishing returns. A context rebuilt for one step holds only what that step needs, so the agent stays sharp on day two of a case, when a piled-up history would be full of replaced values.

It is also a quick test of any agent design, a vendor's included: ask where each of the three lives. If the answer for two of them is "in the conversation", the design has only one.

Write down the intent before acting

Safe restarts come from the order of writes. Before any step that changes the outside world, the workflow records what it is about to do (create this supplier, for this case), and afterwards the reference number the system returned. A restart then finds an open intent, not a blank page, and nothing is repeated until that intent is resolved.

In the onboarding review, this removed the duplicate without changing a word of the agent's instructions, which were never the cause. The cost is a few extra writes and a little delay per step, always cheaper than one duplicate supplier, order or payment.

A plan is out of date the moment it is written

Many agent tools plan once, then execute. In an operation that is backwards. Over a two-day case, a buyer changes the order, credit control blocks the customer and someone corrects the address, while the agent holds a plan built on the old values.

So the plan is disposable and the checks are the asset. Each step that changes something carries the exact values it relied on when planned: the order version, the credit status, a fingerprint of the address. Before acting, it compares them with the live record. Unchanged, it goes ahead. Changed in a field it doesn't use, it goes ahead and logs it. Changed in a field it relies on, it stops and returns the case for replanning, showing a person both versions.

A check then a write still leaves a gap. Where the system supports it, the write carries the condition itself. The Dataverse Web API behind Microsoft's Dynamics 365 customer apps, for example, returns a version tag with each record and rejects an update if the record has changed since it was read. The check then holds at the moment of the write, not seconds before.

In the systems we have reviewed, out-of-date plans cause more wrong changes than wrong reasoning does, and they are invisible in testing, because test data never changes while the agent is thinking. The same goes for reference data such as customer and product lists: an agent keeping its own copy for speed will act on a stale one sooner or later, so it reads current values at the step that needs them.

Rebuilding the context each step costs time when a case carries long documents: a contract, a price list, a hundred-page tender. So we keep what was taken from them, an extracted table or a summary of the terms, labelled with the version of the source, never with the conversation. When the source changes, the old extract stops being used. Speed comes back without the context becoming a store.

Memory that changes decisions is a business rule

Agents now often come with memory: summaries of past work, kept for later. Anthropic's same post describes note-taking and summarising for long tasks, which suits research and coding agents. In an operation, summarising needs a limit. A summary keeps what looks important and drops the rest, and in a business case the rest is often the exception: the credit note that arrived late, the approver who asked for a second quote. So only the working context is summarised. The model may read a summary of the case file; the file itself, the audit trail, stays whole.

Business decisions need a harder line. If an agent learns that a supplier invoices per pallet while the purchase order counts cartons, that changes how future invoices are matched. It is a business rule, stored as one: the fact, the case it came from, who confirmed it, when it expires. A finance analyst can read, correct or delete it. Memory nobody can inspect, such as stored traces of old conversations that shift behaviour in ways no one could explain to an auditor, is not allowed near a business decision.

Where the business remembers

This separation costs design time before the agent does anything impressive, so under demo pressure it is deferred, and the demo works anyway: demos are short, single-user and never restarted. It pays off in live use: the agent can be stopped at any point, two people looking at a case see the same history, and when the model is replaced next year nothing is lost, because nothing lived in the model.

An agent's context is where it thinks. The record is where the business remembers.