Denshin / Blog / AI

Agentic AI explained: what actually works in production

An agent is a specific thing: a system where the model, not your code, decides the next step. How agents differ from chatbots and LLM workflows, where they beat a scripted pipeline, the failure modes that cost real money, and a checklist for scoping your first one.

Denshin Engineering · Engineering Team · 27 August 2026 · 8 min read

Almost every vendor now describes their product as "agentic". Most of the time they are describing a form with a language model behind it. The distinction matters, because the engineering you need for a real agent is different in kind from the engineering you need for a prompt inside a request handler, and so is the failure surface. This is the post we wish we had before we shipped our first one: what an agent actually is, the small set of jobs where it beats a scripted pipeline, the jobs where it is the wrong tool, and the failure modes that quietly burn money before anyone notices.

What agentic AI actually means

An agent is a system in which a language model decides what to do next. It runs in a loop: read the current state, choose a tool, call it, read the result, then decide whether the job is done or another step is needed. The defining feature is not intelligence, it is control flow. In an agent, the model owns the branching. In everything else, your code does.

That one sentence explains most of what follows. If the model owns the branching, you cannot enumerate the paths in advance, you cannot unit test every route, and you cannot promise a caller how many external calls a single request will make. You buy flexibility on inputs you did not anticipate, and you pay in determinism, cost variance and observability work.

Chatbot, LLM workflow, agent: three different things

Every "should we build an agent" conversation gets easier once you separate these three shapes. They are not a maturity ladder. They are different tools, and the middle one is the right answer far more often than the market implies.

Shape	Who decides the next step	Best for	Main risk
Chatbot	The user, one turn at a time	Open questions, drafting, exploration	Confidently wrong answers, no ability to act
Workflow with LLM steps	Your code, with the model filling in specific steps	Extraction, classification, summarising, generating a fixed shape	Prompt brittleness, cost creep across high volume
Agent	The model, in a loop, with tools	Tasks with many valid paths and a cheap way to check the result	Non-determinism, unbounded cost, silent partial completion

The workflow is the default, not the consolation prize

If you can draw the flowchart, build the flowchart and let the model do the language-shaped parts inside it. A pipeline that calls a model three times in a fixed order is easier to test, easier to price, easier to debug at 2am, and usually just as good for the user. Reach for an agent when you genuinely cannot draw the flowchart, because the number of branches is large or unknown at design time. If your reason for choosing an agent is that agents are what everyone is building, that is not a reason.

Where agents genuinely beat a scripted pipeline

In our experience the wins cluster around a specific set of conditions, and they tend to appear together:

The input shape varies a lot. Every request needs a slightly different sequence of lookups, and the long tail is long enough that hard-coding it would never end.
The next step depends on what you find. You cannot fetch everything up front, so the system has to look, then decide, then look again.
Verification is cheaper than generation. A test suite, a schema, a type checker, a database constraint or a second cheap model can tell you whether the output is acceptable without a human reading it.
Iterating on failure is useful. When step three fails, trying a different approach has a real chance of working, rather than failing identically forever.

Coding is the clearest example, which is why coding agents landed first: the compiler and the test suite are a fast, free oracle. We use them in daily delivery for exactly that reason, and wrote up what changed in how AI pair programming reshaped our delivery. Triage, research over messy internal sources and multi-system reconciliation share the shape: many possible paths, a cheap check at the end.

Where an agent is the wrong tool

Four situations where we would argue against it, fairly firmly:

Deterministic work. If the rule is expressible as an if-statement, write the if-statement. A model that gets it right almost always is worse than code that gets it right always, and it costs money per call.
High volume, low margin per item. An agent that averages eight model calls per task is roughly eight times the cost and latency of a single-shot classification. At a few thousand items a day that difference stops being academic. We went through the arithmetic of this kind of decision in adding AI to your product without setting money on fire.
Low tolerance for error. Payments, payroll, medical or legal output, anything that writes to a system of record without review. You can still use an agent to prepare the work, but a human or a hard rule has to sign it off.
Tight latency budgets. A loop takes as long as it takes. If your product promises a response inside a second, an agent is not the component to put in that path.

