AI agents are moving from answers to actions. That turns an AI problem into a distributed systems problem.
An AI agent can make the right decision and still do the wrong thing.
Imagine an agent decides, correctly, that a customer should receive a refund. It calls the payment provider.
The request times out.
Did the provider receive it? Should the agent retry? What if the first request actually succeeded? What happens if the second one succeeds too?
The reasoning can be right. The outcome can still be wrong.
That is the paradox that starts to matter when AI moves from answering questions to actually doing things.
Last year, Gartner predicted that more than 40% of agentic AI projects would be cancelled by the end of 2027. The reasons were familiar: high cost, unclear value and weak controls.
A year later, the warning looks slightly different. In May 2026, Gartner predicted that 40% of enterprises will demote or decommission autonomous AI agents because of governance failures discovered after production incidents.
That distinction is interesting.
The problem is no longer only whether companies can build useful agents. Increasingly, the agents work well enough to get into production.
And once they get there, a different set of problems starts to matter.
From answers to actions
The first generation of generative AI was fairly easy to understand operationally. A user asked a question, the model produced an answer, and a human decided what to do next.
Agents change that model.
They can call APIs, update systems, trigger workflows, create transactions, send data and invoke other agents. The output is no longer necessarily an answer someone reads. It can be an action that changes another system.
And actions have consequences that answers do not.
A payment can happen twice. An API can be unavailable. A request can disappear somewhere between sender and receiver. A destination can become overloaded. An operation can succeed even though the sender never gets the acknowledgement.
The agent may have done exactly what it was supposed to do.
The system around it can still fail.
That is not really an AI problem. It is a distributed systems problem.
We have seen these problems before
Software teams have spent years dealing with unreliable networks and systems that fail in inconvenient ways.
Queues, retries, backoff, idempotency, dead-letter queues, rate limits, audit logs and replay exist for a reason.
AI does not remove the need for any of this. It simply introduces more software capable of initiating actions without a developer or operator sitting in the loop.
Retries are a good example. "The agent can retry" sounds like a reasonable solution until you start asking what that actually means.
Was the error temporary? How long should it wait? Is the destination already overloaded? Could the previous request have succeeded without returning an acknowledgement? Can the operation safely happen twice? At what point should the system stop trying?
Reliable delivery is not just about retrying the action. It is also about understanding why it failed, whether another attempt makes sense, and when the system should stop.
Those decisions are infrastructure concerns. Having an agent improvise them at runtime does not necessarily make the system more resilient.
The agent should decide what needs to happen. The infrastructure around it should make delivery durable, controlled and observable.
The agents are moving faster than the infrastructure
Agent adoption is moving quickly.
McKinsey reported in August 2026 that 40% of respondents from companies with more than $1 billion in revenue are already scaling AI agents.
Forrester describes the same development from another angle: adoption is high, but relatively few companies have meaningful agentic systems running at scale in production.
The interesting question is no longer whether companies want agents. It is what happens when those agents get production access.
Then the surrounding infrastructure suddenly matters a lot more: who did what, what happened next, whether an action can be reversed, whether the receiving system actually got it, and what the system should do when something fails halfway through.
None of this is particularly new.
What is new is how many autonomous actors we may soon have doing it.
Today, most actions between systems are still initiated by application code written by developers. As agents become more common, a growing share can be triggered dynamically. One application may contain dozens or eventually hundreds of agents and automated processes calling internal services, third-party APIs and other agents.
That creates more machine-to-machine traffic.
It also creates more situations where the agent itself is not the problem.
Agents need boring infrastructure
There is a tendency to assume that every new problem created by AI needs another AI product.
Probably not.
Some of the most important infrastructure around agents will look remarkably familiar: durable queues, controlled retries, backpressure, idempotency, audit trails, replay and circuit breakers.
The difference is that these mechanisms increasingly sit between autonomous software and the real-world systems it is allowed to change.
This is also the thinking behind Queuey.
An application or agent should be able to publish what needs to happen without also owning buffering, retry logic, backoff, destination protection, replay and recovery. Those responsibilities are better handled by infrastructure built specifically for delivery. There is a clear distinction between orchestrating an agent's own execution and delivering its actions to external systems.
That also means reacting differently to different failures. A 429 is not the same as a 401, and a timeout is not the same as a confirmed rejection. Reliable delivery depends on knowing the difference.
The intelligence stays with the agent. The delivery problem does not.
The hard part starts when agents are allowed to act
The first wave of generative AI was mostly about producing better answers. Agentic AI is increasingly about allowing software to act on those answers.
That changes the consequences of failure.
If an AI assistant writes a bad paragraph, you delete it.
If an autonomous agent sends the same payment three times, the model being smarter is not much help after the money has moved.
That may turn out to be one of the more important shifts in agentic AI.
The hard part is not only making agents intelligent enough to decide what to do.
It is building systems that can survive when those decisions meet unreliable networks, unavailable APIs, ambiguous responses and everything else we already know about production software.
The agent can work perfectly.
The system still has to work too.