Module 1 — The Execution Loop

The Execution Loop

The heartbeat. Five architectures, five stop conditions, four subagent patterns, one per-turn payload.

minutes

artifacts

The loop is the agent. Without it you have a chatbot. Its architecture is the first and most consequential rubric decision — it shapes tool design, context management, error handling, observability. Get the loop wrong and everything downstream fights you.

Key Claims

Load-Bearing Claims

Task predictability decides architecture: ReAct for unpredictable, Plan-then-Execute for predictable.

The wrapper pattern (callModel/executeTool as extension point) is reused for observability (M10), permissions (M6), and security (M11).

The future-proof test: does performance improve when the model upgrades?

After This Module

Identify any of the five loop architectures in a harness's source and name its tradeoffs.

Choose a loop architecture for a given use case — and defend the choice against the four alternatives.

Design a complete stop-condition system (budget, end-turn, max-iter, error-threshold, human) and explain why "no stop condition" is a production defect.

Choose among the four subagent patterns (agents-as-tools, handoffs, fork, worktree) based on the control/visibility tradeoff.

Specify the per-turn observability payload and explain why a loop without it is un-debuggable.

Artifacts

Teaching Document

~6,400 words; 4 sub-sections, deeply sourced

READ

Diagrams

7 diagrams — 5-arch comparison, ReAct anatomy, stop-condition statechart, subagent matrix, observability payload, ReAct + Plan-then-Execute n8n workflows

READ

Slide Deck

reveal.js, 25 slides, dark theme

READ