You added an AI feature to your app, and for a while one model call did the job: text in, answer out. Then it needed more: look something up, decide what to do, then act, sometimes several times over. That is the moment a plain call becomes an agent, and not the kind that builds your code, but one you ship inside your product for your users. This chapter gets you knowing when your product needs an agent, and how one works.
7.3.1A call answers; an agent acts
A plain call answers. You send text, the model sends text back, and the exchange is over. An agent acts instead: it runs a loop, deciding and doing and checking until the task is actually done.
Each time around, it decides the next step, calls a tool (a function you let it run to fetch data or take an action), and reads the result before deciding again. The loop, not the wording of any one reply, is what makes it an agent.
7.3.2Give it tools, not just words
Words tell the agent what you want; tools are what let it act on the world. A tool is a plain function with a name, a short description so the model knows when to reach for it, and the inputs it takes.
That loop is the whole engine. The real design work is which tools you expose, and how tightly you scope each one.
7.3.3Reach for a framework when the loop gets real
You can write that loop yourself, and for one or two tools you should: it is a dozen lines and you understand every one. Libraries such as LangChain and LangGraph exist to handle the loop, the state, and the tool wiring once it grows.
Name them as options, not defaults. Reaching for one too early buys complexity you have to learn before you have a problem it solves.
| Keep it a simple loop | Reach for a framework |
|---|---|
| One or two tools | Many tools to coordinate |
| A few steps, then done | Long or branching runs |
| You can read every line | State and retries to manage |
7.3.4Keep it on a leash
An agent with tools can do real damage, because a tool is real power and the model decides when to pull it. Give each tool the least privilege that still does the job: read-only over write, a scoped key over a master key, a test target over production.
For anything you cannot undo, deleting data, sending money, emailing users, the agent proposes and a human approves. It is the same discipline the security chapters apply to agents that read untrusted input: the shorter the leash, the less any mistake or attack can reach.
Do this now: paste the prompt, and only if your feature truly needs an agent, wire the smallest tool-using loop with least-privilege tools and an approval gate before any action you cannot undo.
