Agentic AI: what changes when a system takes actions
An agent is a system that decides its own next step instead of following a sequence somebody wrote in advance. That single property is the whole of the difference, and everything difficult about agents follows from it. It is why they can handle situations nobody anticipated, which fixed workflows cannot. It is also why they are slower, more expensive per item, harder to test because the space of behaviours is not enumerable, and capable of doing something you did not consider. The question that decides whether an agent is the right design is therefore not whether the technology is impressive. It is whether the sequence of steps genuinely cannot be known ahead of time. When it can, a plain script wins on cost, on speed, on testability and on being debuggable by somebody who was not there when it was built, and those advantages compound over the years the system will run.
The eight things worth understanding, in order
What AI agents are
The one property that defines an agent, where it earns its complexity, and where a plain script wins on every dimension that matters.
AI agent vs chatbot
One returns words a person can disregard. The other has already acted. Why that changes the approval model, the logging and the accountability.
Agent workflows
The shape most production systems actually take: a fixed workflow with an agent in the one step that genuinely varies.
AgentOps
Keeping agents running: tracing a non-deterministic decision, watching cost, and catching a degradation before a user reports it.
Agent security
Securing a system whose inputs are untrusted text and whose behaviour cannot be enumerated. Why instructions are the weakest control available.
Agent ROI
Why an agent that takes twelve steps costs roughly twelve times a single call, and what that does to a business case at volume.
Retrieval or fine-tuning
The choice teams agonise over and usually answer backwards, and the third option that is right more often than either.
Evaluating AI systems
The instrument everything else rests on, how it drifts away from reality, and why an average hides the failure that matters.
The line that matters is reversibility
Read across those eight pages and one distinction keeps reappearing under different names. Whether an action can be undone is what separates an engineering problem from an incident.
An agent that can only read, draft and propose is a system that occasionally wastes time. An agent that can send, delete, transfer or commit is a system that occasionally causes damage, and the same underlying model with the same error rate produces those two different outcomes purely because of what it was permitted to do.
This is why the reliable controls are structural rather than instructional. Restricting a credential works regardless of how the system reasons. Telling a system not to do something depends on it interpreting the instruction correctly in a situation you did not anticipate, which is precisely where it is least reliable.
What agents cost, and where the cost hides
An agent that takes twelve steps to answer a question costs roughly twelve times a single call. At a hundred requests a day that is invisible. At a hundred thousand it decides whether the system exists.
The cost is hard to see in a pilot, because a pilot runs at a volume where everything is affordable. It becomes visible on the first full invoice, at which point the system is in production and the options are worse. Estimating cost per request at design time, using the expected number of steps rather than the best case, is a ten-minute exercise that avoids the most common reason a working agent is switched off.
The related hidden cost is variance. The same input can produce different paths on different runs, so a system that passed testing can fail in a way testing could not find. That is not a defect to engineer away; it is the property you chose. The response is to bound the consequences rather than to chase determinism.
How to tell whether you need one
Sit down and try to write the steps. Not in a design document: on paper, as a sequence, with the branches named. Most teams can, and are surprised that they can, because the sense that a process is too complicated to sequence usually comes from never having tried.
If you can write them and the branches are countable, build that. It will cost less to develop, run in a fraction of the time, cost a fraction per item, and be maintainable by someone who joins next year. Choosing an agent here buys unpredictability and pays for it in every one of those dimensions.
If you genuinely cannot, look at why. Three reasons come up. The inputs vary more than you can enumerate, which is the strongest case for an agent. The next step depends on what the previous step found, across a wide space, which is the second strongest. Or nobody has yet done the work of understanding the process, which is not a case for an agent at all: it is a case for spending a week on the process first, and it is the most common of the three.
Where this fits with everything else
Agents are a technique, not a strategy. The five stages of a deployment do not change because the system is agentic, and the two stages where projects die, data access and adoption, are not made easier by a more capable architecture.
If anything, an agent makes stage four harder. People extend trust to a system that suggests far more readily than to one that acts, and an agent asks for the second kind of trust on day one. Teams that introduce an agent where a suggestion would have done are choosing the harder adoption problem for a capability nobody asked for.
