The central discipline
Represent the desired outcome, action, observation, and verifier as separate state so the system can tell progress from merely convincing narration.
Completion is a verified state, not a confident sentence.Interactive agent-systems explainer
Watch an AI agent plan, act, verify, and recover
Compare three execution strategies, inject a tool failure, change the approval threshold, and scrub through the resulting state graph. Every event is deterministic teaching logic, not a live model or real external action.
Strategy
Goal received; planning has not started.ACTIVE
Agent planning simulator ready.
An agent loop is a controlled state transition system
An agent is more than a language model producing a plausible next sentence. A useful agent maintains task state, chooses an action, invokes a tool through a schema, receives an observation, updates its state, and decides whether the goal is satisfied. Reliability comes from how those transitions are represented and checked.
The live graph separates events that are often blurred together in demos. A goal is not a plan. A plan is not an action. A successful HTTP response is not proof that the intended outcome exists. A tool observation can be incomplete, stale, malicious, or simply unrelated to the postcondition the user cares about.
Change the strategy to Reactive. The graph has less planning structure and makes the next decision after each observation. This can adapt quickly, but it may repeat work, lose the global objective, or accept an attractive local result. Plan mode expands the intended sequence first, which improves coordination but can become brittle when reality differs from the plan.
Verified mode inserts explicit postcondition checks and a recovery path. Inject the midway failure and advance the timeline: the action fails, the verifier detects that the expected state is missing, a recovery event revises the route, and a retry is checked again. This additional structure consumes time and tokens, but it converts silent error into inspectable state.
Plans are hypotheses
A plan predicts a useful route through uncertain tools and environments. It should be revisable when observations contradict its assumptions.
Tools need contracts
Typed parameters, bounded permissions, idempotency expectations, timeout policy, and structured results reduce ambiguity at the action boundary.
Observations are inputs
Tool output should be parsed and scoped like any other untrusted input. It does not gain authority merely because the agent requested it.
Verifiers need evidence
A verifier should test the requested postcondition using an independent signal whenever practical, not rephrase the executor's claim.
Three execution strategies
Reactive loop
The system chooses one action from the current goal and observation, then repeats. It works well for short, observable tasks where each step reveals enough state to choose the next move. Without durable state, it can cycle, forget constraints, or optimize the latest observation rather than the original request.
goal -> action -> observation -> next action
Plan then execute
A planner decomposes the objective into ordered steps before tools run. The executor can track dependencies, reserve resources, and communicate expected work. The risk is plan lock-in: if the environment changes, a stale plan can drive a sequence of locally valid but globally useless actions.
goal -> plan -> action sequence -> completion claim
Verify and replan
The graph adds explicit checks after actions and a recovery policy when evidence does not satisfy the postcondition. This is especially valuable for browser automation, deployment, messaging, purchases, and other workflows where the tool can report success before the real-world state is correct.
goal -> plan -> act -> observe -> verify -> commit or replan
Failure becomes useful when it changes state
Action attempt
The executor calls a bounded tool with typed parameters and an idempotency strategy. The system records the attempt before assuming that it happened.
IntentObservation
The result can include data, an error, a timeout, or an ambiguous response. It should be attached to the exact attempt and parsed without treating embedded text as new authority.
EvidencePostcondition check
The verifier asks whether the user-visible state now satisfies the goal: the page is live, the reservation exists, or the intended recipient actually received the message.
DecisionRecovery route
A retry is only one option. Recovery may refresh state, choose another tool, roll back a partial change, request approval, narrow the goal, or return a structured failure receipt.
Bounded adaptationGOALPLANTOOL SCHEMAAPPROVALACTIONOBSERVATIONPOSTCONDITIONRECOVERYRECEIPTGOALPLANTOOL SCHEMAAPPROVALACTIONOBSERVATIONPOSTCONDITIONRECOVERYRECEIPT
State and memory need types
Working state
The current goal, plan position, tool attempt, unresolved assumptions, and active approvals belong in short-lived execution state. They should be explicit enough to resume or safely abort.
Evidence memory
Tool observations, screenshots, receipts, source URLs, and verification results support later reasoning. Store provenance and scope so similar-looking evidence is not silently reused for another user or task.
Preference memory
Durable user choices can guide planning, but they should not become universal permission. A preference for nonstop flights is different from authority to purchase any ticket.
Policy state
Approval thresholds, spending limits, recipient restrictions, allowed domains, and data boundaries should be enforced outside free-form model text and evaluated at the action boundary.
How verified loops support personal agents
A personal agent works across messaging, browsers, accounts, and changing external state. That makes reliable postconditions more important than long plans. The agent should know what it attempted, what evidence came back, what remains uncertain, and what requires the user.
For a text-message AI assistant, a request such as "tell the contractor the appointment moved" needs recipient resolution, content review policy, a send action, and a delivery receipt. Drafting a polished message is only one node in that graph.
A computer-use cache can reduce repeated browsing by retrieving prior observations, but cached state must not masquerade as a fresh verifier. A page seen yesterday is evidence about yesterday unless the workflow explicitly refreshes it.
When an AI website-building agent publishes a change, the commit, deploy request, Render status, custom-domain HTTP response, title, screenshot, and mobile layout are separate signals. A strong loop links them into one release receipt instead of stopping when the upload command exits successfully.
Super applies these patterns to messaging and computer-use work where the agent needs to act through real tools, preserve user control, and report outcomes in a form that can be inspected later.
Represent the user-visible postcondition before selecting tools.
Give every tool a typed schema, timeout, and permission boundary.
Record action attempts before interpreting their responses.
Parse observations as untrusted, scoped evidence.
Place approvals before irreversible or high-consequence actions.
Use independent postcondition checks when practical.
Bound retries and define rollback or escalation routes.
Return a structured receipt for success, partial completion, or failure.
Frequently asked questions
Does an agent need a complete plan before acting?
No. Short, observable, reversible tasks can work well with a reactive loop. More explicit planning becomes valuable when steps have dependencies, resources must be reserved, coordination spans tools, or the user needs a preview before execution.
Is a successful tool response enough?
Only when the tool response itself is the authoritative postcondition. Often it is not. A deployment request can be accepted while the site still returns 404, and a browser click can succeed while the wrong item is selected. Verify the state the user actually requested.
Where should approval logic live?
Outside free-form model reasoning, at the action boundary. The policy engine should evaluate tool, parameters, user, scope, risk, freshness, and prior authorization before execution.
What makes a retry safe?
Idempotency, attempt identity, fresh state inspection, bounded counts, and knowledge of partial side effects. Retrying an email send or purchase without those protections can duplicate the consequence.
Can the same model plan and verify?
It can, but shared blind spots reduce independence. Strong systems combine model review with structured assertions, direct environment reads, deterministic validators, policy checks, or a separate evaluator chosen for the failure mode.
What should an agent receipt contain?
The goal, relevant inputs, plan or route, tool attempts, observations, approvals, verification evidence, final state, unresolved uncertainty, and links or identifiers needed to inspect the result.
Primary research and implementation references
ReAct: Synergizing Reasoning and Acting in Language ModelsYao and colleagues interleave reasoning traces and task-specific actions with environment observations.
ToolformerSchick and colleagues study language models learning when and how to call external tools.
ReflexionShinn and colleagues explore verbal reinforcement signals and reflective memory for agent improvement.
Plan-and-Solve PromptingWang and colleagues separate planning from solution execution to reduce reasoning omissions.
AgentBenchLiu and colleagues evaluate language-model agents across interactive environments.
Three.js DocumentationThe WebGL library used to render and animate the live execution-state graph.
Make the outcome inspectable.
An agent becomes trustworthy when goals, actions, evidence, approvals, and recovery are represented as explicit state rather than hidden inside persuasive text.
Explore Super