AI BENCHNOTES
Tool callsBENCH NOTE 006Agent loopsCoding agents
AI BENCHNOTES
THE COMPLETE WORKBENCHPick a machine part.
12 NOTES / 12 LABS / ZERO INCENSE

Start anywhere. The numbers are a useful route, not homework police.

00Animated bench map
CONCEPT 006gears included

Agent loops:the robot costumehides a while loop.

Your application asks a model what to do next, runs the chosen tool, feeds the result back, and decides whether another turn is allowed. Useful autonomy is a controlled feedback cycle—not an endless inner monologue.

  • DISCRETEmodel calls
  • STATEFULevent history
  • BOUNDEDby your code

The model chooses a move. The harness decides whether that move is permitted, executed, recorded, and repeated.

01 / FRAME BY FRAME

There is no tiny model pacing inside your server.

A model invocation ends when it returns. Your application may then run code for milliseconds, minutes, or hours before calling a model again. The continuity lives in state and history, not in a permanently running mind.

  1. FRAME 01HARNESS
    Observe

    Pack the goal, current state, relevant history, and fresh evidence.

  2. FRAME 02MODEL
    Decide

    Return a final answer or a structured request for the next tool.

  3. FRAME 03APP + TOOL
    Act

    Validate, approve if needed, then execute one bounded operation.

  4. FRAME 04HARNESS
    Inspect

    Record the result, errors, and any environment changes as new state.

  5. FRAME 05POLICY
    Stop or continue

    Check proof of success and budgets. Exit—or make another model call.

Between frames: no magical background “thinking.” Just your runtime executing code, waiting on tools, persisting state, or pausing for a human.

02 / INTERACTIVE LOOP-O-MATIC

The exit policy writes the ending.

Same goal. Same tools. Same first error. Change only what the harness considers a reason to stop, and watch the run recover, abandon the task, or chew through its fuse.

Choose one exit policy
RUN / FIX_FLAKY_AUTH_TESTEXIT POLICY: PROOF OF DONE
  1. T01OBSERVEOne failing auth test
  2. T02DECIDEPatch the stale assertion
  3. T02TOOLPatch conflict: line moved
  4. T03INSPECTRetryable; no change applied
  5. T04ACTRe-read, patch once, run tests
  6. T05VERIFY42 tests pass → exit
EXIT CHUTEDONE5 turns · recovered

The loop treated the stale patch as evidence, retried safely, and exited when the environment proved the task was complete.

HARD FUSESmax turns: 8tool retries: 1side effects: approval gated

A model can suggest “done.” Your loop needs a testable definition of done—and a budget for the days when it never arrives.

03 / UNDER THE ROBOT COSTUME

Three jobs. Do not make the model impersonate all of them.

Reliable loops separate judgment from orchestration and execution. The model proposes. The harness governs. Tools touch the world.

01 / APPLICATION HARNESSThe stage manager

Builds each model input, validates tool calls, carries state, enforces permissions and budgets, records the trace, and decides whether another turn happens.

02 / MODEL TURNThe next-move proposer

Reads the current evidence and returns a bounded next action, perhaps a plan update, a tool request, a question for a human, or a candidate final answer.

03 / TOOLS + ENVIRONMENTThe hands and the ground truth

Search, read, write, test, transact, or inspect. Their results reveal what actually happened—not what the model hoped happened.

THE GOLDEN GEAR

After an action, inspect the environment again. A successful API response can still produce the wrong state; a failed tool call can contain exactly the evidence needed to recover.

04 / SERVICE MANUAL

Autonomy needs fuses, not vibes.

Most loop failures are ordinary software failures wearing novel clothes: missing termination, unsafe retries, stale state, weak permissions, and no useful trace.

  1. 01
    TERMINATIONWrite an exit predicate

    Completion should be observable: tests pass, required fields exist, a cited answer meets a rubric, or the user confirms. “The model sounded finished” is not a predicate.

  2. 02
    BUDGETSInstall hard fuses

    Cap turns, elapsed time, tokens or spend, tool calls, and repeated failures. A budget stop is a controlled outcome, not an embarrassing crash.

  3. 03
    RECOVERYClassify errors before retrying

    Retry transient failures with backoff. Feed actionable failures back as observations. Stop or escalate permission errors, invalid requests, and repeated identical failures.

  4. 04
    IDEMPOTENCYMake repetition safe

    Use idempotency keys, read-before-write checks, operation IDs, or deduplication. A timed-out payment call is not permission to charge twice.

  5. 05
    HUMAN GATEPause before blast radius

    Ask for approval before irreversible, expensive, public, privileged, or ambiguous actions. Persist the run so approval can arrive without replaying completed work.

  6. 06
    STATEKeep a useful trace

    Record decisions, tool inputs and results, retries, approvals, and stop reasons. Compact old history deliberately; do not let an ever-growing transcript become the control system.

