Agents doing operational work: analysing infrastructure, investigating logs, diagnosing deployments and triaging incidents. Here a wrong answer does not stay on a screen. It becomes a restarted service, a rolled-back release or an engineer sent down the wrong path at the worst moment. The field competes on whether you can build agents at all. The question that matters is whether the thing holds up in production, where a wrong autonomous action has a real operational cost.
An operations agent reads several systems that disagree, and its answer is only as good as how it settles them.
An operations agent starts from an alert or a question: why is this service slow, what changed before the errors began, which hosts are affected. It answers by calling tools. Each tool reads from a different system, such as the logs, the metrics store, the deployment history, the asset inventory or the ticket queue. The agent assembles what comes back into a picture, proposes a diagnosis, and sometimes proposes an action to fix it.
Each of those systems has its own clock, its own caching and its own idea of the truth. The inventory can list a machine as in service while monitoring stopped hearing from it some time ago. A deployment record can say a release completed while the logs show it rolling back. None of this is unusual. Reconciliation is the discipline of deciding, in advance, which source is authoritative for which kind of fact, how fresh a reading has to be before it counts, and what to do when two sources conflict. Often the right thing to do is to report the conflict itself, because the conflict is the clue.
The other half of the mechanism is restraint. A language model will produce an answer to any question it is asked, so the system around it has to decide when an answer is good enough to use. Confidence gating converts an uncertain answer into no answer and an escalation. A validation stage checks an action against the current state of the world before it runs, for example that the target still exists and is the one intended. And for actions that cannot be undone, a person approves. Rates matter differently at volume: a small error rate multiplied by a very large number of tool calls is still a count of real mistakes, and the design has to assume some of them will happen.
The agent layer is the visible part, and it is the smaller part. Around it sits the work most people skip: reconciling systems that disagree, confidence thresholds that return no answer when the alternative is a wrong one, validation stages before any real action, and the cost and observability work that decides whether the platform is viable at volume. That is the eighty percent that separates a demonstration from a platform, and no demo ever shows it.
Operational agents break on ordinary conditions, the ones a demo never stages.
A demonstration runs against clean systems that agree with each other, on a question the agent can answer, with an action that is easy to undo. Production offers none of those. Sources disagree, questions arrive half formed, and the obvious fix is sometimes the one that makes the outage worse. An agent built and tested only on the demo path fails the first time it meets the normal path.
The second failure is economic. A pilot handles a modest number of requests, so nobody looks hard at the cost of each call or at whether a given answer can be traced back to the calls that produced it. At production volume both become decisive. A platform that cannot account for its spending gets switched off, and one that cannot explain an answer gets ignored by the engineers it was meant to help.
The reflex, and the fix.
Build a proof of concept and scale it
The agent layer is the interesting part, it demonstrates well, and it is what the market asks about.
A proof of concept has no answer for two systems that disagree, a model that is unsure, or an action that cannot be undone. Those are the ordinary conditions of operational work.
Build the eighty percent
Reconciliation, confidence gating, validation stages, and the cost and observability work, all in place before scale.
A platform that survives production at volume, that abstains when it is unsure, and that puts a person in front of anything irreversible.
Build for the conditions that break agents, because the conditions that showcase them are not the ones they will meet.
Reconciling sources that disagree
Operational systems contradict each other as a matter of routine. An agent that trusts the first answer it receives is wrong systematically, in the direction of whichever system it happened to query first. So disagreement is detected and settled before any conclusion is drawn.
Thresholds that allow no answer
Returning nothing is a correct output. An agent that always answers is an agent that guesses, and in operations a guess turns into an action.
A validation stage between deciding and doing
A staged check sits between the decision and the change, so a wrong decision does not automatically become a wrong change.
A person in front of anything irreversible
The worst thing the platform can do on its own is stop.
Cost and observability treated as viability
At volume, the cost of each call and the ability to trace it decide whether the platform survives its own success. This is the work that gets cut first, and it is the work whose absence ends deployments.
What each choice cost, and what it bought.
AReconciling before reasoning
The quicker build lets the agent call whatever tools it likes and reason over whatever comes back. Settling disagreements first means deciding, for each kind of fact, which system is authoritative and how fresh it must be, and that is slow, unglamorous work done source by source. It buys an agent whose conclusions rest on a consistent picture of the estate. Without it the agent is not occasionally wrong. It is wrong in a predictable direction, and that kind of error is the hardest to notice because it looks consistent.
BMaking no answer a correct answer
Confidence thresholds mean some questions come back unanswered, which is uncomfortable for a product whose value is answering. The alternative is an agent that guesses, and in operations a guess gets acted on by a tired engineer or by the platform itself. A clear no answer, with the reason and an escalation, is something an engineer can work with. A wrong answer delivered confidently costs them the time it takes to discover it is wrong.
CSeparating deciding from doing, and gating the irreversible
Every real action passes a validation stage that checks it against the live state, and anything that cannot be undone waits for a person. This adds latency to every change and puts a human in a loop that a pure automation story would remove. It buys a ceiling on harm. The honest reading of under 0.4 percent hallucination at 1.9 million tool calls is that wrong answers will occur, so the design makes sure the worst outcome of one is that the platform stops and asks.
DDoing cost and observability work before scale
Measuring the cost of each call and tracing each answer back to its tool calls produces nothing a user sees. It is also the work that decides whether the platform is still running a year later. Building it early meant growth across 17 facilities did not arrive as a surprise bill, and an engineer who doubted an answer could see exactly how it was reached.
A single headline number hides where a system fails. This work was scored on the dimensions that actually decide whether it holds in production, measured on real, held-out cases rather than the demo path.
Figures confirmed as proven. The rendered client quote associated with this engagement is deliberately not published: the neuro-wearable review remains the only attested testimonial on the site.
An impressive agent that reconciles nothing, answers everything, acts without validation, and becomes unaffordable the moment it meets real volume.
A production agentic operations platform that reconciles disagreeing systems, abstains when confidence is low, validates before any real action, and carries the cost and observability work that keeps it viable. Running across 17 facilities, 1.9 million tool calls, and under 0.4 percent hallucination.
What it owns, and what it hands to a person.
The hallucination figure is a rate, never a guarantee, and the architecture is built on that assumption. A low rate at 1.9 million tool calls is still a meaningful count of wrong answers. That is exactly why everything irreversible sits behind a human approval gate.
Almost everything hard about agent reliability is already solved somewhere else: reconciliation, thresholding, staged validation, approval gates and cost accounting. The work is recognising which known problem is in front of you and using the answer that already exists.
Operational systems disagree with each other as a matter of routine, so an agent needs explicit rules for which source to trust before it reasons about anything.
An agent that cannot return no answer will guess, and in operations a guess becomes an action.
Keep deciding and doing as separate steps, and put a person in front of any action that cannot be undone.
A low error rate at high volume is still a count of real mistakes, and the architecture should limit what each one can cost.
Per-call cost and traceability decide whether an agent platform survives its own success, so build them before the volume arrives.