All articles

Errors should surface where they're made, not at the end

  • Agentic AI
  • Production

The most expensive failure in an agent chain is not producing a wrong output. It is a wrong output being taken for a right one and handed to the next step. The longer the chain, the bigger it gets and the harder it is to see where it came from.

In production we tied this down with a single rule: no step passes data onward until its output has been validated.

Free text is not an interface

When agents reach into internal systems, the most common mistake is interpreting the text the model produces. The model says "service restarted", the code tries to parse that sentence. One day the model says "I restarted the service" and the flow breaks.

The problem is not the model's inconsistency, it is the absence of a contract. Free text has neither defined fields nor types.

So every step's output gets a schema and the model is held to it:

{
  "action": "restart_service",
  "target": { "host": "APP-014", "service": "spooler" },
  "confidence": 0.86,
  "requires_approval": false
}

There is no longer a sentence for the code to interpret. action comes from a known set, target can be verified, confidence can be compared against a threshold.

Matching the schema isn't enough

An output can be structurally valid and still meaningless: a hostname that does not exist, a service not present on that machine.

Three layers do separate work.

Structural validation checks that fields exist and types match. Cheap and deterministic; on failure we hand the error back to the model and let it try again.

Semantic validation asks whether host actually exists in inventory and whether service is defined on it. Here the system's own records decide, not the model.

Authorisation asks whether the agent is permitted to take this action on this machine. That check is never left to the model - it sits outside the contract, in the call layer.

An output that fails any of the three does not move on.

The threshold is where trust ends

The confidence field means nothing on its own. It is the model's own estimate and it is not calibrated. What gives it meaning is tying it to a threshold.

Where the cost of being wrong is low the threshold can stay low - if log collection misfires, the cost is running it again. Where the cost is high, like a configuration change, anything under the threshold goes to a person.

That turns human approval from a bottleneck into a valve that opens and closes with cost.

You can't loosen what you don't measure

Schema validation catches errors but does not improve anything by itself. For that you need to know which step fails and how often.

We keep three numbers per step: validation failure rate, retry count, escalation rate.

Looking at all three together tells you whether the problem is the prompt or the schema. If the model keeps stumbling on the same field, the issue is usually not the prompt - it is that the schema never made clear what it wanted from that field.

What helped when moving agent systems into production was not better prompts but narrower contracts. The more freedom the model gets, the later its mistakes become visible.

More articles