Thoughtware

The agent loop

Plan, act, observe, review, and revise around persistent state, with explicit transitions such as accept, patch, fetch, ask, escalate, or stop.

9 min read

Cover for The agent loop

Serious agents do not generate once and hope. They move through planning, action, observation, review, and revision around persistent working state. Each material step ends in an explicit transition, not another pass of fluent text. The loop is the mechanic of pursuit: how an agent turns evidence into progress toward a goal without hiding decisions inside monolithic calls.

Helpful context: This page builds on minimum sufficient loop, working state versus transcript, and what is an agent. Read those first if pursuit state or stopping policy still feel abstract.

One Meal Companion iteration

Working state holds interpreted week, plan version, accepted meals, and open gaps. After CritiquePlan names one weekday weakness, one lap might run as follows. The agent plans by selecting local patch strategy rather than full replan. It acts by calling RecommendMealSubstitution. It observes the structured patch proposal, cost, and source. Deterministic code validates schema and re-runs allergy checks. Review chooses PATCH apply versus REPLAN versus ASK. Finally, a transactional update to working state checkpoints the change if material.

The iteration ends in patch via RecommendMealSubstitution, not in another undifferentiated generation pass. That ending is architectural. Review chose a transition. State changed. Evaluators can replay the lap. Compare with a chat product that regenerates the whole week because the last reply "felt weak." No transition is named. Working state may not exist. The user sees new text. The system learned nothing durable about pursuit. The difference is observable in production traces: the first system produces a log that says "PATCH applied to Tuesday, weakness resolved, four accepted meals preserved" while the second produces only a new blob of text with no record of what changed or why.

Explicit transitions

Review decisions need a shared vocabulary. Thoughtware uses explicit verbs so decision locality survives incident review.

TransitionMeaning
ACCEPTSufficient for its role. Preserve and continue or stop successfully
PATCHBroadly sound. Repair one bounded weakness locally
RETRYSame judgment again after failure or transient problem
FETCHAdditional declared memory or knowledge required
BRIDGEFill a named gap through retrieval, tool, or inquiry
REPLANStrategy or problem representation no longer suitable
ASKPerson can supply missing information, preference, consent, or authority
ESCALATEDecision exceeds authority, terrain, or acceptable consequence
STOPCannot complete safely or usefully under current conditions

The vocabulary gives evaluators questions: Did the agent repair locally when locality was appropriate? Did it replan when representation failed? Did it ask instead of guessing preference? Did it stop when minimum sufficient loop criteria were met? Cognitive orchestration implements these transitions in ordinary code. An agent is mostly ordinary code because the loop must be readable, not emergent.

State, not transcript

The loop is organised around working state rather than around repeated generation. Transcripts record what was said. Working state records what currently matters for the goal: interpreted week, accepted meals, unresolved gaps, active strategy, checkpoints, loop budget. Confusing the two produces familiar failures. Temporary corrections become permanent behaviour. Accepted meals disappear on regeneration. Critique findings vanish because the chat window scrolled.

See working state versus transcript. Memory forms remain distinct: context for this run, knowledge endorsed across runs, experience and expertise when libraries mature. Looping without state change is repetition, not deliberation. Generating another paragraph because the last one felt weak is not review. Calling a tool chain twice without updating pursuit state is not an agent lap. The distinguishing test is whether the working state fields have a different value after the iteration than before: if nothing changed in accepted meals, open gaps, or strategy, the system consumed budget without advancing pursuit.

The loop is organised around state rather than around repeated generation.

What the loop is not

Skills may appear inside the Act step. cognitive units may appear inside the Act step. Deterministic guards sit between Observe and Review. The agent owns Plan and Review policy even when it delegates perform work. Where the cognitive unit ends and the agent begins applies on every lap. cognitive units return judgments. The agent chooses transitions.

Trust conduct inside the loop

Loop design connects to trust conduct in specific ways. Targeted questions replace generic chat when ASK is chosen. Challenge as conduct fires when constraints combine impractically. Recovery is part of trust when ESCALATE or STOP preserves safety over fluency. Behaviour standards belong in agent policy, not in hopeful prompt tone. The loop is where conduct becomes testable.

Compression and expertise

When guards pass, expertise like Busy Week Pattern compresses laps without removing review. Compression licenses a shorter path. It does not remove stop checks or authority. Failed guards return the case to full deliberation. That pattern links the loop to libraries of cognition. Expertise packages are callable material. Agents decide when compression applies.

Common loop failures

Review skipped is the most visible failure: Act connects directly to Act via another generation call without any transition decision. Transitions without logging means operators cannot replay why REPLAN fired. Patch without locality means whole-week regeneration masquerades as repair. Stop tied to tokens means pursuit ends when spend hits a cap while exact checks still fail. An agent loop label on a pipeline means a fixed chain with no review decisions exists. See pipelines are not agents.

Loop budget and economics

Working state should carry a loop budget when cost or latency matters. Budget exhaustion triggers stop or escalate transitions, not silent truncation. Budget is a guardrail paired with sufficiency checks, not a substitute for them. Economics belong in loop design. A patch transition is cheaper than full replan. A targeted ask is cheaper than another critique pass when preference is missing. Explicit transitions make those economics visible to product owners setting policy.

Multiple laps, one pursuit

One user request may require several laps. Each lap ends in a named transition and a working state diff. Pursuit completes when stop conditions succeed or when escalate or stop transitions end the run safely. Material revisions should checkpoint working state so recovery does not replay expensive work. Checkpoints belong in orchestration beside revise steps. A patch that fails mid-apply should restore the last good plan version, not regenerate from scratch. Checkpoint design pairs with recovery is part of trust. Households notice when accepted meals disappear after a failed repair.

Product specs should use the same review verbs engineering implements. If the spec says "regenerate plan" while code implements REPLAN, evaluations will talk past implementation. Align language early. Shared vocabulary also helps support teams interpret logs without engineering escalation for every confused stop.

Loop maturity

Early agent builds may log transitions before they enforce them. Maturity moves from logged suggestions to enforced policy with evaluation gates. Track that progression explicitly. A loop that documents PATCH but always regenerates the full week has not matured past demo stage. Maturity reviews should sample logs, not slide decks. Export one lap trace from staging and annotate each transition with the review verb that fired. Keep annotated traces as fixtures for regression tests and onboarding examples.

Loop design and library design converge as products mature. Both reduce repeated discovery cost for households and operators. Packaged cognition turns repeated laps into invocations instead of rediscovery. That convergence is the handoff to libraries.

Each iteration should leave a traceable transition in working state so support can reconstruct why the agent chose the next step.

What to do next

Name the working state fields the loop reads and writes each lap. Implement review transitions as enumerated decisions in code. Walk one real case lap-by-lap and verify state changes at each step. Attach evaluation to trajectories, not final natural language output alone. The replay exercise converts loop vocabulary from theory into a team habit and produces fixtures for trajectory evaluation.

See minimum sufficient loop, stop conditions as design, and cognitive orchestration.

Read next: Libraries of cognition.