Agentic AI Engineer

Two teams ship something they both call an agent. The first is a chat box with a system prompt, and it fails because it cannot actually do anything. The second is a fully autonomous loop with twelve tools and no step limit, and it fails because nobody can work out why it did what it did. Both mistakes come from treating "agentic" as a label you either claim or do not, rather than a dial you deliberately set.

The spectrum of autonomy

Chat completion: the model produces text and a human acts on it. Tool use: the model chooses to call a function you defined, and your code decides what happens next. Agent loop: the model observes results and decides the next action repeatedly, until it judges the task complete. Autonomous agent: the model sets its own subgoals, manages its own memory, and decides when it is finished.

The crisp technical distinction, and the one worth carrying into design reviews: a system is agentic to the degree that the model decides the control flow rather than your code. A pipeline that calls a model five times in a fixed order is not an agent, however sophisticated each call is. A single call that chooses between three tools has more genuine agency than that pipeline.

Autonomy is a cost, not a goal

The instinct is to treat more autonomy as more advanced. In production the relationship runs the other way: every increment of autonomy multiplies the ways the system can fail and makes each failure harder to diagnose, because errors compound across steps rather than surfacing at one.

The arithmetic is unforgiving. An agent that is 95 percent reliable at each step is only about 54 percent reliable across a twelve-step task, because the failures multiply rather than average. This is why teams are repeatedly surprised that an agent which looks excellent step by step completes barely half its tasks. The correct response is usually to remove steps, add verification at the points that matter, or narrow the task — not to reach for a better model.

The design target is the least autonomy that solves the problem. Most agents that survive contact with production sit at tool use or a short bounded loop.

Failure modes

Compounding error — per-step quality is high, task completion is poor, and the gap widens with trajectory length. Signal: strong spot-checks of individual steps alongside a task success rate nobody can explain.

Autonomy theatre — the loop always executes the same actions in the same order, so the model's apparent decisions are illusory. Signal: trajectory logs where the step sequence never varies across hundreds of runs.

Unbounded loop — no step or cost budget, so a confused agent retries until something external stops it. Signal: a cost-per-task distribution with a long, expensive tail.

Objective drift — over a long trajectory the original goal falls out of effective context and the agent solves an adjacent problem well. Signal: a final answer that is coherent, high quality, and not what was asked.

Explaining this to stakeholders

On the spectrum: a chat completion is asking a colleague for advice. Tool use is asking them to look something up. A full agent is handing them a company card and saying "sort out the office move." The usefulness and the risk rise together, and you would not hand over the card for a question you could answer yourself.

On why the team is not building the most autonomous version: autonomy is not a feature you add, it is supervision you remove. That is worth doing only where you have evidence the supervision was unnecessary.

On compounding errors: a process that is right ninety-five percent of the time at each of twelve stages is right about half the time overall. Reliability at the task level is the only number that matters, and it is always worse than the number people quote.