Loop Engineering: The Control System Around the Agent

Abstract

Reliable agent systems do not emerge from models, prompts, tools, and memory alone. They depend on the control system that reconstructs state, allocates bounded work, verifies outputs, persists accepted changes, and decides whether another iteration is allowed. This note argues that the primary object of engineering is the loop around the agent, not merely the agent itself. That matters because many production failures come from control failures: stale state, weak stopping rules, unsafe retries, unverifiable progress, and ambiguous authority.

Context and motivation

Agent demos have improved quickly. Teams can now show a model planning, calling tools, and producing convincing outputs across coding, research, and operational tasks. That progress creates a familiar mistake: people describe the agent as if the model and its prompt were the whole system.

That description leaves out the machinery that decides what happens first, which facts are authoritative, what counts as progress, when a failure should trigger a retry, and when execution must stop. In production, those decisions determine whether a system remains bounded, diagnosable, and governable.

This note uses loop engineering as the name for that design problem:

Loop engineering is the discipline of designing the control system that repeatedly reconstructs context, invokes probabilistic workers, verifies their outputs, persists validated state, and determines what happens next.

This is not an established industry term. It is the organizing concept behind the adk-loop-lab reference architecture, which implements bounded agent loops with Google ADK.

Core thesis

The important design object is not merely the agent. It is the loop around the agent.

Models can propose plans, interpret evidence, and generate candidate actions. They do not define durable state, safe retries, stopping conditions, authority boundaries, or acceptance criteria by themselves. A production system needs deterministic control around probabilistic workers.

The loop is the system

A production agent operates inside a repeated decision-and-action process. The return edge is conditional. The system does not continue merely because another model call is possible.

Lifecycle loop:

flowchart LR
  D[DISCOVER] --> P[PLAN]
  P --> E[EXECUTE]
  E --> V[VERIFY]
  V --> C[COMMIT]
  C --> R[REFLECT]
  R --> X[DECIDE]
  X -->|continue| D
  X -->|complete or stop| S[TERMINAL STATE]

flowchart TB
  O[Outer system loop] --> O1[Reconstruct authoritative state]
  O1 --> O2[Allocate bounded work]
  O2 --> A[Invoke agent]
  A --> I[Inner model and tool loop]
  I --> O3[Verify external result]
  O3 --> O4[Persist accepted changes]
  O4 --> O5[Decide whether another iteration is allowed]

flowchart TB
  subgraph C[Control plane]
    C1[Lifecycle]
    C2[Budgets]
    C3[Stopping]
    C4[Approvals]
  end
  subgraph E[Execution plane]
    E1[ADK agents]
    E2[Gemini]
    E3[Tools]
    E4[Workers]
  end
  subgraph D[Data plane]
    D1[State]
    D2[Events]
    D3[Memory]
    D4[Artifacts]
  end
  C --> E
  E --> D
  C -.policy and persistence rules.-> D

flowchart TB
  A[Authoritative environment] --> S[STATE
Durable workflow record]
  S --> C[CONTEXT
Temporary model input]
  C --> M[MEMORY
Reusable but fallible knowledge]
  S --> M