Loop Engineering for Governed Agent Systems

AI Engineering

Loop engineering is the emerging practice of designing the system that repeatedly prompts, equips, checks, and stops an AI agent. The important shift is not from one clever prompt to a longer prompt. It is from supervising every turn manually to engineering a controlled execution loop.

I find the term useful because it moves the architecture discussion to the right level. The question is no longer, “Can the model complete this task?” It becomes:

What evidence must one iteration produce before the system is allowed to continue, stop, escalate, or create a real-world effect?

That is the difference between an agent that keeps trying and an operating system for agent work.

Loop engineering is one layer above the agent run

IBM’s definition of loop engineering describes an iterative workflow organized around a goal, an action, an observation, and an adjustment. OpenAI’s description of the Codex agent loop shows the lower-level mechanism: a harness orchestrates the user, the model, and the tools the model invokes.

Those views are compatible, but they describe different design scopes.

Loop engineering does not replace the other three. A loop simply compounds their quality. A poor prompt, polluted context, or overpowered harness becomes more dangerous when it can run repeatedly.

The smallest useful loop has a contract

I would not start with multiple agents or a sophisticated orchestrator. I would begin with a contract that can be inspected without reading model reasoning.

goal:
  outcome: classify one reconciliation exception
  done_when: evidence bundle passes deterministic checks

scope:
  read: [ledger, processor_report, settlement_report]
  write: [case_note, proposed_correction]
  forbidden: [post_ledger_entry, move_money, close_case]

limits:
  iterations: 4
  wall_time: 8m
  model_cost: 1.50_USD

evidence:
  required:
    - source_completeness
    - amount_and_currency_match
    - identifier_lineage
    - verifier_result

terminal_states:
  - proposed
  - no_action
  - needs_human
  - control_failed

This is not a universal syntax. It is a design checklist expressed as configuration. A credible loop needs six things.

1. A recursive goal with a verifiable end

“Investigate the exception” is an activity. “Produce a complete evidence bundle, a classified cause, and a proposal that passes these four checks” is an outcome.

The goal must be re-evaluated on every iteration. Otherwise the agent can optimize for whatever intermediate signal is easiest: more notes, more tool calls, a plausible explanation, or a green evaluator score that does not represent the business result.

2. A bounded trigger

The loop needs a reason to start: an event, schedule, queue item, failed control, or human request. The trigger should carry an identity, priority, owner, and deduplication key.

Without an idempotent trigger, one real-world issue can create several active loops. That is inconvenient for code maintenance and dangerous for financial operations.

3. Prepared context, not accumulated conversation

Each cycle should receive a deliberately assembled evidence bundle: current records, relevant policy, tool results, prior decisions, and a compact summary of earlier attempts.

Appending the full history is not memory design. It is context inflation. The loop should preserve durable facts and decisions while discarding conversational residue.

4. Tools with authority proportional to the task

OpenAI’s practical guide to agents recommends assessing tool risk based on factors such as whether access is read-only or write-enabled, reversibility, permissions, and financial impact. That is especially important inside a loop because tool authority is exercised repeatedly.

I use three tool classes:

• Observe: query records, retrieve policy, inspect telemetry.
• Prepare: create a draft, proposal, test fixture, or case note.
• Effect: modify a customer state, deploy software, post a ledger entry, or move money.

An observe tool may be automatic. A prepare tool usually needs validation. An effect tool needs explicit authorization based on impact and reversibility.

If tools are exposed through MCP, transport authorization is only part of the design. The MCP authorization specification defines protections such as OAuth-based authorization, secure token handling, HTTPS, and scopes. The business layer must still decide whether this agent, for this case, at this point in the loop, may invoke the tool.

5. Evidence that is stronger than model confidence

A model saying “the task is complete” is a claim. The loop needs evidence that another component can inspect.

Useful evidence includes:

• test results bound to the current source version;
• schema and invariant checks;
• before-and-after snapshots;
• signed or immutable tool receipts;
• independent record counts and control totals;
• deterministic policy outcomes;
• a model-based critique with a stable rubric;
• human approval for high-impact exceptions.

Anthropic’s evaluator-optimizer pattern is valuable when success criteria are clear enough for iterative feedback to improve the result. But a second model is not automatically an independent control. Two models can share missing context, incentives, or blind spots. The evaluator should add evidence, not ceremonial agreement.

6. Terminal states that include failure

A loop without a negative terminal state is an infinite retry policy.

At minimum, I want:

• done: the requested outcome is proven;
• no action: the evidence shows that a change is unnecessary;
• needs human: ambiguity or impact exceeds delegated authority;
• control failed: a required source, check, or safeguard is unavailable;
• budget exhausted: the loop reached its time, iteration, or cost limit.

Stopping safely is a product feature. It prevents an uncertain agent from converting uncertainty into repeated action.

The maker-checker pattern needs three kinds of verification

Loop engineering discussions often reduce verification to a maker agent and a checker agent. I prefer a three-part model.

Deterministic verification

Use code for properties that code can decide: type checks, balances, thresholds, allowed transitions, completeness, signatures, uniqueness, and policy rules.

Deterministic checks are cheap, repeatable, and explainable. They should not be delegated to a model merely because a model is already present.

Model-based evaluation

Use a model when the property requires interpretation: whether an explanation is supported by the evidence, whether a proposed plan addresses the stated goal, or whether the output omits a material risk.

Anthropic’s guidance on agent evals emphasizes that multi-turn agents must be evaluated across tool use, state changes, and intermediate results—not only the final answer. I would therefore score both the trajectory and the terminal artifact.

