Agentic AI moved from research demo to board-level priority faster than any category we have worked in. Survey after survey now puts autonomous agents near the top of enterprise technology priorities, and most large companies are running some already. What the surveys are quieter about is how many of those agents are pilots that never widened, or a single automation with an ambitious name.
We build these. Here is the pattern we see in the ones that make it to production.
An agent is a loop with permissions, not a personality
Strip away the framing and an agent is a model in a loop: it has a goal, a set of tools it can call, a way to observe what happened, and a rule for when to stop. That is the whole idea. Everything that determines whether it works in production is in the boring parts of that sentence, the tools and the stopping rule, not in the model.
Which means the first design question is never “which framework”. It is: what exactly is this thing allowed to do, and what happens when it does the wrong one?
The projects that ship start narrow enough to be embarrassing
The agent projects that reach production almost always start smaller than the client initially wanted. Not “an agent that handles customer support”, but “an agent that handles refund requests under $50 for orders that shipped in the last 30 days”. Not “an agent that manages procurement”, but “an agent that matches incoming invoices to purchase orders and flags the ones that do not match”.
This is not timidity. A narrow scope is what makes the two hard parts tractable: you can enumerate the tools, and you can write down what a correct outcome looks like. Gartner’s read that most multi-agent deployments will end up built from narrowly specialized agents matches what we see on the ground. Broad autonomy is not a stage you graduate to. Narrow agents that work are the product.
Tools are the actual engineering
The model is a commodity you rent. The tools are what you build, and their quality determines almost everything.
A good tool for an agent has a narrow, unambiguous contract, validates its own inputs rather than trusting the model, returns errors the model can act on instead of a stack trace, and is idempotent wherever it touches the world, so a retry does not issue the refund twice. Most agent failures we are called in to debug are not reasoning failures. They are a tool that silently accepted nonsense, or an operation that ran twice because the loop retried after a timeout that had actually succeeded.
Read-only tools are cheap to get wrong. Anything that writes, sends, charges, or deletes needs to be treated as the dangerous thing it is.
Where humans belong in the loop
The useful question is not whether to keep a human involved but where to put them, and the answer depends on the cost of being wrong.
Reversible and cheap, like drafting a reply or tagging a record: let it run and sample the output for review. Expensive or irreversible, like issuing a payment, emailing a customer, or changing a production record: the agent prepares the action and a human approves it. High volume with occasional high stakes: run automatically inside defined bounds and escalate outside them, which is exactly the confidence-threshold review queue we build into document intake pipelines.
The mistake is treating human review as a temporary phase to be removed once the agent is trusted. In most business processes the review queue is the product, and the agent’s job is to make it short.
What you have to build around the loop
The parts of an agent system that take the most work are the parts that are not the agent:
- A trace of every run. Which tools were called, with what arguments, what came back, what it decided. Without this you cannot debug a bad outcome, and you will have bad outcomes.
- Hard limits. Maximum steps, maximum spend, maximum tool calls per run. An agent in a bad loop is a bill and an outage at the same time.
- An evaluation set. Recorded real cases with known correct outcomes, run on every prompt or model change. The same discipline RAG systems need, for the same reason: without it you cannot tell an improvement from a regression.
- A kill switch. One flag that stops all agent activity, owned by someone in operations, not buried in a deploy.
- Cost per completed task. Not tokens. The number a finance team can compare against what the task costs today.
When an agent is the wrong shape
Plenty of the work being labeled agentic is not. If the sequence of steps is fixed and known, that is a workflow, and a workflow written as ordinary code is faster, cheaper, fully testable, and does not occasionally decide to do something else. Agents earn their overhead when the path genuinely varies by case, when the input is unstructured, or when the number of possible branches is too large to enumerate.
We say this to about a third of the people who come to us asking for AI, because the simpler build is often the better one and we would rather say so on a free call than six weeks in.
If you have a process where the path really does vary case by case, that is worth a conversation. See our AI development services, or get an estimate: free scope call, written quote in 48 hours.