Picture a support-ticket assistant for an online retailer. It has four tools: lookup_order and check_refund_policy only read data, issue_refund moves money, and send_customer_email writes to a real customer. Some tickets need one lookup and one reply. Others, like a disputed refund, need steps that depend on what the lookup turns up. The interview question that follows is almost always the same: when would you build an agent instead of a fixed workflow, and how do you keep it from going off the rails?

An agent is an LLM (large language model) application where the model, not your code, picks the next step. It decides which tool to call next, or that it is done, inside a loop that feeds each result back to it. A workflow fixes the steps in code. If you can write the steps down before the run starts, as for a "where is my order?" ticket, build a workflow. Reach for an agent only when each step depends on what the last one found, as in the disputed refund.

The rest follows from that difference: what it costs, and what safeguards keep a model-driven loop bounded, limit context growth, and prevent refunds based on a misread ticket.

This question shows up in most AI engineer and forward-deployed engineer loops, often as a design discussion of fifteen minutes or more. Mid-level candidates are expected to tell a workflow from an agent, write the loop, and put a step limit and an approval on it. Senior candidates also justify the choice with cost and reliability, bound the loop three ways, manage context growth, place approvals by risk, and explain why long runs fail more often than short ones.

The tutorial assumes you already know how one tool call works: the model returns a tool name and JSON arguments, your code runs it, and the result goes back to the model. That single call, and its schema, is covered in Structured Output and Tool Calling.