The failure modes that will bite you

Loop until broke

The model cannot finish, cannot recognise that it cannot finish, and keeps trying. Every production agent needs three independent limits: a maximum number of turns, a maximum token or currency spend per task, and a wall-clock timeout. Hitting any limit must be a loud, structured failure that carries the partial state, not a silent stop.

Silent partial completion

The worst one, because it looks like success. The agent was asked to do five things, did three, and reported that the task is complete. There is no exception, no error rate spike, just a wrong result with a confident summary. The defence is to never let the model be the judge of its own completion: define done as a checkable condition in code, and verify it after the loop exits.

Swallowed tool errors

A tool returns an error, the model reads the error, decides it is not important, and carries on with a plan built on a missing fact. This one is your fault more often than the model's. Tool error messages are prompts: they must say what failed, why, and what a sensible next action would be. Returning a bare 500 or an empty list where an error occurred teaches the agent to hallucinate around the gap.

Unbounded cost through the retry multiplier

Cost in an agent is multiplicative, not additive. Longer context on each turn, times more turns, times retries, times concurrent users. A change that adds one extra tool result to the context does not add a few hundred tokens, it adds them to every subsequent turn of every task. Log per-task cost from day one, alert on the tail rather than the average, and treat a rising median turn count as a bug report.

How to scope your first agent

A checklist we actually use before committing to build one:

Name one task, narrowly. Not "an assistant for operations". Something like "given a failed webhook delivery, work out why and either fix the payload or open a ticket with the diagnosis".
Write the definition of done as code. If you cannot express success as an assertion, you cannot evaluate the agent and you should not ship it.
Count the tools. A first agent wants roughly three to seven tools. Below that, a workflow is simpler. Above that, the model starts picking the wrong one and you need to reconsider the split. Tool and memory design is most of the work, and we go into it in AI agent architecture: tools, memory and the loop.
Decide the blast radius. List every write the agent can perform, and for each one decide whether it is reversible. Irreversible plus automated is the combination to avoid.
Collect twenty real cases before you build. Pull them from support tickets and logs, including the ugly ones. These become your eval set, and twenty honest cases beat two thousand synthetic ones. That argument is in how to evaluate AI agents.
Set the budget before the first run. Turns, tokens, seconds, rupees per task. Numbers you will enforce in code, not aspirations.

Where the human belongs in the loop

The useful rule is to gate on blast radius, not on model confidence. Confidence scores from a language model are not calibrated in a way you can safely threshold on, and a well-written wrong answer looks exactly like a right one. Instead, classify each action the agent can take: reversible and cheap actions run automatically, expensive or irreversible ones require an approval step, and anything touching money, identity or customer-visible communication gets a human by default.

Approval fatigue is the counterweight. A reviewer clicking approve forty times a day is rubber-stamping, and you have bought nothing but a slower system. Batch approvals, show a clear diff of what will change, and move actions out of the gate once real traffic says they are safe.

Budgeting turns and tokens

Give every agent run a budget object and pass it through the loop. Track turns used, tokens in and out, and elapsed time, and make the remaining budget visible to the model in its context. Agents behave noticeably better when they know they have two turns left rather than discovering the limit by being cut off. When the budget runs out, hand back what has been done so far, in a structured form a human or a retry can pick up. Prices and model options move fast, so as of writing in August 2026, check current vendor pricing before you turn any of this into a spreadsheet.

What to do next

Take the task you were going to build an agent for and try to draw its flowchart. If you succeed, build the workflow instead.
If you cannot, write down the definition of done as a testable assertion, and the list of tools with their blast radius.
Gather twenty real inputs from your logs before writing any prompt.
Add turn, token and time limits on the first day, not after the first surprise invoice.
Put a human gate on every irreversible action until real traffic tells you otherwise.

We build and run this kind of system on a small, boring, serverless stack, and most of our advice comes from cleaning up after our own early enthusiasm. If you are weighing up an agent for a real product and want a second opinion on whether it is the right shape, talk to us and we will tell you honestly if a plain workflow would do the job.

Tags: Agentic AI, AI Agents, LLM, AI Engineering, Production AI

All posts · Work with Denshin