If you have built one of these for production, you already know the ratio. Getting a model to draft a plausible response to a support ticket, code an invoice, or classify a document takes an afternoon. Getting it to production takes months, and almost none of that time goes into the part that looked like the product.
It goes into two components that never appear in a demo: the gate that decides whether output ships or escalates, and the audit trail that lets you explain the decision six months later.
This is a note on building the first one properly.
What the gate actually is
A useful agentic workflow has four properties: a defined input trigger, a bounded set of permitted actions against real systems, a validation gate deciding whether output ships or escalates, and a complete record of every decision and tool call.
The gate is not a confidence threshold on a model score. That is the naive version, and it fails for a specific reason: token-level probabilities are not calibrated to task correctness. A model can be extremely confident and wrong, particularly on inputs that resemble its training distribution but differ in a business-critical detail — the deviation in clause 14, the account flagged as enterprise, the code combination that is valid but unusual.
A gate that works is a composition of cheap independent checks, most of which are not model calls at all:
verdict = ship
if structural_valid(output) # schema, required fields, referential integrity
and within_policy_bounds(output) # amount ceilings, permitted action set, blast radius
and consistent_with_source(output) # every claimed fact traceable to retrieved input
and not matches_escalation_rule(input) # explicit carve-outs: VIP, legal hold, dispute
and self_check_passed(output) # a second model call, adversarially prompted
else escalate
Ordering matters for cost. Put the deterministic checks first — they are free and they catch the majority of genuine failures. The model-based self-check goes last, on the minority of cases that survive, because it roughly doubles your per-transaction inference cost when it runs.
Explicit carve-outs beat clever thresholds
The single highest-value component is the boring one: matches_escalation_rule.
A hand-maintained list of conditions that always route to a human regardless of how confident everything else is. Disputed accounts. Anything with a legal hold. Amounts above a ceiling. Customers flagged as sensitive. Any input where a prior attempt was overturned.
This list is where domain expertise actually enters the system, and it is the thing your business owner should own directly and be able to edit without a deployment. Every incident post-mortem adds a line to it. It grows for the first six months and then stabilises, and its growth curve is a decent proxy for how well you understood the process at the start.
The temptation is to replace it with a smarter model. Resist that. A rule you can read, test, and explain in an audit is worth more than a marginal accuracy gain you cannot account for.
Tune the threshold with evidence, not judgement
Ship with the gate deliberately too conservative. Escalate most cases in week one. This feels like failure and is not — it is how you collect the labelled data that lets you tune honestly.
Every escalation produces a human decision. Log the pair: what the system would have done, what the human actually did. After a few thousand pairs you can compute, for any candidate threshold, the agreement rate and the cost of the disagreements. Now the tuning decision is empirical rather than a product manager's intuition.
Two things to watch:
- The two error types are not symmetrically expensive. A false escalation costs you a few minutes of human time. A false ship can cost a customer relationship or a regulatory finding. Tune for the asymmetry explicitly rather than optimising a single accuracy number.
- Week one and month three differ substantially. Resolution rate rises as you fix the failure modes the escalations reveal. Anyone quoting a single accuracy figure for a production system without specifying when it was measured has not watched one mature.
The audit trail is a product requirement, not logging
For each transaction, persist: the input, everything retrieved, the full prompt, the raw output, every gate check with its result, the final verdict, and — for escalations — the human decision. Keyed to the business record, queryable, retained per your policy.
Two reasons this cannot be deferred. First, when a workflow misbehaves at 2am, an engineer needs to reconstruct exactly what the system saw and why it decided as it did. Application logs will not do it. Second, in any regulated context you will eventually be asked to explain a specific decision about a specific person, possibly a year later, and the answer needs to be evidence rather than a description of your architecture.
Retrofitting this after go-live is one of the more expensive mistakes available, because the interesting transactions are already gone.
Evals, or every change is an uncontrolled experiment
You need a regression suite of real cases with expected outcomes, run on every prompt change, model change, and retrieval change.
Not synthetic cases. Real transactions with known correct outcomes, including every case that has ever failed in production — each incident should add a permanent test. Fifty well-chosen cases beat five hundred generated ones, because the value is in covering the failure modes you have actually encountered.
Without this, a provider deprecating a model version becomes a production emergency instead of a Tuesday.
The workflows worth building first
Not every process is a good candidate, and the profile is fairly specific:
- High volume, moderate complexity — thousands per month, each currently five to forty minutes of human time
- Verifiable ground truth — you can tell afterwards whether it was right, which is what makes measurement and improvement possible at all
- An existing escalation path — someone already handles exceptions; you are not inventing that capability
- Structured or semi-structured input — documents, tickets, forms against a known schema
- A measurable current cost per unit, so the savings claim is arithmetic rather than narrative
Anything failing this profile should be later in the roadmap, however strategically important it feels. You cannot tune a gate without a safe failure mode, and you cannot measure improvement without volume.
Full writeup, including 2026 US cost benchmarks and the compliance constraints that shape all of this: Digital Transformation Company in USA: How to Choose the Right Partner in 2026.
We build these systems at TechCirkle — agentic workflow development and LLM integration.
Frequently Asked Questions
What is an escalation gate in an agentic workflow?
It is the component deciding whether the system acts on its own output or routes the case to a human. Practically it is a composition of cheap deterministic checks — schema validity, policy bounds, source consistency, explicit carve-out rules — with an optional model-based self-check last. It is not simply a confidence threshold, because token probabilities are not calibrated to task correctness.
Why shouldn't I use model confidence scores as the gate?
Because a model can be highly confident and wrong, especially on inputs that closely resemble its training distribution but differ in a business-critical detail. Confidence measures fluency, not correctness. Deterministic checks against schema, policy limits, and traceability to retrieved source catch a far higher share of real failures at zero inference cost.
How do I choose the right confidence threshold?
Ship deliberately conservative so most cases escalate, then log every pair of what the system would have done and what the human actually did. After a few thousand pairs you can compute agreement rate and disagreement cost for any candidate threshold. Tune for the asymmetry between error types — a false escalation costs minutes, a false ship can cost a customer or a regulatory finding.
What should an audit trail for an LLM workflow contain?
The input, everything retrieved, the full prompt, raw output, every gate check with its result, the final verdict, and the human decision for escalated cases — all keyed to the business record and queryable. This is a product requirement rather than logging, because debugging a 2am failure and explaining a specific decision a year later both need evidence rather than an architecture description.
How many eval cases do I need?
Fifty well-chosen real cases beat five hundred synthetic ones. Use actual transactions with known correct outcomes, and make every production incident add a permanent test case. The purpose is covering failure modes you have genuinely encountered, so that a model deprecation or prompt change becomes a routine regression run rather than an emergency.
How much does the self-check step add to cost?
Roughly double the per-transaction inference cost on the cases where it runs, which is why it belongs last in the chain — after the free deterministic checks have already filtered most of the traffic. Ordering the gate by cost rather than by conceptual tidiness is one of the easier optimisations available.
Which processes make good first candidates for agentic automation?
High volume with moderate complexity, verifiable ground truth after the fact, an escalation path that already exists, structured or semi-structured inputs, and a current cost per unit you can already measure. Support triage, invoice coding, and document classification usually qualify. Low-volume, high-stakes processes with no existing exception path should come much later.
Top comments (0)