The fifth stop on my AI roadmap is where a model stops being a question-and-answer box and starts doing things: searching, calling an API, editing a file, booking something. That is an agent, and it is the most powerful and the most dangerous thing on this roadmap for the same reason. A model that can act can act wrongly, fast, and at scale. So this stop is half “how it works” and half “what you must put around it”.
From answering to doing
The mechanism is simpler than the hype suggests. With tool use (also called function calling), you describe some functions to the model: their names, what they do, what inputs they take. Instead of answering in prose, the model can reply “call this function with these arguments”. Your code runs the function and hands the result back. The model reads it and decides what to do next.
Picture giving an assistant a phone and a list of numbers they may call. They still do the thinking; the phone just lets the thinking reach the world.
flowchart LR
T[Task] --> R[Model reasons about the next step]
R --> C{Needs a tool?}
C -->|yes| U[Call the tool, get the result]
U --> R
C -->|no, done| A[Final answer]
That reason-act-observe loop is the classic agent pattern, known as ReAct. A second common shape is planner-executor: one pass writes a plan of steps, then the steps are carried out and checked. Either way, the model is choosing actions, one at a time, based on what it just learned.
Memory, and knowing when to stop
Two things separate a toy agent from a useful one. Memory: short-term is the running context of the current task, long-term is what it stores and can recall across sessions, usually in a database it can search. Without long-term memory every task starts from zero.
And a stopping rule. Agents can loop forever, retrying a failing step or chasing a goal they have misunderstood. Every real agent has a maximum number of steps, a budget, and a way to give up and report rather than burn tokens indefinitely.
NOTE
Long tasks should run asynchronously: kick them off, let them work in the background, and report back, rather than holding a web request open for ten minutes. Anything with more than a few steps belongs in a background job.
The guardrails that keep it from doing damage
Here is the part to take seriously. An agent with a shell tool can delete files. One with a payments tool can spend money. One that reads a web page can be tricked by text on that page into doing something you never asked. Three guardrails, in order of importance:
- Human in the loop. Any irreversible or expensive action, sending, paying, deleting, deploying, waits for a person to approve. The agent proposes; you confirm.
- Least permission. Give it only the tools the task needs, and scope each one tightly: read this folder, not the whole disk; this account, not all of them.
- Sandboxing. Run the agent’s actions in an isolated environment with limits on files, network, and time, so a mistake or a hijack cannot reach anything real.
CAUTION
Never give an agent a tool you would not hand to a stranger. Text an agent reads, a web page, a document, an email, can contain instructions aimed at it, and an agent with real permissions may follow them. That attack is called prompt injection, and the defence is not a smarter model, it is limiting what the agent is allowed to do in the first place.
Plugging in tools, and building your own
You will connect tools two ways. Directly, by describing your own functions to the model. Or through MCP (Model Context Protocol), a standard that lets any tool publish itself so any compatible agent can use it. Using MCP servers others built (for git, databases, docs) is the easy half. Building your own MCP server, so the agent can reach your app’s specific abilities, is the step that turns a general agent into one that works for your product.
Bigger jobs split into subagents: a coordinating agent hands well-defined pieces to separate agents with their own context, so no single context window has to hold everything. A related frontier is computer use, where an agent drives a browser or a screen directly instead of calling an API.
IMPORTANT
Fewer, sharper tools beat a huge toolbox. Every tool description rides along in the context window on every step, and a model choosing between fifty vague tools picks wrong more often than one choosing between five precise ones. Connect what the task needs, not everything you have.
The tools you actually reach for
| Job | Popular tools | Note |
|---|---|---|
| Agent SDKs and frameworks | Claude Agent SDK, Vercel AI SDK, LangGraph, Mastra | Free/OSS libraries; handle the loop and tool plumbing |
| Tool protocol | MCP | Open standard; many free servers, easy to write your own |
| Sandboxes | E2B, Modal, Docker containers | Isolate what the agent can touch |
| Background jobs | Any queue (Inngest, BullMQ, Trigger.dev) | For long-running agent tasks |
Power is permission
The lasting lesson is that an agent’s capability and its danger are the same property, and you do not get to keep one without the other. The skill at this stop is not making the agent do more. It is deciding precisely what it may touch, putting a human in front of anything irreversible, and isolating the rest, so that when it is wrong, and it will be, the damage is a rollback instead of a disaster.
Give it hands, but you hold the keys.
Sources
- Firecrawl: AI agent sandbox, how to safely run autonomous agents in 2026 for sandboxing, permission scoping, and limits
- Modal: best code execution sandboxes for tool-calling AI agents (2026) for tool calling and running agent actions in isolation
- Cosmonic: the complete guide to sandboxing AI agents in 2026 for capability scoping and auditability
- AI Builder Club: AI agents in 2026, build, deploy, and scale for the ReAct loop, memory, and MCP