Sean Weldon
September 21, 2026
8
min. read
and updated on:
September 22, 2026
An AI agent is a system where a language model decides which actions to take and executes them through tools rather than only producing text. That definition sounds modest and hides the entire difficulty: the moment a model can act, every mistake it makes has consequences beyond a bad paragraph.
Agent projects fail on reliability, not capability. A demonstration works because a human chose a good example. Production fails because real inputs are messy, and a system that succeeds 85 percent of the time is unusable for anything consequential while being extremely impressive in a meeting.
This is what actually works.
The reliability arithmetic that governs everything
Consider a workflow of six steps, each of which the model performs correctly 95 percent of the time. The probability of the whole chain completing correctly is roughly 74 percent. At ten steps it falls to about 60 percent.
That arithmetic is the reason ambitious agent projects disappoint. Nothing is broken. Each component is performing well. The compounding is what fails.
Three consequences follow directly, and they shape every good agent design. Fewer steps is better than more. Deterministic code should handle every step that does not require judgement. And any step with real consequences needs verification, either programmatic or human.
The pattern that works: constrained agents over open-ended ones
Successful production agents look less like an autonomous assistant and more like a workflow with model-powered decision points.
Concretely: the process structure is written in code, so the sequence and the guardrails are deterministic. The model is called at the points where judgement is genuinely required, classifying an item, extracting fields, choosing among a small set of paths, drafting content. Tools are few and narrowly scoped. Every model output is validated against a schema before it is used. Consequential actions require confirmation. And the whole run is logged step by step so failures can be diagnosed.
This is far less exciting than an agent that plans its own approach, and it is what survives contact with users. The design instinct worth internalising is that autonomy is a cost, not a feature. Give the model exactly as much latitude as the task requires and no more.
Where agents genuinely earn their cost
Document and data processing pipelines. Ingest something unstructured, classify it, extract the fields that matter, validate them, route the result. Invoices, applications, claims, contracts, inbound support requests. High volume, measurable accuracy, and a clear comparison against the manual cost.
Triage and routing. Reading an incoming item and deciding where it goes and how urgently. The consequence of an error is a misroute rather than a disaster, which makes it a good fit for a system that is very good rather than perfect.
Multi-source research and summary. Gathering information from several systems and producing a briefing. Read-only, which removes most of the risk, and genuinely time-saving.
Draft-then-approve workflows. The agent prepares the work and a person approves it. This pattern converts a reliability problem into a productivity gain, and it is the highest-return agent shape available to most companies.
Where agents currently disappoint
Long autonomous chains with no checkpoints. See the arithmetic above.
Irreversible actions without confirmation. Payments, deletions, external communications, and anything a customer sees. If it cannot be undone, a human confirms it, at least until you have measured accuracy over months.
Tasks requiring precise calculation. Language models are unreliable arithmetic engines. Give them a calculator tool or perform the calculation in code. Anything financial belongs in deterministic code.
Workflows over systems with poor APIs. If the agent must operate through a brittle interface or by driving a user interface, the fragility of that layer will dominate every other consideration.
Scoping an agent project
| Question | Why it decides feasibility |
|---|---|
| How many steps does the workflow have? | Reliability compounds downward with each one |
| Which steps need judgement? | Everything else should be code |
| What is the cost of a wrong action? | Determines where confirmation is mandatory |
| Do the required systems have real APIs? | No API means the project is an integration project |
| Can success be measured objectively? | Without a metric there is no way to improve it |
| What is the manual cost today? | Establishes whether the build pays back |
Answer those six before design begins. Projects that skip them tend to discover in month three that the workflow has fourteen steps, two of the systems have no API, and nobody agreed what accuracy would be acceptable.
Contrary to how agent capability is usually pitched, the strongest predictor of a successful agent project is a narrow scope with an objective success metric. Ambition correlates negatively with shipping in this category.
Engineering requirements specific to agents
Tool definitions that are hard to misuse. Each tool needs a precise schema, validation on every parameter, and permissions scoped to exactly what it needs. A tool that can query anything will eventually query the wrong thing.
Step-level observability. You need a trace of every run: what the model saw, what it decided, which tools it called with which arguments, what came back. Without this, debugging is guesswork, and agents fail in ways that are invisible from the outcome alone.
Loop and cost limits. Maximum iterations, maximum tokens per run, maximum wall-clock time. Agents that reason in a loop can loop indefinitely, and the failure mode is a bill.
Idempotency and state. A run that fails at step five must be safely resumable or safely abandonable without duplicating the effects of steps one through four.
Injection resistance. Where the agent reads untrusted content, incoming email, uploaded documents, web pages, that content can contain instructions. Keep instructions structurally separate from data, restrict tool access, and never let model output trigger a consequential action without validation.
Bolder Apps builds backends in Node.js and Laravel and prices project work fixed-scope rather than hourly, and the reason the pricing model is relevant to agent work in particular is that reliability improvement is an open-ended activity. Agents can always be made a little better, and a defined scope with an agreed accuracy target is what stops the project from becoming permanent.
The team an agent project actually needs
Agent projects are frequently staffed as machine learning work and are mostly not. The skills that matter, in order of how much they affect the outcome.
- Backend engineering with distributed systems instinct. Agents are asynchronous, multi-step, partially failing systems. Retries, idempotency, queueing, state machines, and tracing are the core competencies, and they are ordinary senior backend skills rather than specialist ones.
- Domain understanding of the workflow. Someone has to know which steps require judgement and which are rules, and which errors are recoverable. This is usually the client's operations lead rather than anyone on the engineering side, and their availability is a project dependency.
- Integration experience with the target systems. The tools the agent calls are integrations, and integration quality bounds agent reliability.
- Prompt and evaluation discipline. Not a job title, but someone has to own the test set and the measurement, or quality becomes anecdotal.
Machine learning research skills are genuinely useful for custom model work and largely irrelevant to API-based agents. Hiring for the wrong profile is a common and expensive mismatch.
Rolling out an agent inside an organisation
Even a technically sound agent fails if the people whose work it touches were not part of the design. Three things reduce that risk.
Show the trace to the operators. A queue where staff can see what the agent decided and why, with the ability to correct it, converts suspicion into training data and surfaces failure patterns you would otherwise never see.
Frame it as removing a task rather than replacing a role, and mean it. Agents built without the cooperation of the people who perform the work today tend to be quietly bypassed.