PLAN-AHEAD MODEA pencil route

Useful when dependencies matter: outline milestones, reserve resources, and make the intended path inspectable.

REACTIVE MODEEyes on the road

Useful when the environment is uncertain: take a small action, inspect reality, then choose again.

A plan is state, not scripture. Good loops can plan ahead and still change course when a tool returns ground truth.

05 / FIT CHECK

Use a loop when the route is unknown—but progress is visible.

Agentic loops earn their complexity when each observation can legitimately change the next action. If the route is fixed, write the route.

LET IT LOOPuncertain path · observable progress
  • Repository work

    The path depends on what search, edits, tests, and code review reveal.

  • Open-ended research

    The next query depends on gaps in the evidence, with a clear coverage rubric.

  • Incident triage

    Inspect signals, form a hypothesis, run a safe diagnostic, and update.

  • Messy operations

    Reconcile records or complete forms where each result changes the next step.

USE BORING CODEknown path · predictable steps
  • The path is already known

    Use normal deterministic code or a fixed workflow. A loop adds latency and new failure modes.

  • Success cannot be observed

    Without evidence or a rubric, the loop cannot know whether to continue, stop, or correct itself.

  • Every action is irreversible

    Redesign tools and approval boundaries before granting repeated autonomous access.

  • One response solves it

    Do not build a tiny bureaucracy around a question that needs one model call.

FIELD RULE

Give the model freedom over the path, not freedom from constraints.

06 / IMPLEMENTATION RECEIPT

The glamorous bit is still a guarded while loop.

Frameworks package this differently, but the durable responsibilities remain: inspect, decide, gate, execute, record, verify, and stop.

agent-loop.ts · provider-neutral pseudocodeCONTROL LIVES HERE
async function runAgent(goal: Goal, budget: Budget) {
  const state = await loadRunState(goal);

  while (state.turns < budget.maxTurns) {
    const observation = await inspectEnvironment(state);
    state.record({ type: "observation", observation });

    if (completionPolicy.isSatisfied(goal, observation)) {
      return finish(state, "verified_complete");
    }

    state.turns += 1; // one turn = one new model invocation
    const next = await model.decide({
      goal,
      state: state.compactView(),
      observation,
      tools: allowedTools,
    });

    if (next.kind === "ask_human") {
      return pauseForApproval(state, next.question);
    }

    if (next.kind === "final") {
      state.record({ type: "candidate_final", text: next.text });
      await saveRunState(state);
      continue; // verify against the environment on the next cycle
    }

    if (approvalPolicy.requiresHuman(next.toolCall)) {
      return pauseForApproval(state, next.toolCall);
    }

    const result = await executeTool(next.toolCall, {
      idempotencyKey: state.operationId(next.toolCall),
      retry: retryPolicy.for(next.toolCall),
    });

    state.record({ type: "tool_result", result });
    await saveRunState(state);
  }

  return finish(state, "turn_budget_exhausted");
}
WHY INSPECT FIRST?

The environment may already satisfy the goal after a resume, duplicate delivery, human edit, or delayed tool completion.

WHY RECORD BEFORE NEXT TURN?

Recovery needs durable facts. If the process restarts, the loop should continue from state—not replay side effects from memory.

WHY VERIFY “FINAL”?

Final text is a proposal to stop. When ground truth is available, let code or a grader confirm the claim.

07 / BENCH NOTES

Six ways to accidentally build a haunted carousel.

01

“The model keeps thinking between tool calls.”

Usually, the application is executing a tool or waiting. A later model call receives the accumulated state and continues from that evidence.

02

“More turns make the agent smarter.”

More turns buy opportunities to observe and correct. They also add cost, latency, and chances for errors to compound.

03

“Retry means run the same thing again.”

Only retry classified transient failures, and make side effects idempotent. Otherwise repetition may duplicate damage.

04

“A detailed plan removes the need to inspect.”

Plans are hypotheses. Tool results and environment state outrank the plan whenever reality disagrees.

05

“If it says it is done, the loop is done.”

Treat self-reported completion as a candidate. Prefer tests, state checks, graders, or human confirmation when available.

06

“Human approval means clicking yes on every turn.”

Approval is most useful at meaningful boundaries: irreversible, privileged, expensive, public, or intent-sensitive actions.

THE WHOLE BENCH NOTE, REDUCED

agent loop = model judgment + tool-grounded feedback + application control

↻ until verified done, paused, or safely out of budget