The database becomes the agent’s memory

An agent can reason through a task, but enterprise work depends on remembering what happened before the latest prompt arrived. As autonomous systems take on longer processes, databases are becoming the persistent memory that connects decisions to the reality of the business.

A customer does not expect a company to forget yesterday’s conversation simply because somebody new answers the phone. If a refund has been approved, an address changed or an order placed on hold, the next person involved in the process is expected to know. That continuity is so fundamental to everyday business that it usually becomes noticeable only when it breaks.

Software agents expose the same requirement in a different form. A model can interpret a request and decide what should happen next, but that does not mean it automatically knows what happened five minutes earlier, what another system has already changed, or which version of an enterprise record now represents the truth. Once agents move beyond isolated questions and begin carrying work from one stage to another, remembering becomes an architectural problem.

A conversation is not a memory

Much of the early attention around generative systems concentrated on context windows: how much information a model can receive and retain during an interaction. Longer context helps, but it is not the same thing as persistent enterprise memory. Information held while a model processes a request can disappear with the session, while the state of a customer account or manufacturing order has to survive regardless of which model or agent touches it next.

Vikas Mathur, Chief Product Officer at database company MariaDB, sees this distinction becoming increasingly important as agents take on more complex work. “Agents are stateless by definition, but they need session context and short-term and long-term memory,” he explains. “That state must be stored somewhere. The data platform can provide the memory, the enterprise context and some of the computation the agent needs.”

What looks like a new problem therefore brings software back to one of computing’s oldest requirements. Business applications have always needed somewhere dependable to record what has happened. The difference is that people and conventional software previously created much of that state through clearly defined transactions. An agent can now decide which information it requires, make several requests of different systems and use the results to determine its next action.

The distinction matters once a process lasts longer than a single exchange. An agent handling a customer request may need to remember that identity checks have already been completed before passing the case elsewhere. Another might begin procurement research today and return to the task tomorrow after additional information arrives. The model may change between those moments without the underlying business state being allowed to do the same.

That persistent record also must distinguish between conversation and fact. A customer mentioning a possible change of address is not equivalent to the address being changed in the system of record. An agent proposing an action does not mean that action was authorised or completed. Memory must preserve the state of the business rather than simply accumulate everything that appeared in the dialogue.

The right version of reality

Giving an agent more information does not necessarily make it more reliable. Enterprise environments contain duplicate records, historic documents and contradictory versions of policies that were created for different purposes. The useful question is not how much information the system can retrieve, but whether it can reach the information that should govern the task in front of it.

Mathur sees grounding as one of the practical ways to narrow that problem. “Data plays a very significant role,” he says. “If you can narrow the focus of the model onto the right context, ground it in the relevant data and put guardrails around it, you can bring the hallucination problem under control very quickly.”

Hallucination is only one consequence of getting this wrong. A perfectly coherent answer can still be operationally useless if it is based on yesterday’s inventory figure or a policy that has since been replaced. As agents acquire the ability to act, the difference between plausible information and authoritative information becomes more consequential.

Retrieval answers one part of that requirement by finding information relevant to a question. Operational memory must do something more. It needs to preserve what has happened as a result. When an agent changes a delivery date, progresses an application or completes one stage of a workflow, that event becomes part of the context required by whoever or whatever takes the next step.

This is where the database begins to perform a different role in the architecture. It is not merely feeding knowledge into a model. It provides continuity between model calls, applications and interactions that would otherwise begin with only a partial understanding of the process. The intelligence may decide what should happen next, but the underlying state determines what has already happened.

The actor can disappear before the consequences do

Persistent memory creates another question that becomes harder as autonomous systems proliferate: who made the change? Conventional applications often rely on predictable machine identities with narrowly defined functions. Agents behave differently because they can choose how to achieve an objective and may call tools or systems that were not involved in the previous step. Alex Laurie, Senior Vice President at identity security company Ping Identity, argues that this makes the identity of the agent itself significant.

“With agents, one of the important differences is that they can make their own decisions,” Lawrie explains. “They try to find the easiest path to do something, a little like water or a grey IT user, which is why an identity specific to the agent is important. You can scope, control, govern and manage that identity according to its role.”

That identity becomes part of the organisation’s memory of the transaction. Knowing that a customer record changed is useful; knowing which digital actor changed it and under what authority may be essential when the result is challenged later. The agent might have been acting for an employee, another system or a supervisory process that delegated a narrow piece of work.

The complexity increases when agents create other agents. Laurie has experimented with systems capable of spawning temporary digital workers to complete subtasks before removing them almost immediately. “We could be talking about hundreds of millions of agents being created, running through their existence and disappearing again within minutes,” he says.

The agent can disappear while the consequence of its work remains. A short-lived identity may update a record that persists for years or supply information used by another system after the originating agent no longer exists. Enterprise memory therefore has to retain enough information about the action to reconstruct what happened without depending on the continued existence of the actor.

That requirement pushes auditability deeper into the architecture. Rather than treating logs as something consulted only after a security incident, organisations need persistent relationships between identity, state and action. When autonomous software is involved, the question of what changed cannot be separated easily from the question of who or what changed it.

One process may involve many agents

The memory problem becomes more visible again when work is distributed across specialised agents rather than handled by a single general-purpose system. One component might research a question before another evaluates the evidence, while a different agent carries out an approved action. The benefit comes from breaking a difficult process into manageable pieces, but those pieces still need enough shared context to form one coherent workflow.

Matt Penton, Director of Data and AI at consulting firm BIP Group, sees multi-agent architecture as a way of keeping complex work under greater control. “A single general-purpose large language model struggles with highly complex, multi-step tasks,” he explains. “It might lose context, produce inaccurate information or fail to follow a coherent plan. When you break that down into subtasks, a multi-agent system has a better way of keeping control.”

Breaking the work apart does not remove the requirement for continuity. In some respects, it increases it. The second agent needs to understand what the first has established without blindly repeating its work, while an execution agent needs to know whether the necessary checks have already taken place. Their individual model contexts can differ, but the business process cannot keep generating a different history for each participant.

The result looks less like one extraordinarily intelligent digital worker and more like a conventional enterprise system populated by increasingly autonomous components. Models contribute reasoning, agents provide specialised capabilities and orchestration determines how work moves between them. Beneath those layers sits the less fashionable requirement to maintain a consistent record of the process as it changes.

That may become one of the more sobering lessons of agentic deployment. Many of the problems exposed by autonomous software are not entirely new. Transactions still need to be recorded correctly. Current information needs to be distinguished from obsolete information. A process needs to survive when one component stops running. What changes is the speed and independence with which software can now read those records and alter them.

The database therefore becomes strategically important for reasons that have little to do with the current enthusiasm around any particular model. Persistent state gives an agent something its reasoning engine alone cannot supply: a durable connection to the organisation in which the decision is being made.

Customers will never care whether that continuity came from a vector store, relational database or orchestration layer. They will notice immediately when the company forgets that their problem was already resolved. Employees will notice when an agent repeats work that another system completed minutes earlier, while regulators and auditors will care when nobody can reconstruct how a consequential change entered the record.

A clever response can be generated from a prompt. A functioning enterprise has to remember what happened after the response was given. Reasoning may determine what an agent decides next, but memory determines whether that decision belongs to the same business reality as everything that came before it.