What is an AI Agent?

This post answers the 'so what' for agents, and the cover frames it with a concrete contrast: a chatbot can describe how to book a flight, an agent can book it. The reader has learned what an agent is; now they need a visceral reason the difference matters.

The core argument runs through the whole post: moving from answering to acting changes the category of problems AI can solve. It's the difference between getting advice and getting outcomes, and that's why agents went from research curiosity to the thing every team is suddenly building.

The opening slide states the value plainly: a plain LLM hands you instructions and you still do the work; an agent does the work. That closing of the execution gap is the entire payoff. The value isn't that the text got smarter — it's that you can now offload a whole multi-step task instead of a single question.

This reframing matters because people often evaluate agents on answer quality, the wrong axis. The right axis is task completion: did the thing actually get done, end to end, with the agent recovering from the inevitable hiccups along the way.

This slide enumerates the concrete capabilities agents add over a bare LLM. They reach live data through tools instead of being frozen at a training cutoff. They take real actions — writing, sending, querying, deploying. They execute multi-step plans rather than one-shot replies. And they self-correct when a step fails.

Each of these is something an LLM alone simply cannot do, no matter how large. They're not properties of the model; they're properties of the loop and the tools around it. Listing them makes clear that 'agent' is a capability upgrade achieved through architecture, not scale.

The compare diagram dramatizes the shift from prompt to workflow. The LLM column produces a how-to and then stops, working from frozen knowledge in a single turn. The agent column produces a completed outcome, executing for you, pulling fresh data, and looping until finished.

The two phrasings at the top — 'Here's how to do X' versus 'Done, X is complete' — are the whole post in two sentences. That's the mental snapshot to keep: an agent changes the deliverable from instructions to results.

The 'why now' slide grounds the hype in two real maturity points so the reader understands this isn't arbitrary. First, LLMs got reliably good at reasoning and at producing structured output, which is what makes tool selection dependable. Second, function-calling and tool-use APIs standardized across providers.

Before both of these, the loop was too flaky to trust — models picked wrong tools or emitted malformed arguments too often. Once both matured, the agent loop became dependable enough for real tasks. It's still not perfect, and that honesty matters, but it crossed the threshold from demo to useful.

This slide shows where agents genuinely earn their keep today, grounding the abstraction in real domains. Research agents search, read, and synthesize. Coding agents read a repo, edit files, and run tests. Ops agents triage tickets, query logs, and act. Data agents pull, join, and summarize on demand.

The common thread is that each task is multi-step, benefits from live data or real actions, and has a checkable outcome. That pattern — multi-step plus tool-using plus verifiable — is the signature of a good agent use case, and naming concrete examples helps the reader recognize it in their own work.

The bar chart quantifies the capability gradient so the reader feels the progression. A one-shot LLM completes the fewest tasks because it can only answer from frozen knowledge. Adding tools lifts it — now it can fetch facts. A full agent, with the loop and self-correction, completes the most.

The numbers are illustrative, but the shape is the point: capability rises with each layer of agent machinery you add. It also sets up the honest counterpoint two slides later — that this rising capability comes with rising cost and risk, so more is not always better.

This code slide makes the abstract 'acting beats answering' argument concrete with a data question. A one-shot call asked to sum a column can only guess — it never sees the file, so it may hallucinate a number. The agent version actually reads the CSV, runs real Python to compute the sum, observes the true result, and reports a grounded answer.

The contrast is the whole value proposition in one example: the loop lets the model verify against reality instead of pattern-matching a plausible-looking number. Grounding through action is exactly what makes agents trustworthy for tasks where correctness matters.

Honesty about limits builds trust and pre-empts the obvious objections. Errors compound across steps, so a long agent run is fragile. The agent can take wrong actions that have real consequences, not just print wrong text. It's slower and more expensive than a single call because each step is another model invocation. And its behavior is hard to fully predict or test because the model chooses the path.

These aren't reasons to avoid agents; they're the constraints that shape good design. Each one maps directly to a mistake in post 5 — bounding steps, gating dangerous actions, keeping chains short, and adding observability.

This slide keeps the post intellectually honest by naming when an agent is the wrong tool. If the task is a single, well-defined transformation — classify this text, summarize that document — a plain LLM call is cheaper, faster, and far easier to trust and test.

The rule of thumb is to reach for an agent only when the task genuinely requires multiple steps, live data, or real-world actions. Wrapping a one-shot task in an agent loop just adds cost, latency, and failure modes for no benefit. Knowing the boundary prevents cargo-culting agents into problems that don't need them.

The bottom-line slide compresses the post into four takeaways. Agents turn AI from advice into action. They're best for tasks that are multi-step, tool-using, and live. That power brings new failure modes you didn't have with a single call. And the engineering discipline is to use the simplest thing that solves the problem.

That last principle is the one to carry forward: agents are a powerful tool, not a default. The reader should leave able to decide, for any given task, whether an agent is genuinely warranted or whether a plain call would do.

The CTA hands off to the mechanics post. Having argued why acting matters and where it pays off, the natural next question is how the loop actually produces those actions.

Day 76's teaser — the reason-act loop, step by step — promises to open the box. Post 3 walks through the reason-act-observe cycle, how tool calling works at the JSON level, the ReAct pattern, where memory lives, and how the loop knows when to stop.