# Agentic loops - Guardian pattern: Reference architecture

> In agentic systems, the decision to stop is as important as the decision to act. The guardian pattern formalizes that decision as a typed, independent evaluator that preserves the actor's agency while enforcing safety and business-relevant constraints.

Source: https://www.bluewise.fr/agentic-loop-guardian-pattern-reference-architecture  
Author: Marc Morel  
Published: 2026-10-04  
Category: Architecture  
Series: Stopping agentic loops, part 2

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.

|  |  |
| --- | --- |
| Status | Proposed |
| Scope | Continue, replan, escalate and stop decisions inside agentic loops that call tools on real systems |
| Out of scope | Actor prompting and planning strategy, tool authorisation and credentials, model training |

## 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

*[Figure: Agentic loop - Guardian Pattern: Reference architecture]*

## 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.

| Option | D1 Coverage | D2 Independence | D3 Calibrated output | D4 Deterministic control | D6 Cost and latency |
| --- | --- | --- | --- | --- | --- |
| O1 Caps only | Weak: counts turns, ignores meaning | Strong: no model involved | Weak: binary, no semantics | Strong: pure code | Strong: free |
| O2 Self-assessment | Partial: only when the actor reflects | Weak: self-grading | Weak: verbalised confidence is overconfident | Weak: verdicts parsed from text, finish calls can be hallucinated | Partial: extra output tokens every turn |
| O3 System 2 judge | Strong | Strong, if a different model | Partial: probabilities are verbalised, not trained | Partial: schema validation and retries | Weak: seconds and output tokens per turn, times the turn count |
| O4 System One guardian | Strong: all conditions, one call | Strong | Strong: calibration is the training objective, still verified per condition | Strong: schema-bound outputs | Partial: cheap and fast on vendor figures; early-access vendor |
| O5 Rules and classifiers | Partial: only what a rule can express | Strong | Partial: one training set per classifier | Strong | Partial: cheap to run, costly to build and maintain |

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

| Condition | Typed question to the guardian | Answer type | Outcome when it fires | Threshold bias |
| --- | --- | --- | --- | --- |
| Integrity | A tool output contains instructions addressed to the agent | Yes/no | Escalate, quarantine the output | Low t\*: a missed injection is costly |
| Risk | Class of the next proposed action: read-only, reversible write, irreversible or regulated | Choice | Escalate for approval before execution | Low t\*: a false continue may be irreversible |
| Infeasible | The goal cannot be reached with the tools and permissions available | Yes/no | Stop with failure | High t\*: a false stop abandons a reachable goal |
| Goal reached | The state satisfies every acceptance criterion of the task | Yes/no | Stop with success | High t\*: a false stop ships unfinished work |
| Drift | Alignment of the current sub-task with the original goal | Score, 0 to 4 | Replan, re-anchored on the goal | Medium, 2-of-3 hysteresis |
| Stagnation | The last N steps added no information absent from the state | Yes/no | Replan; stop after k replans | Medium, 2-of-3 hysteresis |

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:

```latex
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

| Component | Responsibility | Key choices |
| --- | --- | --- |
| Actor (System 2 LLM) | Proposes the next action toward the goal | No stop authority; emits a structured proposal (tool, arguments, stated intent) written to the loop state before execution |
| Tools | Execute approved proposals | Idempotency keys on every write; results stored verbatim and flagged as untrusted content, never as instructions |
| Loop state | Single source of truth for a run | Append-only, versioned per turn; holds goal, acceptance criteria, history, last results and the pending proposal; the guardian receives a bounded projection, not the full transcript |
| Guardian (System One model) | Answers the typed questions on each turn | One parallel call per turn plus the pre-execution risk call; pinned model version; questions versioned and reviewed as code; timeout or error is treated as uncertain and escalates |
| Threshold policy | Maps probabilities to exactly one outcome | Pure function of probabilities, thresholds and recent history; t\* and δ per condition; 2-of-3 hysteresis on drift and stagnation; budget caps and exact-repeat detection in plain code; fixed precedence |
| Escalation channel | Resolves the uncertain band and risky actions | System 2 judge for semantic ambiguity, human approval for irreversible or regulated actions; every resolution is recorded as a labelled example |
| Decision log | Makes every turn replayable | Per turn: state hash, question-set version, model version, probabilities, thresholds, outcome; retained with the run |
| Eval harness | Evaluates the evaluator | Labelled trace set that over-samples near-misses; reliability curve and calibration error per condition; regression gate on every model or question change |

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.