A Circuit Breaker the Agent Can Read: What the Model Sees at Trip

Four properties of the trip message push a model toward re-rolling the same call.

It is ambiguous. A write-up on stopping reasoning loops names "ambiguous tool feedback" as a root cause of loops, alongside unclear goals and missing stopping criteria. A message like "The tool call failed. Please try again." is exactly that: partial, non-terminal, and suggestive of another attempt.

It implies the failure was transient. If the message describes a timeout or a 500, the model has been trained by experience to retry, because those often do resolve. A breaker-open result is not transient in the same way. It represents a breaker decision, not the last raw error.

It carries no state change. The model's plan was built on the assumption that the target is callable. If the tool result does not say the target is now unavailable for a defined window, the assumption survives and the plan does not change.

It buries the actionable part. Long outputs that open with apology, stack traces, or an embedded upstream error body push the one fact that matters past the part the model is most likely to act on.

Ambiguous feedback compounds. A study of infinite agentic loops analyzed 6,549 LLM agent repositories with a static tool and confirmed 68 loop failures across 47 projects, at 91.9% precision. The authors define the failure as a feedback path that repeatedly triggers model calls, tool invocations, or workflow transitions without an effective termination condition. They also note that framework limits such as max iterations exist but are often missing, misconfigured, or placed outside the actual feedback path. A trip message is part of that feedback path.

Return a short structured block with these fields, in this order:

A stable breaker code matters more than it looks. Agents recover better when the observation is machine-parseable and consistent across turns, and it lets you join model behavior to your breaker metrics later. Give it a name a human would recognize in a log line, not a hash.

The signal field is where most teams lose the plot by pasting raw errors. Signal should be a short category: error_rate, latency, auth_failure, quota_exhausted, malformed_response. Each implies a different repair. An auth failure means the agent should stop and escalate rather than route around, because retrying with a different endpoint will not fix a credential. An error rate means fall back. A latency trip means reduce payload or await recovery. A guide to LLM tool calling error handling makes the same routing distinction for tool errors: transient infrastructure faults belong to the orchestration layer and should not be surfaced to the model, while input validation and application-level logic failures belong to the model, which must reason and correct its request.

That split is the clearest decision rule in this whole design:

• Transient network fault: retry silently inside the harness, do not tell the model.
• Breaker tripped: tell the model, with the full contract, because the plan itself must change.
• Bad input from the model: return the schema error and let it correct itself.

Take an agent that reconciles invoices. Its plan is: read the ledger, call the payments API to charge, then write to the warehouse.

The payments API starts failing. The breaker opens after three failed probes.

Payload A, the weak version:

{
  "error": "Tool call failed. The payments API returned an error. Please try again."
}

What the model sees: a failed call with no persistent state. It has no reason to abandon the plan. A plausible next step is to call the same tool with slightly different parameters, which the breaker then blocks again. The orchestrator absorbs two more trips, and the model spends tokens reasoning over errors that add no information.

Payload B, the contract version:

{
  "action": "switch_to_fallback",
  "breaker": "payments_api_v2",
  "target": "POST /v2/charge",
  "signal": "error_rate",
  "observed": "9/10 failed in last 60s",
  "threshold": "trip at 3 failures in 30s",
  "state": "open until 14:02:10Z, then half_open",
  "do_not": "retry same endpoint before half_open",
  "fallback": "payments_api_v1, same request shape"
}

Now the model has a state change, a deadline, a named alternative, and a prohibition. The natural next step is a different tool call to a different endpoint. The plan is repaired rather than repeated.

The numbers do the persuasive work. "9/10 failed in last 60s" tells the model this is not a blip. "trip at 3 failures in 30s" tells it the harness will not let it brute-force through. "open until 14:02:10Z" tells it time is the constraint, not wording.

One caution on the timestamp: a concrete time is useful, but only if your clock is trustworthy and the agent does not have to compute durations. Prefer including both the absolute time and a relative hint ("about 40 seconds from now") so the model does not have to do arithmetic across time zones.

The trip payload competes for attention with the whole history: the user request, the system prompt, prior tool output, the plan. Field order is not cosmetic.

Put action first. Models condition on the opening of an observation when deciding what to do next, and the first token of a repair-shaped observation is more likely to produce a repair. Bury the next step in paragraph four and a model may treat the payload as a status note.

Keep the total payload small. Every trip message is re-sent in context on the next turn, and on every turn after, so a verbose diagnostic block taxes the whole remainder of the run. Strip stack traces, upstream request ids, and full response bodies. Log those in the orchestrator. The model needs the state and the next step, not the evidence trail.

There is a real cost tradeoff here. One analysis of operational breakers for agents warns that validation overhead, the verification work needed to catch failures that look like successes, can exceed 200% of execution cost. That is an argument for a payload that is cheap to produce and cheap to keep: a fixed set of fields drawn from data the breaker already tracks, not a generated narrative.

Set a hard length budget in the harness. If the rendered block exceeds it, something is wrong with the payload generator.

The contract should not assume every trip ends in a fallback. Four signals, four different next steps:

Auth and malformed-response trips are the ones teams most often mis-label as retryable. A practical guide to error handling for LLM calls groups 4xx client errors as "your fault, do not retry" and 429 and 5xx as retry candidates. A breaker carries the same distinction one level up. If your breaker trips on an auth failure, the payload must say so, or the model will do what it does with any error: try again.

Escalation is a legitimate agent outcome, not a failure of the automation. Research on triaging agent failures by priority puts crashes, stuck loops, wrong output, and rate limits on different urgency profiles, and rollback or corruption cases above all else. Your action field should map onto that same ladder so an operator reading logs later can see what the agent was told.

The payload should be generated by the same component that owns the breaker, so the state and the observation can never drift apart. A sketch:

def breaker_result(breaker, call, decision):
    return {
        "action": decision.next_step,
        "breaker": breaker.code,
        "target": call.endpoint,
        "signal": decision.signal,
        "observed": decision.observed_text,
        "threshold": breaker.threshold_text,
        "state": decision.state_text,
        "do_not": decision.prohibition,
        "fallback": decision.fallback_name,
    }

Then test it. Measure three things per breaker code:

• Repeat rate. How often the model calls the same tool with the same arguments after an open trip. The baseline is usually worse than teams expect, and this number is your primary success metric.
• First-action match. How often the model's next tool call matches the action field. Low values mean the payload is being read but not trusted, often because the field order or wording is weak.
• Turns to recovery. Median remaining steps after a trip. This catches improvements that reduce repeat calls but leave the model wandering.

A before-and-after comparison on one breaker, run over a few hundred trips, tells you more than any amount of prompt debate. Keep a copy of the old payload variant and A/B it.

Where the human side matters, the same discipline applies. On-call practice already expects that every page needs a clear, actionable message, and that escalation paths never dead-end; a guide to on-call schedules and handoffs treats a clean handoff and a non-dead-ending escalation policy as core mechanics. A breaker trip is the machine equivalent of a handoff, and it fails the same way when the recipient cannot tell what to do next.

If your team is designing the model layer and the orchestration layer together, especially across more than one model vendor, Quanta Inference puts text, image, video, audio, and embedding models behind one OpenAI-compatible endpoint, which keeps the trip payload contract identical regardless of which model answers next.