Why Agents Now?

You’ve built the chatbot. You wired up a model, gave it a system prompt, streamed answers into a chat box, and it was genuinely useful — it could explain your refund policy, summarize a document, answer a question. And then a user asked it to actually issue the refund, and it couldn’t. It could only ever tell. That wall — between a model that talks about the work and a model that does the work — is what this book is about tearing down.

The whole difference is one word: act

A chatbot answers. An agent acts. That’s the entire distinction, and everything else follows from it. Ask a chatbot “what’s our refund policy?” and it writes you a paragraph. Ask an agent “refund my annual plan,” and it looks up your order, checks the policy, calls the payment system’s refund function, updates the ticket, and emails you a confirmation — doing each step, not describing it.

The moment a model can act, three things change at once. It needs tools — real functions it can call. It needs a loop — because acting is rarely one step. And it needs to be trustworthy, because a thing that can issue refunds can also issue wrong refunds, leak data, or be tricked by a malicious document. A chatbot that says something wrong is embarrassing. An agent that does something wrong is a customer calling their bank.

💡 Tip: Hold onto that one-word test — tell vs act — for the whole book. Whenever you’re unsure whether you even need an agent, ask: does this feature need the AI to do something with a real effect in the world, or just to tell the user something? If it only tells, you probably don’t need an agent.

What an agent actually is

Strip away the marketing and an agent is refreshingly simple. The core piece is the augmented LLM — a plain language model given three extra abilities: it can call tools, it can retrieve information, and it can remember across the conversation. That’s the single building block; everything fancy is made of copies of it.

The loop is where “agent” actually happens. You give the augmented model a goal and a set of tools, and it runs this cycle:

• Think — the model looks at the goal and what it knows so far, and decides the next action.
• Act — it calls a tool (say, lookupOrder).
• Observe — your code runs the tool and hands the result back to the model.
• Repeat — the model reads the new information and decides again: call another tool, or stop because it’s done.

Notice what makes it an agent and not a script: the model decides the path. You don’t hard-code “first look up the order, then check the policy, then refund.” You give it the tools and the goal and it works out the sequence itself — which is why it can handle messy, varied requests a fixed script can’t, and exactly why you need the whole second half of this book to keep it in bounds.

Workflows vs agents: the fork in the road

Here’s the distinction that will save you the most pain: not everything that uses tools in a loop should be a free-roaming agent. Most of the time, you want a workflow. A workflow is a fixed path you write in code, with the model doing the smart bits at each stop. It’s predictable, cheap, easy to test, and easy to debug, because you hold the steering wheel. An agent is when you hand the model the steering wheel — priceless for open-ended problems, but slower, costlier, harder to test, and harder to trust.

⚠️ Pitfall: The most common mistake in this field is reaching for a full autonomous agent when a simple workflow would do — because “agent” sounds more impressive. A three-step workflow that runs the same way every time is better than an agent for a three-step problem. Start with the simplest thing that works, and add autonomy only when you feel the fixed path failing.

Meet the Cortex Agent

Across eighteen chapters we build one real product: the Cortex Agent — a support-and-operations autopilot for a team. A ticket lands: “I was charged twice for my annual plan — please refund the duplicate.” The agent reads it, searches the company’s help docs, looks up the customer’s real billing history through a tool, reaches the payment provider through an MCP connection, drafts a reply — and because a refund moves real money, it pauses for a human to approve before it issues anything. If the server crashes halfway through, the whole thing resumes exactly where it left off and finishes — without refunding twice.

Build the Cortex Agent and you’ve built the reusable spine of any production agent; swap the domain and the same architecture powers a coding agent, a research assistant, or an operations bot. The product is the vehicle. The destination is knowing how to ship agents you can trust.