What agentic AI actually means in production

The word "agent" has been stretched far enough that it now covers everything from a prompt template to a system that can restart your production database. That vagueness costs real money, because the engineering you need for one is nothing like the engineering you need for the other.

Here is the line we use. A chatbot produces text. An agent produces decisions about what to do next, and then does them. The moment a model's output becomes an input to a tool call rather than a paragraph on a screen, you have crossed into agentic territory and the whole risk profile changes with it.

The loop is the product

A production agent is a loop: observe, decide, act, observe the result, decide again. Most of the interesting engineering lives in the parts that are not the model.

Observation means giving the agent a view of state that is accurate right now, not a snapshot from when the conversation started. An agent reasoning about a deploy from twenty minutes ago will confidently give you the wrong answer.

Decision is the model. This is the part everyone focuses on and the part you will spend the least time on.

Action means tools, and tools mean a real API surface with real failure modes. A tool that times out, returns a partial result, or succeeds but reports failure will happen to you in week one.

Termination is the one people forget. An agent with no stopping condition will happily burn through your token budget re-reading the same log file. You need a step ceiling, a cost ceiling, and a rule for what "done" looks like.

Three things that break first

The failure modes are consistent across every agent we have built.

The first is silent partial success. The agent performs three of five steps, reports that the task is complete, and moves on. Every tool needs to return a structured result the agent can actually verify against, not a string that says "OK".

The second is context drift. Long-running agents accumulate a transcript, and somewhere around the fortieth turn the original instruction stops carrying weight against forty turns of intermediate reasoning. Re-injecting the goal and the constraints on every turn is unglamorous and it works.

The third is confident recovery from a bad state. When something goes wrong, a model will keep going. Left alone it will try increasingly creative workarounds, and creativity is precisely what you do not want from something with write access.

What this means for scope

If you are considering an agent, the useful first question is not "which model" but "what is the worst thing this can do if it is wrong". That answer determines the architecture. Read-only agents are a product decision. Write-capable agents are a security decision. Agents that can spend money or delete things are an organisational decision, and they need an approval gate that no amount of prompting can talk its way past.

None of that is exotic. It is the same discipline you would apply to any system that acts on your behalf without a human watching each step. The novelty is only that the thing making the decision is a model, and models are persuasive in a way that a cron job never was.