The agent loop's four surfaces

a refund request: one turn through the execution loop

Now walk through a complete turn of a fuller agent, the billing specialist whose blocks you just read, to see the loop the anatomy serves.

A customer contacts support requesting a refund. The agent’s overarching goal was established before this customer ever arrived, codified directly in its system prompt: resolve refund requests strictly according to company policy. The model evaluates the incoming message and emits a structured request to invoke a tool: fetch_order_history(user_id).

The loop’s code, running entirely outside the model, intercepts that request and executes the corresponding query against your production database. The database response returns as raw text and is appended to the ongoing conversation history. This returned payload constitutes an observation: the order in question was placed ten days ago.

At this stage, the model ingests the entire updated context—the user’s initial message, its own prior tool invocation, and the newly injected observation—to determine its next step. It evaluates the ten-day elapsed time against the thirty-day eligibility threshold defined in its instructions, determines that the purchase qualifies, and emits a second tool call: issue_refund(order_id). This decision represents adaptation: the agent revised its operational plan dynamically based on facts discovered through active execution.

This iterative loop continues until the primary goal is satisfied or an explicit boundary condition halts execution. Once the action succeeds, the agent composes a clear confirmation message for the customer.

Four distinct design surfaces govern this interaction, and every one of them remains under your direct architectural control. Keep this refund sequence in mind as we analyze each layer in detail.

Notice carefully where the observation landed. When the order history returned from the database, your application appended it directly to the prompt sequence. On the subsequent forward pass, those facts sat inside the context window alongside the initial prompt and instructions. This is grounding in its practical form: rather than relying on manual copy-pasting, the programmatic loop injects ground truth directly into the model’s text stream, allowing the next token probabilities to condition on genuine system data. The model generated language at three distinct points, but every underlying fact originated in your external code.

the loop is what produces agency

deriving the loop: goals, actions, observation, adaptation

A standard household thermostat monitors ambient temperature and activates a heating unit when the room cools. It senses its environment and takes physical action. Does this mechanism qualify as an agent?

The thermostat provides an instructive baseline. It pursues a programmed goal and acts upon its environment, but it executes a single, invariant rule regardless of context, unable to revise its strategy based on intermediate feedback. Compare this with our billing agent. Upon observing that the purchase occurred ten days ago, the agent invoked issue_refund; had the observation indicated forty days, it would have generated a policy-based refusal; had the amount exceeded $500, the written boundary would have made escalation its likely reply, and the refund service would have refused the call either way. Agency emerges from this capacity to inspect intermediate results and adapt subsequent decisions.

The definition: this course’s working definition of an LLM agent is a language model integrated into a loop that pursues goals by selecting actions, observing results, and adapting its strategy until the goal is met or a boundary stops it. Computer science uses “agent” more broadly, as the thermostat dialogue above showed.

This raises a foundational design question: how much functional capability stems from the underlying model versus the loop?

A more capable foundation model improves reasoning quality, but a frontier model devoid of external tools remains incapable of inspecting a live customer record. The operational utility of any agent is bounded by the external integrations you construct around it. Without a loop, a model asked for account history cannot consult live records; it can say so, and it often outputs what a generic invoice looks like instead: confabulation, the gap filled with the shape of an answer. Our billing example avoided confabulation because fetch_order_history supplied verified data to the context window before the model generated its assessment.

each loop surface dictates an engineering constraint

Every component of the agent loop represents an engineering choice that carries direct operational consequences. When you grant a system the autonomy to pursue goals, execute actions, inspect results, and adapt its plan, you must build safety constraints directly into each of those four surfaces.

Assigning a goal requires strict alignment. Language models follow instructions literally, often discovering shortcuts that optimize a metric at the expense of your actual intent. An agent told simply to “close customer tickets as quickly as possible” can satisfy that instruction by marking every ticket resolved without helping the user. To prevent this, system goals must be framed around policy compliance and verified outcomes rather than raw throughput.

Executing actions introduces asymmetric risk. Read-only operations like fetch_order_history are idempotent: a failed query costs latency, and sometimes a disclosure, because a record the agent should not have read has already gone to the model provider. State-mutating operations like issue_refund alter reality outside the loop: an incorrect database write, a duplicate refund or an unauthorized transaction causes immediate financial loss. This asymmetry is why destructive actions require rigid boundary checks, explicit confirmation gates, and elevated runtime permissions, and why the trust perimeter around them is built in your runtime rather than in your prompt.

