You ask a chat assistant to find a free room for a study group. It can suggest a plan. If the application lets it inspect a calendar, choose a room, request a booking, and check the result, the system has crossed into a different kind of workflow.
Before you begin: Know the difference between a model output and an application capability.
How an agent uses tools
An agentic system uses model outputs to help choose actions toward a goal. The application provides tools, maintains state, interprets results, and decides whether to continue. Definitions vary, so describe the actual control flow rather than relying on the word “agent” alone.
For the room task, a loop might read the request, call an availability tool, inspect returned rooms, propose a booking, obtain required approval, execute the booking, and verify confirmation. The model does not directly become the calendar. It emits a proposed action that application code must validate and carry out.
Agents and fixed workflows
A fixed workflow follows a predetermined sequence or branching rule. An agent gives the model more freedom to choose the next step based on observations. Both can use language models, and they can be combined.
If every event notice needs the same extraction, review, and formatting steps, a fixed workflow may be easier to test. If a research task requires deciding which source to inspect next, flexible action selection may help. More autonomy is a design choice with costs, not a universal upgrade.
Who chooses the next step?
Both a fixed workflow and an agent can call tools. The distinction in this example is who selects the next action. A fixed workflow follows a route written by the developer. An agent asks a model to choose among allowed actions based on the current goal and observations.
That choice needs boundaries. Define the tools it may use, a stopping condition and a way to report that it could not finish. More steps are not evidence of more progress. In the activity, locate the exact decision point where control passes from fixed code to model selection, then ask what the surrounding code still has to enforce.
Every signup always follows validate, store, notify.
Let the model choose whether another lookup is needed before answering a question.
The system has a model-selected next step, with a need for tool limits and a stopping rule.
Define what each tool can do
A tool needs a clear name, inputs, outputs, and failure behavior. “Search rooms” should return structured information such as room ID, capacity, and availability, not a vague success message. “Book room” should require the exact room and time, authenticated authority, and protection against duplicate bookings.
The application checks permissions before execution. A model-generated field that says “approved” is not user approval. If an action changes an external system, the system should know which person authorized which version of the action.
Track the task and its results
State records what the system knows so far: the original request, available rooms, selected candidate, approval status, and tool results. A plan is not a completed action. A successful request to a tool is not always confirmation that the external change occurred.
Suppose booking times out after the calendar service may have accepted it. Retrying blindly can create a duplicate. A well-designed workflow checks the outcome using an operation identifier or another supported reconciliation method. We will implement these ideas in later lessons.
When should the agent stop?
An agent needs limits on steps, time, spending, and allowed actions. It should stop when the goal is met, required information is missing, permission is absent, or a failure cannot be resolved within its budget.
For the room task, “no suitable room available” is a legitimate result. Booking a room too small for the group just to finish would violate the task. The system should expose the constraint and let the user decide what to change.
Find a failed booking
The availability tool returns a room for 12 people, but the group has 16. The assistant says “Booked successfully” without calling the booking tool. Identify two separate failures.
Separate selection from execution
The selected room fails the capacity requirement. The success claim also lacks an executed and verified booking. Fixing only the wording would not make the room suitable, and choosing a suitable room would not prove it was booked. A reliable trace must preserve both the decision criteria and the actual tool result.
Practice with feedback
Find the decision point in a loop
System A always runs: fetch emails, extract fields, write rows, send confirmations. System B is given the same goal plus four tools and decides what to call next each time.
Separate a fixed workflow from a system that chooses its own next action.
Check your understanding
Your task
Take one workflow you know and decide, with reasons, whether it needs an agent.
These notes stay on this page. Download them before leaving.
What to include
- You identify a specific step where the action varies, or state that none does
- Tool contracts name inputs, effects, and what they cannot do
- The stopping condition is an observable end state, not 'when done'
- The failure trace names what you would inspect first
Compare with a worked answer
Here is one way to answer. Check how it uses the information in the task.
Workflow: answer member emails about class availability. The steps today: read email (me), look up the class (me), reply (me). Is there a step where the next action genuinely varies? Yes: some emails name a class, some describe it vaguely, some ask about two classes, and some are not about availability at all. The lookup that should happen next depends on what the email turns out to contain.
If agentic: tools with narrow contracts: - find_class(query: str) -> list of at most 5 {slug, title, day, time}. Read-only. Cannot create classes. - places_left(slug: str) -> int. Read-only, single class. - draft_reply(slug: str|null, kind: 'available'|'full'|'not_found') -> string. Returns text only; sends nothing. Stopping condition: a draft reply exists for every class mentioned in the email, or the agent has recorded that the email is not about availability. Step budget: 8 tool calls. On exhaustion the email is queued for me with the trace attached, and no draft is used. What I would look at in a failed trace: the first call whose observation contradicted the plan. Usually it is find_class returning five near-identical results and the loop re-querying instead of asking.
Note that nothing here sends an email. The one irreversible action stays with me, which is why an 8-call ceiling is a tolerable failure and not an incident.
When you are signed in, opening the challenge carries your edited working notes into its draft in this browser. The challenge has its own completion record. Practising here does not award points or mark it complete.
Next, we will learn how to inspect new AI announcements without mistaking a demonstration for evidence that a system works in your setting.
Further reading
Anthropic's Building Effective Agents distinguishes workflows and agents. ReAct is a research example of combining reasoning and tool-mediated interaction.