A
The moment an AI agent starts calling APIs, maintaining state, waiting for events, and changing the real world, the engineering problem changes completely.
For a while, the easiest way to understand an AI agent was to think of it as a chatbot with a few extra capabilities. A user gives it an instruction, the model reasons about the request, it calls a tool when necessary, receives the result, and then responds. That mental model is simple enough to build a prototype around, and for many early experiments, it is perfectly reasonable.
The problem starts when the agent becomes useful.
The first time we allow an agent to update a CRM record, create a support ticket, approve a transaction, check inventory, modify infrastructure, send an email, process a refund, or trigger another workflow, the architecture changes in a way that is easy to miss. The interface may still look like a conversation, but underneath that interface, the system is no longer simply generating responses. It coordinates state changes across multiple systems.
That is where the chatbot mental model begins to break down.
An agent that can act on the world has to deal with databases, APIs, authentication, network failures, concurrency, retries, stale data, partial execution, long-running workflows, permissions, and recovery. None of those problems disappears because the decision about what to do is being made by an LLM.
In fact, the more capable the model becomes, the more important these problems become. A model that can only generate text has a relatively small blast radius when something goes wrong. A model that can operate across enterprise systems has a much larger one.
This is why I increasingly think about production AI agents differently. An agent is not simply a chatbot with tools. It is a software process with a probabilistic decision-making component operating inside a distributed system. And once you see it that way, many of the problems that initially look like AI problems start looking very familiar.
Most agent demonstrations follow roughly the same pattern. A user asks for something, the model decides what needs to happen, a tool is called, the result comes back, and the model produces the final answer.
It looks something like this:
There is nothing wrong with this architecture for a prototype. In fact, it is probably where most useful agent systems should begin.
The problem is that the diagram hides almost everything that makes production software difficult.
What happens when the tool takes 30 seconds instead of 300 milliseconds? What happens when the network connection disappears immediately after the tool has completed its operation? What happens when two workers receive the same request? What happens when the data the agent retrieved five seconds ago has already changed? What happens when the process crashes after step three of a seven-step workflow?
And perhaps the most uncomfortable question is this: what happens when the system cannot determine whether an operation succeeded?
Consider a simple example. An agent is handling a customer refund. It decides that a customer should receive $500 and calls the payment service. The payment service processes the refund successfully, but the connection between the payment service and the agent breaks before the response reaches the agent.
From the agent's perspective, the request timed out. From the payment system's perspective, the refund succeeded. The two systems now have different versions of reality. A naive retry could produce another refund.
Nothing about this scenario requires the model to have made a bad decision. The model may have done exactly what it was supposed to do. The failure happened because two independent systems could not agree on what happened.
That is not a prompt-engineering problem. It is a distributed-systems problem.
I think one of the most important architectural changes in AI engineering is learning to separate the intelligence of the model from the guarantees provided by the software around it.
An LLM can reason about what should happen next. It can interpret an instruction, compare information, choose between tools, form a plan, and adapt when an operation returns an unexpected result. Those capabilities are extremely valuable.
But the model should not be responsible for guaranteeing that software can enforce deterministically.
If an agent decides that a customer should receive a refund, the model should not be responsible for making sure the refund happens exactly once. If an agent decides that an account should be modified, the model should not be responsible for determining whether it has authorisation to make that change. If an agent believes that a previous operation failed, the model should not have to guess whether the operation actually succeeded.
Those are infrastructure concerns.
A useful architecture, therefore, looks less like an LLM sitting directly on top of every business system and more like a series of boundaries between reasoning and execution.
The agent proposes an action. A policy layer evaluates whether the action is allowed. A validation layer checks whether the request is structurally and semantically valid. An execution layer operates. The result is recorded as a durable state, and that state becomes part of the context for the next decision.
The model remains flexible and probabilistic. The system around it remains deterministic wherever determinism is possible. That separation is going to become increasingly important as agents move into higher-consequence environments.
One of the easiest mistakes to make when building agents is to think about tools as ordinary functions. The code might look innocent:
But
The function hides the distributed nature of the operation.
Traditional application developers already know why this matters. A function call inside the same process is fundamentally different from a request sent across a network. The local function either executes or throws an exception. A network request introduces ambiguity. The remote service might execute the operation while the caller never receives the response.
That difference becomes even more important for agents because the next action is often dynamically selected based on the result.
If a normal application receives a timeout, the developer may already know what the correct recovery strategy should be. An agent may instead interpret the timeout as evidence that something failed and decide to try another action.
The system, therefore, has to give the agent reliable observations.
If the infrastructure tells the model that an operation failed when the real state is actually unknown, the agent can make a perfectly rational decision based on incorrect information.
The model isn't necessarily hallucinating. The system gave it an incomplete version of reality.
This is one of the concepts from distributed systems that becomes particularly important in agent architecture. We tend to think in binary terms: an operation succeeded, or it failed.
Production systems are rarely that simple. There is another state that matters enormously: unknown.
Imagine an agent submits a payment request. The payment provider receives the request and processes it. Before the response reaches the application, the connection fails. The application cannot truthfully say that the payment failed.
It can also not immediately say that the payment succeeded. The correct state is unknown. That distinction matters because the recovery strategy is completely different.
If the operation definitely failed, retrying might be reasonable. If the operation succeeded, retrying could create a duplicate. If the outcome is unknown, the system should first attempt to establish the truth, perhaps by querying the provider using a stable transaction identifier.
This is where idempotency becomes more than a backend implementation detail. Every meaningful external operation should have an identity that represents the business intent, not merely the individual network attempt. If the same logical refund is attempted three times because of timeouts, those three attempts should still refer to one refund operation.
The infrastructure can then recognise that the operation already exists and return its previous result instead of executing the business effect again.
This is particularly important for financial operations, but the principle applies much more broadly. Creating an account, sending an email, provisioning infrastructure, changing a subscription, issuing a ticket, or updating a customer record can all become problematic when retries are indistinguishable from new actions.
An agent that can retry safely is not necessarily smarter. It is an agent operating on better infrastructure.
AI discussions often use the word "memory" to describe everything an agent remembers between interactions. That is useful from a product perspective, but it can become dangerous from a systems perspective.
An agent remembering something does not mean the system knows that something is true. Suppose an agent says, "I already created the customer's account."
That statement might have come from its previous conversation history. But the authoritative system may tell a different story. Perhaps the account creation failed. Perhaps another worker created it. Perhaps the account was created and later deleted. Perhaps the operation is still pending.
The model's memory is context. The database is state. Those things should not be treated as interchangeable. This becomes especially important for long-running workflows. Imagine an agent responsible for onboarding a new enterprise customer. It has to verify documents, create an account, configure permissions, establish billing information, wait for approval, and eventually send a welcome message.
If the worker crashes halfway through the process, the replacement worker should not ask the model to remember what happened. The infrastructure should already be known. It might have a durable workflow record showing that document verification, account creation, and billing configuration are complete, while approval is still pending.
That allows another worker to resume the workflow without repeating actions that have already happened. This is a fundamental difference between conversational memory and durable execution state. The model can remember. The system has to know.
A chatbot normally exists inside a request. An agent doesn't have to. An agent might begin a task at 10 in the morning and finish it at 4 in the afternoon. It might wait for another service. It might wait for human approval. It might pause because a dependency is unavailable. It might receive a new event that changes the situation before the workflow finishes.
At that point, the traditional request-response architecture becomes a poor fit. Consider a procurement agent. A user might ask it to find a supplier and prepare a purchase order. That sounds like a single request, but the actual work could involve gathering supplier information, comparing prices, checking internal policies, requesting approval, waiting for that approval, generating the purchase order, and communicating with the supplier.
The agent isn't really answering a question anymore. It is coordinating a process. And processes need a durable state.
They need checkpoints. They need timeouts. They need cancellation. They need recovery. They need a way to resume after a worker crashes. They need a way to determine what has already happened.
This is where agent architecture starts overlapping heavily with workflow systems and distributed orchestration. The interesting part isn't that we suddenly discovered workflows because of AI. We didn't. What changed is that the component deciding what should happen next is now probabilistic.
The problem becomes even harder when an organisation runs multiple agent workers. Imagine two workers receive tasks concerning the same customer. Both retrieve the account and see that its status is
The agents may have behaved perfectly. The problem is that they were reasoning about the same state at the same time. Traditional distributed systems have spent decades developing ways to deal with this. Optimistic locking, version numbers, transactions, leases, concurrency control, and conflict detection all exist because multiple processes eventually try to change the same things. Agent systems will need those mechanisms too.
For example, an agent might retrieve an account at version 42. When it attempts to update that account, the database can reject the operation if the version has already become 43. The agent then retrieves the latest state and decides what to do next.
The important point is that the model does not need to understand optimistic concurrency control. It simply needs to operate within a system that enforces it. This is another reason I don't think the future of agent engineering is going to be about putting more and more responsibility inside the prompt.
The more powerful the agent becomes, the more important it becomes to put hard boundaries around what the agent can actually change.
There is another subtle problem that becomes visible when agents operate across enterprise systems: context is rarely as consistent as it looks. Imagine an agent deciding whether to approve an order. It retrieves the customer's profile from one service, inventory from another, payment status from a third system, previous interactions from a CRM, and company policy from a document repository.
The model receives all of that information inside one context window. To the model, it looks like a single representation of reality. It isn't. Each source may have a different consistency model. The inventory service may reflect changes immediately. The CRM may be updated a few seconds later. The search index may be several minutes behind. A document retrieval system may still be serving an older version of a policy document.
The agent can therefore produce an excellent answer based on inconsistent information. This is a particularly dangerous class of failure because it can look like a reasoning problem. The model didn't necessarily misunderstand the information. The information itself represented different points in time.
As agents become more autonomous, context engineering will increasingly become a data engineering problem. We will need to know not just what information was given to an agent, but where it came from, when it was retrieved, which version it represented, and whether it was authoritative enough to support the action being considered.
Giving an agent access to tools is easy. Giving it safe access to tools is much harder. There is a huge architectural difference between allowing an agent to read a customer's order history and allowing the same agent to cancel the order.
There is an even bigger difference between allowing an agent to recommend a refund and allowing it to execute one. The agent should therefore not have unrestricted access to every underlying system. Instead, the tool layer should act as a boundary between the agent's reasoning and the real world.
The agent can propose an operation. The infrastructure can authenticate the caller, check permissions, validate the parameters, enforce policy, apply rate limits, verify idempotency, and then execute the operation.
That architecture also makes auditing much easier. If something goes wrong, you can distinguish between what the model recommended and what the system actually allowed.
That distinction matters. A model saying "refund this customer" is not the same event as the payment system actually refunding the customer.
One is a decision. The other is a business effect. Those should have separate identities, separate records, and potentially separate controls.
One of the biggest differences between a demo agent and a production agent is how the system behaves when something breaks halfway through. Imagine a workflow with seven steps. The first four succeed, and the fifth fails because an external service becomes unavailable.
A simplistic system might restart the entire workflow. That sounds reasonable until the first four steps have side effects.
Maybe the customer was already created. Maybe the inventory was already reserved. Maybe the payment was already authorised. Maybe an email was already sent.
Starting again could duplicate those operations. A production system needs to know where it stopped and which operations are safe to repeat.
Sometimes the correct action is to retry. Sometimes it is to resume. Sometimes it is to compensate for an earlier action. Sometimes it is to wait. Sometimes it is to ask a human.
The model may help determine which path makes sense, but the infrastructure needs to preserve enough state for the decision to be made safely.
This is why durable checkpoints and explicit workflow states matter so much. A workflow should not depend on the model remembering its own execution history.
This is where I think the industry needs to be careful. As models improve, it is tempting to assume that many of these problems will disappear.
A better model will certainly make better decisions. It will be better at planning, reasoning about failure, choosing tools, and interpreting unexpected results. But a better model cannot make a network reliable.
It cannot turn a non-idempotent API into an idempotent one. It cannot guarantee that two workers won't modify the same record simultaneously. It cannot make stale data current. It cannot guarantee that a crashed process resumes from exactly the right point. It cannot create an audit trail unless the surrounding system records what happened.
And it cannot know whether a remote operation succeeded when the only information available is a timeout.
These are properties of the system. That is why I don't think the future of agent engineering is simply going to be bigger models connected to more tools. It is going to be better models operating inside much more sophisticated execution environments.
There is also a danger of overcorrecting. Once engineers understand the complexity of agent systems, it can be tempting to build an enormous infrastructure platform around every AI workflow.
That isn't necessary.
If a workflow is deterministic, a traditional workflow engine may be the better solution. If the application needs to validate a payment, update inventory, generate an invoice, and send a receipt in a known sequence, there may be very little value in asking an LLM to decide what happens next. AI becomes much more interesting when uncertainty is part of the problem.
An agent can investigate why a customer's account behaves differently from normal. It can examine multiple sources, form hypotheses, decide what information it needs, and determine which action is most appropriate.
But once it decides to execute a consequential operation, deterministic infrastructure should take over. That gives us a useful separation: let the model deal with uncertainty, while letting the system deal with guarantees.
This is perhaps the direction I find most interesting. We tend to talk about agents as if the model is the architecture. I don't think that's going to remain true. The model will increasingly become one component of an agent runtime that manages context, state, identity, permissions, workflows, tools, retries, events, observability, and recovery.
Different models may be used for different parts of the same workflow. A smaller model might handle classification. A larger model might handle complex reasoning. Another model might be used for summarisation or verification.
The runtime remains responsible for making sure that whatever model is being used operates inside known boundaries. That creates a useful abstraction. The model provides intelligence. The runtime provides execution. The infrastructure provides guarantees. The business system provides an authoritative state.
Once you separate those responsibilities, the architecture becomes much easier to reason about.
When evaluating an AI agent, we usually ask whether it can perform a task.
Can it book the meeting? Can it investigate the incident? Can it process the support request? Can it write the code? Can it deploy the service?
Those are useful questions, but they are incomplete. The more important question is what happens when the task doesn't go according to plan.
What happens when the service times out after executing the request? What happens when the worker crashes halfway through the workflow? What happens when the same event arrives twice? What happens when another agent changes the state? What happens when the information used by the model is stale? What happens when the user cancels the workflow? What happens when the agent no longer has permission to act?
And perhaps most importantly, can the system reconstruct exactly what happened? Those questions determine whether we have built an AI system or merely an impressive demonstration.
There is a useful dividing line between a chatbot and an agent.
It isn't the number of tools. It isn't whether the system uses memory. It isn't whether there are multiple models. It isn't even whether the system calls itself autonomous.
The dividing line is whether the system is responsible for work that continues beyond a single response and can change state outside itself.
Once that happens, the architecture has to account for the real world.
Networks fail. Services become unavailable. Messages are duplicated. Data becomes stale. Processes crash. Workers compete. Permissions change. Operations partially complete.
And sometimes the system simply doesn't know what happened. Those are not new problems. Distributed-systems engineers have been dealing with them for decades.
What is new is that we are putting probabilistic reasoning inside those systems. That makes the architecture more interesting, not less.
I don't think the most important question about agents is going to be how intelligent they become. It will be how safely we can connect that intelligence to the systems where consequences actually exist.
A model can make a recommendation. A policy engine can decide whether that recommendation is permitted. A workflow engine can make sure the operation survives a process restart. A database can provide an authoritative state.
An idempotency mechanism can prevent a retry from becoming a duplicate business action. An observability system can reconstruct the execution. A reconciliation process can resolve situations where the system cannot immediately determine what happened.
None of these mechanisms makes the model smarter. They make the environment around the model more trustworthy.
And that distinction matters because production systems are not judged by how impressive they behave when everything goes right. They are judged by what happens when things go wrong. A chatbot that gives the wrong answer is frustrating. An agent that retries a failed-looking payment that actually succeeded is expensive. An agent that updates a stale record can corrupt the business state. An agent that loses its workflow after completing half the steps can leave a process in a state nobody understands.
The intelligence of the model does not protect us from those failures. Architecture does.
The easiest way to build an agent is still to think about the next response. The harder and more important way to build one is to think about the entire lifecycle of the work.
Where does the state live? Who owns it? What happens when the network fails? What happens when a tool succeeds but the response disappears? How does the workflow resume? How are duplicate operations detected? How is authorisation enforced? How do we know what the model knew when it made its decision? How do we reconstruct the chain of events after something goes wrong?
These questions sound like distributed-systems questions because they are. The moment an AI agent starts operating across services, databases, APIs, queues, and long-running workflows, it inherits the realities of distributed computing.
The model may be probabilistic. The environment around it cannot afford to be careless. The model should be allowed to reason, explore possibilities, and adapt. But when its decisions cross into systems where correctness matters, deterministic infrastructure needs to take over.
That means the future of reliable agents probably isn't going to be defined simply by larger models or longer context windows. It will be defined by the engineering around those models: durable state, controlled execution, clear identity, safe retries, authorisation, observability, recovery, and strong boundaries between what an AI can suggest and what a system is willing to execute.
That is the point where an AI agent stops being a chatbot with a few tools attached. It becomes software infrastructure. And once it becomes infrastructure, we have to engineer it accordingly.
The model can decide what might happen next. The system has to make sure that whatever happens next is safe, observable, recoverable, and correct.
That, more than another clever prompt, is what will determine whether autonomous AI actually works in production.
For a while, the easiest way to understand an AI agent was to think of it as a chatbot with a few extra capabilities. A user gives it an instruction, the model reasons about the request, it calls a tool when necessary, receives the result, and then responds. That mental model is simple enough to build a prototype around, and for many early experiments, it is perfectly reasonable.
The problem starts when the agent becomes useful.
The first time we allow an agent to update a CRM record, create a support ticket, approve a transaction, check inventory, modify infrastructure, send an email, process a refund, or trigger another workflow, the architecture changes in a way that is easy to miss. The interface may still look like a conversation, but underneath that interface, the system is no longer simply generating responses. It coordinates state changes across multiple systems.
That is where the chatbot mental model begins to break down.
An agent that can act on the world has to deal with databases, APIs, authentication, network failures, concurrency, retries, stale data, partial execution, long-running workflows, permissions, and recovery. None of those problems disappears because the decision about what to do is being made by an LLM.
In fact, the more capable the model becomes, the more important these problems become. A model that can only generate text has a relatively small blast radius when something goes wrong. A model that can operate across enterprise systems has a much larger one.
This is why I increasingly think about production AI agents differently. An agent is not simply a chatbot with tools. It is a software process with a probabilistic decision-making component operating inside a distributed system. And once you see it that way, many of the problems that initially look like AI problems start looking very familiar.
The Demo Is Usually the Easy Part
Most agent demonstrations follow roughly the same pattern. A user asks for something, the model decides what needs to happen, a tool is called, the result comes back, and the model produces the final answer.
It looks something like this:
Code:
User
↓
Agent
↓
Tool
↓
Result
↓
Agent
↓
ResponseThere is nothing wrong with this architecture for a prototype. In fact, it is probably where most useful agent systems should begin.
The problem is that the diagram hides almost everything that makes production software difficult.
What happens when the tool takes 30 seconds instead of 300 milliseconds? What happens when the network connection disappears immediately after the tool has completed its operation? What happens when two workers receive the same request? What happens when the data the agent retrieved five seconds ago has already changed? What happens when the process crashes after step three of a seven-step workflow?
And perhaps the most uncomfortable question is this: what happens when the system cannot determine whether an operation succeeded?
Consider a simple example. An agent is handling a customer refund. It decides that a customer should receive $500 and calls the payment service. The payment service processes the refund successfully, but the connection between the payment service and the agent breaks before the response reaches the agent.
From the agent's perspective, the request timed out. From the payment system's perspective, the refund succeeded. The two systems now have different versions of reality. A naive retry could produce another refund.
Nothing about this scenario requires the model to have made a bad decision. The model may have done exactly what it was supposed to do. The failure happened because two independent systems could not agree on what happened.
That is not a prompt-engineering problem. It is a distributed-systems problem.
The Model Is Only One Part of the System
I think one of the most important architectural changes in AI engineering is learning to separate the intelligence of the model from the guarantees provided by the software around it.
An LLM can reason about what should happen next. It can interpret an instruction, compare information, choose between tools, form a plan, and adapt when an operation returns an unexpected result. Those capabilities are extremely valuable.
But the model should not be responsible for guaranteeing that software can enforce deterministically.
If an agent decides that a customer should receive a refund, the model should not be responsible for making sure the refund happens exactly once. If an agent decides that an account should be modified, the model should not be responsible for determining whether it has authorisation to make that change. If an agent believes that a previous operation failed, the model should not have to guess whether the operation actually succeeded.
Those are infrastructure concerns.
A useful architecture, therefore, looks less like an LLM sitting directly on top of every business system and more like a series of boundaries between reasoning and execution.
The agent proposes an action. A policy layer evaluates whether the action is allowed. A validation layer checks whether the request is structurally and semantically valid. An execution layer operates. The result is recorded as a durable state, and that state becomes part of the context for the next decision.
The model remains flexible and probabilistic. The system around it remains deterministic wherever determinism is possible. That separation is going to become increasingly important as agents move into higher-consequence environments.
A Tool Call Is Not Really a Function Call
One of the easiest mistakes to make when building agents is to think about tools as ordinary functions. The code might look innocent:
Code:
result = create_refund(order_id)But
create_refund() may actually cross several network boundaries. It might call a gateway, authenticate with a payment service, write to a database, contact an external payment processor, wait for a response, and then update another record.The function hides the distributed nature of the operation.
Traditional application developers already know why this matters. A function call inside the same process is fundamentally different from a request sent across a network. The local function either executes or throws an exception. A network request introduces ambiguity. The remote service might execute the operation while the caller never receives the response.
That difference becomes even more important for agents because the next action is often dynamically selected based on the result.
If a normal application receives a timeout, the developer may already know what the correct recovery strategy should be. An agent may instead interpret the timeout as evidence that something failed and decide to try another action.
The system, therefore, has to give the agent reliable observations.
If the infrastructure tells the model that an operation failed when the real state is actually unknown, the agent can make a perfectly rational decision based on incorrect information.
The model isn't necessarily hallucinating. The system gave it an incomplete version of reality.
"Unknown" Is a Real State
This is one of the concepts from distributed systems that becomes particularly important in agent architecture. We tend to think in binary terms: an operation succeeded, or it failed.
Production systems are rarely that simple. There is another state that matters enormously: unknown.
Imagine an agent submits a payment request. The payment provider receives the request and processes it. Before the response reaches the application, the connection fails. The application cannot truthfully say that the payment failed.
It can also not immediately say that the payment succeeded. The correct state is unknown. That distinction matters because the recovery strategy is completely different.
If the operation definitely failed, retrying might be reasonable. If the operation succeeded, retrying could create a duplicate. If the outcome is unknown, the system should first attempt to establish the truth, perhaps by querying the provider using a stable transaction identifier.
This is where idempotency becomes more than a backend implementation detail. Every meaningful external operation should have an identity that represents the business intent, not merely the individual network attempt. If the same logical refund is attempted three times because of timeouts, those three attempts should still refer to one refund operation.
The infrastructure can then recognise that the operation already exists and return its previous result instead of executing the business effect again.
This is particularly important for financial operations, but the principle applies much more broadly. Creating an account, sending an email, provisioning infrastructure, changing a subscription, issuing a ticket, or updating a customer record can all become problematic when retries are indistinguishable from new actions.
An agent that can retry safely is not necessarily smarter. It is an agent operating on better infrastructure.
The Agent Needs Durable State, Not Just Memory
AI discussions often use the word "memory" to describe everything an agent remembers between interactions. That is useful from a product perspective, but it can become dangerous from a systems perspective.
An agent remembering something does not mean the system knows that something is true. Suppose an agent says, "I already created the customer's account."
That statement might have come from its previous conversation history. But the authoritative system may tell a different story. Perhaps the account creation failed. Perhaps another worker created it. Perhaps the account was created and later deleted. Perhaps the operation is still pending.
The model's memory is context. The database is state. Those things should not be treated as interchangeable. This becomes especially important for long-running workflows. Imagine an agent responsible for onboarding a new enterprise customer. It has to verify documents, create an account, configure permissions, establish billing information, wait for approval, and eventually send a welcome message.
If the worker crashes halfway through the process, the replacement worker should not ask the model to remember what happened. The infrastructure should already be known. It might have a durable workflow record showing that document verification, account creation, and billing configuration are complete, while approval is still pending.
That allows another worker to resume the workflow without repeating actions that have already happened. This is a fundamental difference between conversational memory and durable execution state. The model can remember. The system has to know.
Once an Agent Runs for Hours, It Becomes a Workflow
A chatbot normally exists inside a request. An agent doesn't have to. An agent might begin a task at 10 in the morning and finish it at 4 in the afternoon. It might wait for another service. It might wait for human approval. It might pause because a dependency is unavailable. It might receive a new event that changes the situation before the workflow finishes.
At that point, the traditional request-response architecture becomes a poor fit. Consider a procurement agent. A user might ask it to find a supplier and prepare a purchase order. That sounds like a single request, but the actual work could involve gathering supplier information, comparing prices, checking internal policies, requesting approval, waiting for that approval, generating the purchase order, and communicating with the supplier.
The agent isn't really answering a question anymore. It is coordinating a process. And processes need a durable state.
They need checkpoints. They need timeouts. They need cancellation. They need recovery. They need a way to resume after a worker crashes. They need a way to determine what has already happened.
This is where agent architecture starts overlapping heavily with workflow systems and distributed orchestration. The interesting part isn't that we suddenly discovered workflows because of AI. We didn't. What changed is that the component deciding what should happen next is now probabilistic.
Concurrency Makes Everything More Interesting
The problem becomes even harder when an organisation runs multiple agent workers. Imagine two workers receive tasks concerning the same customer. Both retrieve the account and see that its status is
PENDING. Both independently determine that the account should be approved. Both attempt to update it.The agents may have behaved perfectly. The problem is that they were reasoning about the same state at the same time. Traditional distributed systems have spent decades developing ways to deal with this. Optimistic locking, version numbers, transactions, leases, concurrency control, and conflict detection all exist because multiple processes eventually try to change the same things. Agent systems will need those mechanisms too.
For example, an agent might retrieve an account at version 42. When it attempts to update that account, the database can reject the operation if the version has already become 43. The agent then retrieves the latest state and decides what to do next.
The important point is that the model does not need to understand optimistic concurrency control. It simply needs to operate within a system that enforces it. This is another reason I don't think the future of agent engineering is going to be about putting more and more responsibility inside the prompt.
The more powerful the agent becomes, the more important it becomes to put hard boundaries around what the agent can actually change.
Context Is a Data Consistency Problem Too
There is another subtle problem that becomes visible when agents operate across enterprise systems: context is rarely as consistent as it looks. Imagine an agent deciding whether to approve an order. It retrieves the customer's profile from one service, inventory from another, payment status from a third system, previous interactions from a CRM, and company policy from a document repository.
The model receives all of that information inside one context window. To the model, it looks like a single representation of reality. It isn't. Each source may have a different consistency model. The inventory service may reflect changes immediately. The CRM may be updated a few seconds later. The search index may be several minutes behind. A document retrieval system may still be serving an older version of a policy document.
The agent can therefore produce an excellent answer based on inconsistent information. This is a particularly dangerous class of failure because it can look like a reasoning problem. The model didn't necessarily misunderstand the information. The information itself represented different points in time.
As agents become more autonomous, context engineering will increasingly become a data engineering problem. We will need to know not just what information was given to an agent, but where it came from, when it was retrieved, which version it represented, and whether it was authoritative enough to support the action being considered.
The More Powerful the Tool, the Stronger the Boundary
Giving an agent access to tools is easy. Giving it safe access to tools is much harder. There is a huge architectural difference between allowing an agent to read a customer's order history and allowing the same agent to cancel the order.
There is an even bigger difference between allowing an agent to recommend a refund and allowing it to execute one. The agent should therefore not have unrestricted access to every underlying system. Instead, the tool layer should act as a boundary between the agent's reasoning and the real world.
The agent can propose an operation. The infrastructure can authenticate the caller, check permissions, validate the parameters, enforce policy, apply rate limits, verify idempotency, and then execute the operation.
That architecture also makes auditing much easier. If something goes wrong, you can distinguish between what the model recommended and what the system actually allowed.
That distinction matters. A model saying "refund this customer" is not the same event as the payment system actually refunding the customer.
One is a decision. The other is a business effect. Those should have separate identities, separate records, and potentially separate controls.
Recovery Is More Important Than Intelligence
One of the biggest differences between a demo agent and a production agent is how the system behaves when something breaks halfway through. Imagine a workflow with seven steps. The first four succeed, and the fifth fails because an external service becomes unavailable.
A simplistic system might restart the entire workflow. That sounds reasonable until the first four steps have side effects.
Maybe the customer was already created. Maybe the inventory was already reserved. Maybe the payment was already authorised. Maybe an email was already sent.
Starting again could duplicate those operations. A production system needs to know where it stopped and which operations are safe to repeat.
Sometimes the correct action is to retry. Sometimes it is to resume. Sometimes it is to compensate for an earlier action. Sometimes it is to wait. Sometimes it is to ask a human.
The model may help determine which path makes sense, but the infrastructure needs to preserve enough state for the decision to be made safely.
This is why durable checkpoints and explicit workflow states matter so much. A workflow should not depend on the model remembering its own execution history.
Better Models Won't Solve Distributed-System Failures
This is where I think the industry needs to be careful. As models improve, it is tempting to assume that many of these problems will disappear.
A better model will certainly make better decisions. It will be better at planning, reasoning about failure, choosing tools, and interpreting unexpected results. But a better model cannot make a network reliable.
It cannot turn a non-idempotent API into an idempotent one. It cannot guarantee that two workers won't modify the same record simultaneously. It cannot make stale data current. It cannot guarantee that a crashed process resumes from exactly the right point. It cannot create an audit trail unless the surrounding system records what happened.
And it cannot know whether a remote operation succeeded when the only information available is a timeout.
These are properties of the system. That is why I don't think the future of agent engineering is simply going to be bigger models connected to more tools. It is going to be better models operating inside much more sophisticated execution environments.
Not Everything Needs to Become an Agent
There is also a danger of overcorrecting. Once engineers understand the complexity of agent systems, it can be tempting to build an enormous infrastructure platform around every AI workflow.
That isn't necessary.
If a workflow is deterministic, a traditional workflow engine may be the better solution. If the application needs to validate a payment, update inventory, generate an invoice, and send a receipt in a known sequence, there may be very little value in asking an LLM to decide what happens next. AI becomes much more interesting when uncertainty is part of the problem.
An agent can investigate why a customer's account behaves differently from normal. It can examine multiple sources, form hypotheses, decide what information it needs, and determine which action is most appropriate.
But once it decides to execute a consequential operation, deterministic infrastructure should take over. That gives us a useful separation: let the model deal with uncertainty, while letting the system deal with guarantees.
The Agent Runtime Is Becoming the Real Architecture
This is perhaps the direction I find most interesting. We tend to talk about agents as if the model is the architecture. I don't think that's going to remain true. The model will increasingly become one component of an agent runtime that manages context, state, identity, permissions, workflows, tools, retries, events, observability, and recovery.
Different models may be used for different parts of the same workflow. A smaller model might handle classification. A larger model might handle complex reasoning. Another model might be used for summarisation or verification.
The runtime remains responsible for making sure that whatever model is being used operates inside known boundaries. That creates a useful abstraction. The model provides intelligence. The runtime provides execution. The infrastructure provides guarantees. The business system provides an authoritative state.
Once you separate those responsibilities, the architecture becomes much easier to reason about.
The Question We Should Be Asking
When evaluating an AI agent, we usually ask whether it can perform a task.
Can it book the meeting? Can it investigate the incident? Can it process the support request? Can it write the code? Can it deploy the service?
Those are useful questions, but they are incomplete. The more important question is what happens when the task doesn't go according to plan.
What happens when the service times out after executing the request? What happens when the worker crashes halfway through the workflow? What happens when the same event arrives twice? What happens when another agent changes the state? What happens when the information used by the model is stale? What happens when the user cancels the workflow? What happens when the agent no longer has permission to act?
And perhaps most importantly, can the system reconstruct exactly what happened? Those questions determine whether we have built an AI system or merely an impressive demonstration.
The Agent Has Crossed a Line
There is a useful dividing line between a chatbot and an agent.
It isn't the number of tools. It isn't whether the system uses memory. It isn't whether there are multiple models. It isn't even whether the system calls itself autonomous.
The dividing line is whether the system is responsible for work that continues beyond a single response and can change state outside itself.
Once that happens, the architecture has to account for the real world.
Networks fail. Services become unavailable. Messages are duplicated. Data becomes stale. Processes crash. Workers compete. Permissions change. Operations partially complete.
And sometimes the system simply doesn't know what happened. Those are not new problems. Distributed-systems engineers have been dealing with them for decades.
What is new is that we are putting probabilistic reasoning inside those systems. That makes the architecture more interesting, not less.
Intelligence Needs Infrastructure
I don't think the most important question about agents is going to be how intelligent they become. It will be how safely we can connect that intelligence to the systems where consequences actually exist.
A model can make a recommendation. A policy engine can decide whether that recommendation is permitted. A workflow engine can make sure the operation survives a process restart. A database can provide an authoritative state.
An idempotency mechanism can prevent a retry from becoming a duplicate business action. An observability system can reconstruct the execution. A reconciliation process can resolve situations where the system cannot immediately determine what happened.
None of these mechanisms makes the model smarter. They make the environment around the model more trustworthy.
And that distinction matters because production systems are not judged by how impressive they behave when everything goes right. They are judged by what happens when things go wrong. A chatbot that gives the wrong answer is frustrating. An agent that retries a failed-looking payment that actually succeeded is expensive. An agent that updates a stale record can corrupt the business state. An agent that loses its workflow after completing half the steps can leave a process in a state nobody understands.
The intelligence of the model does not protect us from those failures. Architecture does.
Your AI Agent Is Not a Chatbot Anymore
The easiest way to build an agent is still to think about the next response. The harder and more important way to build one is to think about the entire lifecycle of the work.
Where does the state live? Who owns it? What happens when the network fails? What happens when a tool succeeds but the response disappears? How does the workflow resume? How are duplicate operations detected? How is authorisation enforced? How do we know what the model knew when it made its decision? How do we reconstruct the chain of events after something goes wrong?
These questions sound like distributed-systems questions because they are. The moment an AI agent starts operating across services, databases, APIs, queues, and long-running workflows, it inherits the realities of distributed computing.
The model may be probabilistic. The environment around it cannot afford to be careless. The model should be allowed to reason, explore possibilities, and adapt. But when its decisions cross into systems where correctness matters, deterministic infrastructure needs to take over.
That means the future of reliable agents probably isn't going to be defined simply by larger models or longer context windows. It will be defined by the engineering around those models: durable state, controlled execution, clear identity, safe retries, authorisation, observability, recovery, and strong boundaries between what an AI can suggest and what a system is willing to execute.
That is the point where an AI agent stops being a chatbot with a few tools attached. It becomes software infrastructure. And once it becomes infrastructure, we have to engineer it accordingly.
The model can decide what might happen next. The system has to make sure that whatever happens next is safe, observable, recoverable, and correct.
That, more than another clever prompt, is what will determine whether autonomous AI actually works in production.