Reading observations demands systematic verification. A language model processes incoming tool outputs in the same context window as your system instructions. If an external API returns malformed records, outdated documentation, or prompt injections from untrusted websites, the model ingests that text without inherent skepticism. You must treat every tool payload as unverified external data rather than as trusted instructions: tool results are data, never commands.

Dynamic adaptation requires hard exit criteria. The flexibility that allows an agent to solve multi-step problems also permits it to drift into repetitive loops or pursue dead ends. A reliable architecture pairs its primary success criteria with deterministic constraints: hard step budgets, explicit failure routines, and mandatory human escalation for sensitive operations like refunds exceeding $500.

In agent engineering, architectural mechanisms and safety boundaries are two perspectives on the exact same design choices.

what you can do with this today

You now hold both essential foundations: the loop (goals, actions, observation, adaptation) that produces agency, and the modular block anatomy that governs execution. You can use these principles as a systematic diagnostic framework for any agent architecture you encounter:

Can you find and change the Tutor? An agent’s instruction lives in a file, and changing one line in one block, then running the agent again, shows you what that block controls. An agent you cannot change is one you cannot maintain, and the file is where its maintenance lives.

Can you name the four surfaces? Clearly identify the agent’s explicit goal, its available tool actions, its method for ingesting observations, and its adaptation boundaries. If any of these four surfaces is undefined, the architecture remains incomplete.

Does every capability have a doctrine? Whenever you introduce a new tool integration, vector index, or memory store, author an accompanying doctrine that defines authoritative use and specifies exact fallback behaviors for empty results.

Does the prompt say how to use each custom tool? For every tool you wrote yourself, find the lines in the instruction that say when to call it, what must be read before it changes anything, how many calls a turn may spend, and what the agent does when the result is an error. The tool’s description says what the tool does, and the instruction is where this agent’s use of it is written down.

Does the framework say what to produce, what to decide first, and what never to do? Read the execution framework for a task directive whose finished state you could spot in a transcript, a reasoning directive wherever the reply turns on a decision, and guardrails written as “never”, each with the move to make instead.

Could each rule be checked against a transcript? Audit your existing prompts to identify vague stylistic guidelines, converting them into binary pass/fail assertions an automated test script can evaluate, then run the agent many times and read the rate. A task-list assistant makes a small test: you ask it to add “call the plumber” to your list, then say “I called the plumber”. If its instruction says an inferred change gets a question first, the reply to look for asks whether to mark the task done, and a task_update call in that turn is a fail.

Is anything irreversible guarded by text alone? Ensure that mission-critical mutations, financial transactions, and data deletions are gated by deterministic backend assertions in code rather than prompt-level boundaries alone. For each one, name the check that refuses it: who may ask, how much, and whether it has already happened.

Here is the complete architectural reference for the execution loop and system anatomy:

THE LOOP  (one turn of the billing agent)
  goal        fixed in the instruction: resolve refunds per policy
  action      the model emits a tool request; your code runs it
  observation the result comes back as text, into the window
  adaptation  the model reads everything again and chooses next
  exit        goal met, or a boundary hit (over $500 → a human)

THE ANATOMY  (the instruction that commits the model to the goal)
  identity     what it is solely for            → fixes the goal
  doctrines    one per capability; what is true,
               and what to say when the source
               is silent; for a custom tool,
               when to call it, in what order,
               how often, what an error means   → disciplines observation
  style        format, register, tone, countable → keeps adaptation in voice
  framework    task directive (the deliverable),
               reasoning directive (the decision
               to make before replying), every
               turn or the order of phases as a
               numbered list, and guardrails
               ("never", + what instead), one
               to a line                        → governs the actions
  examples     one positive exchange per branch → the target, and the test
  boundaries   always-first and never, one to
               a line                           → the second exit, in text;
                                                  the wall lives in code

THE TWO RULES
  checkable     a rule you can check is one whose rate you can measure;
                specific wording tends to raise that rate;
                where the task needs judgment, name the decision
                and give it fixed, defined outcomes
  a written rule shifts the likely continuation;
  a check in code guards the irreversible action before the tool runs

In the next lesson, we move the Tutor to the test bench: you will learn to evaluate its outputs systematically, isolate the one variable that moved, and build a review agent that scores drafts against a threshold a loop can gate on. Consult the syllabus to continue.