13 — AI Agents — An LLM Put in a Loop With Hands

"A chatbot that does more" filed agents under chatbots, which hid the structural difference. The one sentence that separated them: chat is one round of text-in/text-out; an agent is the same model wrapped in a loop that can touch the real world through tools. [1] Once I could see the loop, the jump from "suggest" to "do" stopped feeling like magic and started looking like plumbing.

The one idea: the same model, in a loop

The mental shift was smaller than I expected. A model like the one answering a chat window is already doing something agent-like on a tiny scale: it takes text in, decides what to say, and says it. The leap to an agent is not a smarter model — it's the same model run again and again, with tools it's allowed to call between rounds [2]. Each turn, it gets to _act_, not just answer.

The loop has three legs that repeat until the goal is met or the model says stop:

1. Perceive — read the goal, plus whatever the last action returned (an error, a file listing, a search result).
2. Decide — choose the next move: call a tool, or declare the task done.
3. Act — run the chosen tool and feed its result back in as the next observation.

That's the whole shape. Everything else — frameworks, fancy names, "autonomous" marketing — is scaffolding around this loop.

The reason this matters is that acting changes the world the model sees next. A chat answer is frozen the moment it's written. An agent's answer in round three can be shaped by what a tool returned in round two — a real error, a real row from a database, a real page that loaded or didn't. The model isn't predicting in a vacuum anymore; it's reacting to ground truth it just produced.

Tools are the agent's hands

Here's where "agent" stops being a metaphor and gets concrete. A tool is a function the model is allowed to call by name, with arguments it picks, whose return value becomes the next observation [3]. That's it. Read a file. Run a shell command. Search the web. Insert a row. Send a message. Each tool is a small, well-defined lever on the outside world.

A few things had to click before tools made sense to me:

• The model doesn't run the tool. It emits a structured request — "call read_file with path=/etc/hosts" — and a thin harness around the model executes it and hands the output back. The model is the brain picking levers; the harness is the hand that pulls them. "The model called a tool" is loose phrasing — the model _requested_ a call, the harness _performed_ it.
• Tools have schemas. Each declares a name, a description, and the arguments it accepts. The model is shown the menu and decides among them. A vague description gets picked wrongly; a tool missing from the menu can't be picked at all.
• The return value is just text. Whatever the tool does — query a database, send data to another service — what the model sees back is a chunk of text it reasons about. Tools don't make the model smarter; they widen the set of things it can check before deciding.

Without tools, a model can only talk about the world. With tools, it can reach into it.

The leap from "suggest" to "do"

This is the part I had to straighten out, because the difference sounds small and is actually large. When I ask a chat model for help, it _suggests_ — "you could open the file and check line 42." Useful, but the file is still unopened. I'm the one who copies the suggestion, runs it, reads the result, and pastes it back. The loop is in _my_ head, executed by _my_ hands.

An agent closes that gap. The suggestion and the execution are the same step: the model decides "check line 42," calls the read tool, sees the line, and continues. I stop being the relay between thought and action. That's the qualitative change — not a bigger model, but a model whose decisions take effect without me in the middle [1][3].

For frontend work this is where it gets concrete and a little unnerving. An agent with a file tool can edit a component. Add a shell tool (it runs commands on the computer) and it can run the typechecker (the checker that catches code mistakes), read the errors, and edit again. Add a browser tool and it can load the page, see the broken layout, and iterate. Each tool extends the loop's reach into the actual project — the same model that once told me "try adding flex-col" can now add it, rebuild, and confirm the fix itself.

The new failure modes

Handing a model tools doesn't remove its failure modes — it relocates them and adds a few. These are the ones I now watch for:

• Infinite loops. With nothing to stop it, the model can call a tool, get an unexpected result, call it again, and never converge. A step budget or a "have you tried this twice?" check in the harness separates a useful agent from one that burns tokens forever.
• Wrong tool, or right tool with bad arguments. The model picks among tools from their descriptions; a fuzzy description produces a fuzzy choice. delete_record(id=...) picked where archive_record(id=...) was meant is the agent equivalent of a typo — except it actually runs.
• Runaway / scope creep. "Fix the typo" can balloon into "and while I'm here, refactor the module," because each tool call widens what the model can see to "fix." A clear stop condition and tight tool permissions are the guardrail.
• Confident hallucination, now with side effects. A chat hallucination is a wrong sentence. An agent hallucination can be a wrong file edit or API call — wrong _in the world_, where undoing it is harder than scrolling up.

The thread through all of them: an agent's mistakes are no longer just text on a screen. They're actions, and actions have recipients. Permissions, step limits, and human-in-the-loop checkpoints (a person approving a risky step) aren't paranoia — they're the cost of moving from _suggest_ to _do_.

How I use this

The habit these notes left me with is a single question before I reach for "agent" as the answer: _does this task need a loop, or just a turn?_ If the next step depends on the result of the last one — read the error, fix it, run again — the loop earns its keep. If it's a one-shot explanation, plain chat is cheaper and safer. Picking the loop deliberately, scoping the tools tightly, and setting a stop condition is the difference between a tool that helps and one that thrashes.

References

[1] IBM, "What are AI agents?," IBM Think Topics, 2024. [Online]. Available: https://www.ibm.com/think/topics/ai-agents

[2] Anthropic, "Building effective agents," Anthropic Engineering, 2024. [Online]. Available: https://www.anthropic.com/engineering/building-effective-agents

[3] roadmap.sh, "AI Agents — Complete Guide," 2024. [Online]. Available: https://roadmap.sh/ai-agents