01 · Mental model
An agent is a model operating inside an application loop
The runtime supplies an objective and state, asks the model for the next step, validates any proposed action, executes approved tools, records the observation, and decides whether to continue. The model proposes; application code owns side effects.
A production loop needs iteration and token budgets, timeouts, tool allowlists, structured handoffs, retry policy, idempotency where relevant, and explicit states for complete, needs input, needs review, blocked, and failed safely.
02 · Visual explanation
03 · Compare and decide
Chat turn versus agent loop
| Decision lens | Chat assistant | Bounded agent |
|---|---|---|
| Control | Human drives each turn | Runtime may choose another step |
| State | Conversation context | Typed run state and artifacts |
| Tools | Optional and user-directed | Core capability, scoped by node |
| Completion | Response returned | Explicit done, review, blocked, or failed state |
04 · Cybersecurity example
Read-only architecture assessment loop
The agent must collect design facts, identify gaps, and produce structured findings.
Plan one evidence request.
Validate it against the read-only allowlist.
Execute and record the result.
Stop at the evidence budget or escalate missing information.
Outcome: The loop can make progress without acquiring permission to change the environment.
05 · What to remember
The 60-second recall
Agency comes from the surrounding loop, not a personality.
Every side effect should cross deterministic authorization.
Safe termination is a first-class feature, not an error case.
Teach-back prompt: Explain this concept to a teammate using the diagram, then name one failure mode and the control that stops it.
06 · Questions people ask
FAQ
07 · Primary sources