Every few years the software industry finds a word it cannot stop saying. In 2026 the word is agentic. The pitch is seductive: instead of a chatbot that answers questions, you get an agent that takes actions — books the meeting, files the ticket, reconciles the invoice, ships the code. Vendors demo it, boards ask about it, and founders feel the pressure to have an agent story.
Most of that noise is worth ignoring. Underneath it, though, is something real: a genuinely new way to build software, where a model plans and uses tools in a loop rather than producing a single answer. This piece is the version we would give a client over coffee — what agentic AI actually is, the handful of patterns that hold up in production, the failure modes nobody demos, and how to deploy it without the whole thing depending on a good day from a language model.
What "agentic" actually means
Strip away the marketing and an AI agent is a loop. A model is given a goal and a set of tools — functions it can call, like "search the database", "send an email", or "run this code". It decides which tool to use, sees the result, and decides what to do next, repeating until the goal is met or it gives up. That is the whole idea. The intelligence is not in any single step; it is in the model choosing the right sequence of steps and recovering when one of them fails.
This is different from the previous generation of AI features, which were single-shot: prompt in, answer out. An agent is multi-step and stateful. That difference is exactly where the value and the risk both live. A single wrong answer is a mistake; a wrong action in a five-step loop can compound into a mess.
The one-sentence test
If the task is "answer this", you want a well-prompted model call, not an agent. If the task is "get this done, and the steps are not known in advance", that is where an agent earns its complexity.
Where agents earn their keep
Agents are not a general upgrade to every feature. They pay off in a specific shape of problem: multi-step tasks, with clear tools, where the exact steps vary each time, and where a human can check the result. A few that consistently work in production:
- Research and synthesisPull from several sources, cross-check, and produce a structured brief. The steps differ per question, and a person reviews the output before it matters.
- Triage and routingRead an incoming ticket, email or document, classify it, enrich it with context, and route it. High volume, well-bounded, and cheap to verify.
- Coding assistanceRead a codebase, make a change across several files, run the tests, and iterate on failures. The test suite is the safety net that makes the loop safe.
- Data cleanup and reconciliationMatch records, resolve conflicts, and flag what it cannot resolve for a human — instead of silently guessing.
Notice the common thread: in every case there is a cheap way to check the work. A test suite, a human reviewer, a reconciliation report. Agents work where verification is cheaper than the task itself.
The failure modes nobody demos
The demo always works. Production is where you meet the parts that were edited out. These are the ones we see most often:
Silent compounding errors
A small wrong turn in step two becomes a confidently wrong outcome by step five. Without checkpoints, the agent will happily build on its own mistake.
The unbounded loop
An agent that cannot tell it is stuck will keep trying, burning tokens and time. Every loop needs a hard limit and a way to escalate to a human.
Tool trust
An agent is only as safe as the tools you give it. "Delete records" in the toolset is a production incident waiting for a bad plan. Least privilege is not optional.
Non-determinism
The same input can produce different action sequences. That is fine for a draft, dangerous for anything with side effects, and it is why irreversible actions need a human gate.
A rule we hold to
An agent can propose an irreversible action. It should never be the thing that commits it without a human, or without a check that is at least as reliable as a human would be.
The patterns that hold up
Putting agents into production is less about the model and more about the scaffolding around it. Five patterns do most of the work:
- 1Scope the tools tightly. Give the agent the smallest set of tools that can do the job, each with the narrowest permissions. An agent that can only read and draft is far safer than one that can also send and delete.
- 2Make every step observable. Log the plan, the tool calls and the results. When an agent does something surprising — and it will — you need to see the exact sequence that led there. This is not optional tooling; it is the difference between a fixable system and a black box.
- 3Put a human at the irreversible steps. Reads and drafts run free; sends, payments, deletes and publishes wait for approval. This one decision removes most of the real-world risk.
- 4Bound the loop. A step limit, a cost limit, and a clear "I am stuck, escalate" path. An agent that knows how to give up is safer than one that does not.
- 5Evaluate continuously. Build a set of real tasks with known-good outcomes and run the agent against them on every change. Without evals you are shipping on vibes, and model updates will silently move your results.
A word on models, without the hype
The frontier model families — the Claude and GPT lines among them — have all become genuinely capable at tool use and multi-step reasoning, which is what makes any of this possible. But the model is rarely the thing that decides whether an agent succeeds in production. The tools, the guardrails, the observability and the evals decide that.
We deliberately keep our architecture model-agnostic behind a thin abstraction, so a project is never one vendor announcement away from a rewrite. Chase the best model for the task, by all means — just do not build the whole system so tightly around one that you cannot move. The pace of change in this space is the strongest argument for keeping that seam clean.
On version numbers
New model versions arrive constantly, and each one is described as a leap. Treat the claims as marketing until your own evals say otherwise. The only benchmark that matters is your task, on your data, measured by you.
How to start without betting the business
The right first agentic project is small, internal, and easy to check. Pick a task your team already does by hand that is high-volume and low-stakes — ticket triage, first-draft research, data tidying. Build the agent with a human in the loop from day one, instrument everything, and measure it against how the manual process actually performs.
If it beats the manual baseline on your own numbers, widen its scope carefully. If it does not, you have learned that cheaply, on a task where a wrong move costs nothing. That is the whole discipline: agentic AI is not a leap of faith, it is a series of small, verifiable bets, each one earning the right to the next.
Key takeaways
- An agent is a model that plans and uses tools in a loop — use one only when the steps are not known in advance and a human can check the result.
- Agents work where verifying the output is cheaper than doing the task: triage, research, coding with tests, reconciliation.
- The risk is multi-step: small errors compound, loops run away, and tools can do damage. Guardrails matter more than the model.
- Put a human at every irreversible action, bound every loop, log every step, and run continuous evals on your own tasks.
- Keep the architecture model-agnostic; the frontier is moving too fast to hard-wire one vendor.
Frequently asked questions
Is agentic AI just a chatbot with extra steps?
No. A chatbot answers; an agent acts. An agent is given a goal and a set of tools, then plans and executes a sequence of steps in a loop until the goal is met. The value and the risk both come from those multi-step actions, which is why guardrails matter so much more than they do for a simple chatbot.
What is the safest first agentic AI project?
A high-volume, low-stakes internal task where the output is cheap to check — ticket triage, first-draft research, or data reconciliation. Build it with a human approving any consequential action, instrument every step, and measure it against your current manual process before widening its scope.
Which AI model should we use for agents?
The frontier families (Claude, GPT and others) are all capable enough that the model is rarely the deciding factor. Success comes from the tools, guardrails, observability and evaluation around the model. We keep systems model-agnostic behind a thin abstraction so you can switch as the landscape changes.
How do you stop an AI agent from doing damage?
Least-privilege tools, a human gate on every irreversible action, hard limits on loop length and cost, full logging of every step, and continuous evaluation against known-good outcomes. An agent should be able to propose an irreversible action but never commit it unchecked.
Have a project in mind?
Tell us what you’re building. A senior engineer will come back within one working day with a scope, a timeline and a fixed price.