AI Agents & Automation

One line of code separates the two

Everything so far has been a conversation. You ask, the model answers, you do something with the answer. Even RAG — the model reads, then tells you. The doing stayed with you.

An agent is what you get when the model can ask for things to be done and then see the results. That's it. Not a different model, not a special API — the same model, called in a loop, with permission to request actions.

A chatbot calls the model once and shows you the answer. An agent calls it again, with the results of whatever it last asked for, until it stops asking.

That loop is the entire difference. And the crucial thing to hold onto: the model still never does anything itself. It emits text saying "I'd like to run search_issues with these arguments." Ordinary code you wrote reads that, runs the function, and hands the output back. The model's only power is choosing what to ask for next.

Watch the loop run

Abstract descriptions of agents are confusing; watching one is not. Here's an agent with two tools — get_current_user() and search_issues() — answering a question it cannot possibly answer on its own. Watch the message travel, or pause and step through it yourself.

Notice what the model never did: it never queried a database, never knew who "me" was, never counted anything. It made three decisions — ask who the user is, ask for their bugs, stop asking and answer — and your code did all the work in between.

Tools are an interface you design

The model chooses tools by reading their names and descriptions — that's all it has. Tool definitions are therefore documentation written for a reader who will act on it immediately and cannot ask follow-up questions.

Which means the same capability, described two ways, produces visibly different behaviour from an identical model. Compare:

Three things earn their keep in every tool description: what it does, when to reach for it — including when not to — and what comes back. Vague descriptions produce an agent that flails between plausible options; precise ones produce one that moves in a straight line.

MCP: why it exists

Once tools are useful, everyone wants the same ones — your files, your database, your issue tracker, your calendar. The problem is that every agent framework historically spoke its own dialect, so every tool had to be rebuilt for every agent.

The Model Context Protocol is a standard for that connection: tools describe themselves once, in a common format, and any agent that speaks the protocol can use them. Toggle between the two worlds:

It's the same shape of fix as device drivers, or USB. The value isn't cleverness, it's that the integration count stops multiplying — and that a tool someone else wrote works with your agent without either of you having met.

Where the human goes

An agent that can act can act wrongly, and it does so at machine speed and without hesitation. But gating every action behind approval defeats the point — you've rebuilt manual work with extra steps.

The workable rule is the one from Step 03, applied to actions instead of answers: gate on blast radius. How bad is this if it's wrong, and can it be undone?

Auto-run, ask first, or never?

What's worth automating

Agents pay off where a task is multi-step, tedious, and checkable — triaging inbound issues, migrating a pattern across a codebase, gathering scattered data into one report, following a runbook that's always the same until it isn't.

They pay off badly where the work is one clear step (just call the model), where being wrong is expensive and hard to detect, or where you couldn't tell a good result from a bad one. That last case is the real trap: an agent will complete the task either way.