When does an assistant become an agent?

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.

Follow one loop

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.

Separate a workflow from flexible action choice

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.

Give tools narrow contracts

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.

Watch state and uncertainty

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.

Set a stopping condition

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.

Trace a failure

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.

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.

Continue to the next lesson.