Accountable authority

Use a named human or formally delegated policy for the consequences the system is allowed to create.

The NIST AI RMF Core calls for documented scope, responsibilities, human oversight, testing, independent assessment, and production monitoring. In practice, that means the architecture should show who owns the outer loop: risk tolerance, tool authority, exception policy, evaluation changes, and the decision to expand autonomy.

A worked use case: a reconciliation exception loop

Consider a synthetic payment operation with three independently produced records:

1. an internal ledger entry;
2. a processor or scheme report;
3. a settlement or bank statement.

The reconciliation engine finds a mismatch. A traditional workflow puts the case into an analyst queue. A poorly designed agent workflow gives an AI assistant broad access and asks it to “resolve the exception.”

A loop-engineered version is narrower.

Iteration 1: assemble facts

The loop retrieves the three records, verifies source completeness, normalizes identifiers, and builds control totals. It cannot update any financial record.

If a source is missing, the terminal state is control_failed. The agent does not infer settlement from a success message.

Iteration 2: classify and propose

The maker classifies the mismatch:

• timing difference;
• duplicate report;
• identifier mapping failure;
• fee or foreign-exchange variance;
• missing ledger posting;
• unknown.

It then proposes either no action, delayed review, a data correction, or a compensating ledger entry. The proposal includes the expected effect and the records that support it.

Iteration 3: verify independently

Deterministic controls recompute totals, validate currency and amount, check that referenced records exist, and confirm that the proposed transition is permitted.

A separate evaluator checks whether the narrative is supported by the evidence and whether a plausible alternative cause was ignored. The evaluator sees the evidence bundle and rubric, not the maker’s hidden reasoning.

Outer-loop decision: authorize or stop

No model may post a ledger entry. Low-risk data enrichment can be approved by policy if it is reversible. A financial correction requires the authorized operating role.

After approval, the system creates a new compensating entry; it never edits financial history. Reconciliation then runs again against the new state. Only that fresh result can close the case.

This is where the FinTech example clarifies the broader concept: the inner loop can accelerate investigation, but the outer loop owns financial truth.

The Basel Committee’s operational-resilience principles emphasize the ability to respond, recover, and learn while sustaining critical operations. Loop engineering should reinforce that discipline. It should not create a fast but opaque bypass around it.

Observe the loop as a production system

An agent trace is not only a transcript. The system needs correlated telemetry for:

• trigger and case identity;
• context and policy versions;
• model, prompt, and evaluator versions;
• tool calls and authorization results;
• iteration count, latency, and cost;
• evidence checks and failures;
• human decisions and reason codes;
• terminal state and later business outcome.

OpenTelemetry’s signal model provides a useful implementation vocabulary: traces show the path, metrics show aggregate behavior, logs record events, and baggage carries controlled correlation context.

The metrics I would review are not “tokens used” alone.

Every repeated stop is also design information. If the loop repeatedly lacks one identifier, that is a data-contract problem. If reviewers repeatedly reject the same proposal class, that is an evaluation or authority problem. If the same exception returns after correction, the loop is treating symptoms rather than causes.

Where loop engineering is the wrong answer

The term is new; the temptation to apply it everywhere will be strong.

Use deterministic automation when:

• the states and transitions are known;
• the inputs are structured;
• the decision is already encoded reliably;
• an agent would only imitate a rules engine;
• uncertainty adds no business value.

Use a human-led workflow when:

• the goal itself is disputed;
• the evidence cannot be made available safely;
• accountability cannot be delegated;
• the action is irreversible and rare;
• learning from the decision matters more than throughput.

Use an agent loop when the work combines interpretation, tool use, multiple steps, recoverable actions, and verifiable intermediate progress.

The test is not whether the task is difficult. It is whether the task can be bounded and proven.

A practical adoption sequence

Stage 1 — Shadow

Run the loop against historical or duplicated cases. Give it read-only tools. Compare its classifications and evidence bundles with known outcomes.

Stage 2 — Recommend

Let the loop prepare proposals for live work while humans make every consequential decision. Measure missing evidence, overrides, failure modes, cost, and latency.

Stage 3 — Delegate reversible actions

Allow narrowly scoped, reversible updates when deterministic checks pass. Keep high-impact actions behind human authority.

Stage 4 — Expand by evidence class

Increase autonomy only for the classes of work that have stable inputs, clear controls, acceptable error rates, and reliable recovery—not because the average score improved.

At every stage, version the loop itself: goal, context assembly, tool contracts, evaluator rubric, budgets, and stop conditions. Otherwise a changed prompt or tool silently changes the operating control.

My design rule

Do not optimize a loop for the number of iterations it can complete without a human. Optimize it for the quality of evidence it produces before the system changes state.

A good loop has the confidence to continue when progress is proven, the discipline to stop when controls fail, and an accountable owner for the consequences it creates.

That is loop engineering: not endless autonomy, but engineered recurrence.

Related reading

• Observability for AI: From Tokens to Business Outcomes
• Responsible AI Governance as an Engineering System
• Reconciliation by Design, Not by Spreadsheet
• How to Build an MCP Server for Your API

References

• IBM — What Is Loop Engineering?
• OpenAI — Unrolling the Codex Agent Loop
• OpenAI — A Practical Guide to Building AI Agents
• Anthropic — Building Effective Agents
• Anthropic — Demystifying Evals for AI Agents
• NIST — AI Risk Management Framework Core
• Basel Committee — Principles for Operational Resilience
• OpenTelemetry — Signals
• Model Context Protocol — Authorization