Agentic loops - Guardian pattern: Reference architecture

Put together, the pieces form what I call a guardian pattern. The actor never decides on its own whether to stop. A separate evaluator answers typed questions about the state, and plain code turns those probabilities into actions.

I have chosen to write it as an architecture decision record, the format I would use to bring this to an architecture board. The options set aside matter as much as the diagram. They are what the next engineer will question the day an agent stops one step too early, or does not stop at all.

Context

An agent is a loop. A reasoning model proposes an action, tools execute it, the state changes, and something decides whether to go around again. In most implementations that something is an iteration cap, the actor’s own verdict, or both.

Production failures cluster exactly there. Loops spin on the same call, drift away from the goal, burn budget, follow instructions planted in a tool result, or declare success one step early. None of these is a reasoning failure of the actor. Each is a failure of the stop decision.

The constraints are specific:

• Per-turn latency. The check runs on every iteration. Adding seconds to each turn turns a ten-step task into a coffee break.
• Cost linearity. Runs take dozens to hundreds of turns. Whatever the check costs is multiplied by the turn count.
• Semantic judgment. Drift, stagnation and injected instructions cannot be detected by rules on the transcript. The check has to understand the state.
• Explicit risk appetite. A risk function, an auditor or a supervisor will ask why the agent stopped, or did not. The answer must be a stated threshold, not a model’s mood.
• Independence. The component that acts cannot be the only one that judges its own progress.
• Evolvability. Evaluator models change every quarter. The design must survive a model swap without rewriting the loop.

Until recently, the semantic judgment and the per-turn economics pulled in opposite directions. System One models, a category TypeSafe AI introduced with Jev on 15 September 2026, remove that tension: unstructured state in, typed answers with calibrated probabilities out, in one parallel call. TypeSafe reports 70 to 500 ms per call and $0.042 per million input tokens, with output free. These are vendor figures, measured from their own region.

Architecture at a glance

Decision drivers

1. D1, coverage. Every turn is checked against every breaking condition. Sampling one turn in ten is not coverage.
2. D2, independence. The decision to stop is not taken by the model that acts.
3. D3, calibrated output. Each condition returns a probability whose meaning is stable enough to set an explicit threshold on.
4. D4, deterministic control flow. Branching happens in code. The evaluator cannot invent an outcome or return malformed output.
5. D5, auditability. Any turn can be replayed: same inputs, same probabilities, same outcome, with the model version that produced them.
6. D6, cost and latency. The check costs a small fraction of an actor turn, and the loop has no hard dependency on a single vendor.

Considered options

• O1, iteration and budget caps only. The loop stops after N turns or when tokens, time or cost exceed a limit.
• O2, self-assessment by the actor. The actor ends each turn with a verdict, or calls a finish tool, when it considers the task done.
• O3, a System 2 judge on every turn. A separate reasoning LLM reads the state each turn and returns a structured verdict.
• O4, a System One guardian with a threshold policy. A decision model answers one typed question per condition in a single parallel call. Code maps the probabilities to an outcome, and the uncertain band escalates to a System 2 judge or a human.
• O5, rules and bespoke classifiers. Heuristics such as repeat detection and goal-embedding similarity, plus a classifier trained per condition.

D5 does not appear in the table on purpose. Auditability is delivered by the decision log, which is the same whichever option is chosen.

Decision

We adopt O4. On every turn, a System One guardian answers one typed question per breaking condition in a single parallel call over a bounded projection of the loop state. A threshold policy, written as a pure function in code, maps those probabilities to exactly one outcome: continue, replan, escalate or stop. Budget caps and exact-repeat detection stay in the policy as plain code, as in O1 and O5, because they need no judgment and Jev’s own jaggedness notes flag numbers as a weak spot.

O3 is not discarded. It is scoped to the uncertain band, where a slow, expensive judgment is worth paying for. The guardian sits behind a narrow interface, state and question set in, typed probabilities out, so a condition can move to an open-weight decision model or to an O3 judge without changing the actor or the policy.

Breaking conditions

Risk is the only pre-execution check. The actor’s proposal is written to the state, the guardian classifies it, and the policy gates the tool call before it runs. Detecting an irreversible action after it has happened is not a control.

Thresholds

Each threshold comes from the relative cost of the two errors. If a false stop costs C_stop and a false continue costs C_cont, the condition should fire when p · C_cont > (1 − p) · C_stop, which gives:

