Chapter 1

An Agent Is a Product Cycle, Not a Prompt

Before writing code, it's worth agreeing on what an agent even is - because the rest of the book builds exactly that, not a "smart answer." A specialized agent receives a goal, sees a limited set of data and tools, picks the next step, observes the result, and finishes with one of a set of known outcomes. The key here is the split of roles: the model makes probabilistic decisions, and the application owns the rights and the facts.

The easiest way to see it is as a short cycle that any agent turn reduces to.

  1. Request
  2. Decision
  3. Tool
  4. Observation
  5. Outcome

Each arrow does its own job. The request is the goal and context. The decision is the model's probabilistic choice: which allowed tool to call, what to clarify, when the task is already solved. The tool gives the agent hands, the observation returns a verifiable result, and the outcome is one of the finals described in advance. And on this cycle you immediately see who owns what: the model chooses - which allowed tool to call and when to stop; the code enforces authentication, authorization, validation, transactions, limits, and confirmations; the data proves that the policy is active, the order belongs to the customer, and the action can be performed.

Hence the book's main boundary, which we'll return to in every chapter.

The main boundary. The model may propose an action. Only trusted server code decides whether it's allowed and how to perform it.

It helps from the start to tell an agent apart from what isn't one - most tasks don't reach it, and that's good.

System · Who picks the next step · When it's enough

  • A single API call - No step; Classification, extraction, a short grounded answer
  • Workflow - Your code; The order of stages is known in advance
  • Agent loop - The model inside a bounded runtime; The path depends on tool results

Read the table by the "who picks the next step" column. A single API call picks no step at all - that's enough for classification, extraction, or a short grounded answer. A workflow follows an order set by your code. And only an agent loop hands the choice of step to the model inside a bounded runtime - when the path isn't known in advance. The agent is the most powerful and most expensive level; reach for it only when the task truly requires it.

That distinction is where agent engineering begins. And the first step isn't to pick a model - it's to narrow the task into a contract.

Knowledge check

What sets an agent loop apart from a workflow?

Links