Agents: Models That Do Things

What an agent actually is

Strip away the hype and an agent is a simple formula: agent = model + tools + memory + a loop. The model decides the next step (but can only ever emit a request, never act); your program runs the tool; the result gets added to the context; the model is called again. Repeat until it's done.

Perceivegoal + context

→↓

Plan next step

→↓

Actcall a tool

→↓

Observereal result appended

→↓

Reflect↺ loops back to plan

Stop when goal achieved ✓ · budget used up · needs a human · stuck

Two facts follow. First, whatever you put in the context IS the decision-making process: the tool descriptions, the observations, the task. Second, since your program (not the model) runs the tools, your program is the security boundary. Treat the model as an untrusted advisor inside a trusted executor.

Try it yourself: Sketch your own agent loop on paper›

Pick one task you currently do manually and repeatedly (triaging your inbox, checking a dashboard each morning). Write down 3–5 tools it would need as function signatures (e.g. list_unread(), archive(id), flag_urgent(id)). Then trace one example by hand: model decides → tool runs → result comes back → model decides again. You've just designed an agent without writing a line of code.

Tools are APIs for an unusual user

The model picks tools by reading their names and descriptions, so your tool list is really a prompt. What works:

Say when to use a tool, not just what it does. "Call this when the answer depends on current access data" beats "Searches identities."
Bundle a workflow into one tool. One investigate_user(id)that returns access + recent logins + recent changes beats ten tiny tools the model has to orchestrate (ten chances to slip).
Return only what matters: the five useful fields, not a 40-field API dump, and always require a reason argument on anything sensitive, which gives you a built-in audit note.
Support "dry run."A preview of what a write would do doubles as the thing you show a human for approval.

Try it yourself: Rewrite a tool description two ways›

Write two descriptions for the same imaginary tool: one that just states what it does ('Searches identities'), one that also states when to use it ('Call this when the answer depends on current access data, not historical'). Imagine skimming a list of 20 such tools quickly: notice which phrasing you'd trust faster to pick correctly.

Beating the reliability math

Remember that 98%-per-step → 67%-per-task problem? The cure is verification, and it's worth more than a smarter model:

Check the effect, not the acknowledgement. After a write, independently read the system back: "is the account actually disabled?" Never trust the "success" response alone. (Identity people already know this as provision-then-verify.)
Use a fresh-context reviewer. A second pass by a model that didn't do the work, holding only the requirements, catches mistakes the author can't see. This is the best quality-per-dollar trick in the whole field.
Detect stuck loops and cap budgets. If it repeats a failing action, stop and escalate. Iteration/token/time limits are correctness tools, not just cost controls.

Try it yourself: Add a verification step to your next AI task›

Next time you use an AI tool for anything multi-step, add one deliberate extra step: after it reports success, independently check the actual result yourself instead of trusting the claim. Track, over your next 10 uses, how often that check catches something the model's own report missed.

Making agents fast, not just cheap

Cost optimization (a few parts back) and speed optimization are related but distinct: a cheap agent that takes 90 seconds to answer still gets abandoned. A few techniques that target latency specifically:

Parallelize independent tool calls. If step 2 and step 3 don't depend on each other's output, fire them concurrently instead of serially. Most agent frameworks, LangGraph included, support this as a first-class pattern rather than something you bolt on.
Stream partial output. Showing the model's answer, and its intermediate tool calls: as they happen makes a 20-second task feel instant, even though total latency hasn't changed. Silence is what makes users assume something broke.
Route per step, not just per request. One agent run can call a cheap model for mechanical sub-steps ("extract this field," "summarize this ticket") and reserve the frontier model for the one step that actually needs judgment.
Cache semantically, not just exactly. For read-heavy agents: an IAM helpdesk answering the same handful of policy questions worded differently every time: cache by embedding similarity, not just byte-identical matches.

Two before/after examples: an access-request triage agent that ran its entitlement lookup and its risk-score lookup serially, 45 seconds: dropped to 12 by parallelizing the two. A JML mover agent that used to go silent for two minutes while it worked now streams its checklist progress live, and the support tickets asking "is this stuck?" stopped.

Try it yourself: Time sequential vs. parallel calls›

If you have API access to any model, fire two independent prompts at once (using async calls, or just two browser tabs started at the same second) versus running them one after another and timing both. The wall-clock gap you measure is exactly the effect parallelizing independent tool calls has on an agent's total latency.

How agents fail (naming them helps fix them)

Failure	What it looks like	Fix
Under-specified goal	It follows the letter, not the intent	Give the full spec and "definition of done" up front
Acting on assumptions	"The request was probably approved…"	Require reads before writes
Compounding drift	A small early error snowballs	Verification checkpoints; fresh restarts
Over-eagerness	Unrequested "helpful" extra actions	Explicit boundaries; gate writes
False success	"All done!": but it isn't	Demand evidence for each claim

Try it yourself: Read a real failure post-mortem›

Search for a public write-up of an AI agent going wrong in production (several well-known ones exist from coding agents and customer-support bots). Try to match what happened to one of the named failure modes in the table above. Most real incidents map cleanly onto one or two of them.

The security model, in one breath

Break the lethal trifecta per workflow; let an agent act with the requester's permissions rather than a powerful shared account (so it can never do more than the person it's helping); give each agent least-privilege tools with writes behind approval; and treat every agent as a first-class identity: its own account, short-lived credentials, its own audit trail, and subject to access reviews like any employee. Hold that thought; it's the heart of the IAM section.

The five guardrails every production agent needs, in one place: (1) scoped permissions: the agent acts as the requester, never as itself with elevated rights; (2) a hard action budget: cap tool calls per run, kill runaway loops before they compound; (3) dry-run before write: every mutating action previewable before it executes; (4) independent verification: check the effect, not the agent's own claim of success; (5) a human-approval gate on anything irreversible or above a defined blast-radius threshold. Miss any one of these and the other four don't save you.

Try it yourself: Audit a tool you actually use›

Pick one AI tool you use that can take real actions: an IDE coding agent, a browser-automation agent, anything that writes or clicks, not just chats. List out what it can actually access and do. Check it against the lethal trifecta: does it have private-data access, exposure to untrusted text, and an unsupervised way to act, all three at once? If yes, that's a real gap, not a hypothetical one.