t^{*} = \frac{C_{\text{stop}}}{C_{\text{stop}} + C_{\text{cont}}}

A probability within δ of t* is the uncertain band, and always escalates. The band sits around the threshold, not around 0.5, because that is where a wrong answer flips the outcome. Both t* and δ are set per condition and versioned with the question set.

Precedence

When several conditions fire on the same turn, the policy applies a fixed order: escalate before stop, stop before replan, replan before continue. A turn where goal reached and integrity both fire therefore escalates, which is the conservative reading.

Three paths share a single decision log. On the acting path, the actor proposes, tools execute and the state records the result. On the judging path, the guardian reads the state and the policy decides, in code, what happens next. On the learning path, every probability and every escalation outcome lands in the trace set that recalibrates thresholds offline.

Components

The eval harness deserves a word of its own, because it is the component teams most often forget. The guardian is a black box that returns a number, never a reason. A threshold on an unmeasured probability is a guess with a confidence score. The harness is what turns “the model says 0.83” into “on our traces, 0.83 is right about 83% of the time”.

Consequences

What gets better

• Every turn is checked against every condition, on meaning rather than on a count.
• The decision to stop is independent of the model that acts, which removes self-grading from the loop.
• Risk appetite becomes explicit: each threshold is a number derived from a stated cost ratio, which a risk function can review and sign off.
• Control flow is deterministic and replayable: the same probabilities always produce the same outcome.
• Irreversible actions are gated before they run, not discovered afterwards.
• The system improves with use, because every escalation becomes labelled ground truth.

What it costs

• A labelled trace set must exist before go-live and be maintained afterwards. Building it is the largest upfront cost, larger than the integration itself.
• Question design becomes a discipline of its own. Questions are code: versioned, reviewed, tested, and a reworded question is a new model of the condition.
• The escalation channel must be staffed. A δ too wide floods reviewers; a δ too narrow hides exactly the errors it should catch.
• A new vendor dependency, in early access and served from a single region, mitigated by the guardian interface and a fallback judge behind it.

Residual risks

• No rationale per decision. The guardian returns a probability, never a reason. Explaining a single stop relies on replay and counterfactual probing: vary the state, observe how the probability moves.
• Adversarial content. TypeSafe documents adversarial inputs as a weak spot. The integrity check is one layer, never the only defence against injection: tool outputs stay data, and tool credentials stay least-privilege.
• Correlated errors. If guardian and actor fail on the same inputs, independence is weaker than it looks. Measure the overlap of their errors on the trace set.
• Calibration drift. Calibration measured offline does not survive a change in task mix. Monitor the distribution of probabilities and the escalation rate in production, per condition.

When to revisit

• Open-weight decision models match the guardian’s calibration on our trace set: re-evaluate self-hosting for cost and data residency.
• The escalation rate stays above what the escalation channel was staffed for: revisit δ, question design, or the model.
• Per-turn cost and latency of System 2 judges fall far enough for O3 to meet D6 on every turn.
• A supervisor or internal audit requires a stated rationale for each automated decision, which a score-only judge cannot provide.
• The vendor’s pricing, availability or terms change materially.

Questions for your architecture board

Whatever you end up building, these are the questions I would want an architecture board to ask of it:

• Is every turn checked against every breaking condition, or only some turns and some conditions?
• Is the component that decides to stop independent of the one that acts?
• Is each threshold written down, together with the cost ratio it comes from?
• Is calibration measured per condition on labelled traces, and measured again on every model or question change?
• Is every irreversible or regulated action gated before execution rather than detected after it?
• Can any turn be replayed, with the same inputs producing the same probabilities and the same outcome?
• What happens when the evaluator times out or is unavailable: does the loop fail open or fail closed?
• Are tool outputs treated as data, and never as instructions?

What changes

We started with an agent that knew how to act but not how to stop, and with a simple observation: an agent that grades its own homework will always pass. This design gives the stop decision to an independent judge, puts the threshold in code where people can read it, and turns every hard case into evidence for the next calibration.

None of the building blocks is new: a loop, a classifier, a threshold, a log. What is new is a model fast and cheap enough to ask the right questions on every single turn. What makes the difference is deciding, from the very first sprint, that knowing when to stop is a requirement like any other. If you have built something similar, or chosen differently, I would genuinely love to hear how it went.