AI log, day 06: an agent is a loop, not a personality

Day 05 was about telling real improvement from felt improvement, and I ended it saying that habit matters even more once a model stops answering and starts acting. Day six is that shift. “Agent” is the word doing the most marketing work in this whole space right now, and going in I half-expected it to name some new kind of model, something more autonomous or more intelligent than what I’d been poking at. It isn’t. An agent is a control-flow pattern wrapped around the exact same model from day 01. Once I saw the loop, the mystique fell off completely, and what was left was mostly ordinary backend plumbing.

The loop underneath the word

Strip everything off and an agent is this: you ask the model something, the model can either answer or say “I need to call a tool first,” you run the tool it asked for, you feed the result back in, and you repeat until it answers instead of calling another tool. That’s the whole thing. A loop of model, tool call, result, model again.

send prompt + list of available tools
loop:
  model responds
  if response is a tool call:
    run the tool
    append the result to the conversation
    continue
  else:
    return the final answer

The model isn’t doing anything new here compared to day 01. It’s still just generating the next tokens given a context. What changed is that some of those tokens are a structured request to call a function, and your code is standing by to actually run it and hand the output back. The intelligence people attribute to “the agent” is the model choosing which tool and with what arguments. Everything else in that loop is code you write and fully control.

Tool use is the actual mechanism

The piece that makes the loop possible is tool use, and it’s more mundane than “agent” makes it sound. You describe the tools to the model up front: a name, what it does, and the arguments it takes, basically a function signature in plain language plus a schema. The model, when it decides a tool would help, emits a structured call, the tool name and the argument values, instead of prose.

Your code parses that, runs the real function, a database query, a web search, a calculator, whatever, and puts the return value back into the conversation as the tool’s result. The model reads that result on the next turn and continues. The model never touches your database. It only ever emits a request that your code chooses to honor, which is a distinction worth holding onto, because it’s the whole safety boundary. This is also day 03 and day 05 collecting their debt: a tool call is the tightest possible interface, a strict schema in and a strict result out, and that’s exactly what made it testable and what makes it controllable.

Where it actually gets hard

The loop is simple. Making it reliable is not, and none of the hard parts are the model being clever.

The first is that the model can call the wrong tool, or the right tool with bad arguments, and the whole loop happily proceeds on the mistake. A search with a garbage query returns garbage, gets fed back, and the model reasons confidently on top of it. Errors don’t announce themselves. They just flow downstream as if they were facts.

The second is that things loop. A model can get stuck calling the same tool over and over, or ping-pong between two, never deciding it has enough to answer. So real agent code needs a hard cap on iterations, the same defensive instinct as any backend loop that talks to something that might not converge. Without it, a confused agent doesn’t fail fast, it burns tokens and time until something else stops it.

The third is that every tool call is a place to leak or to do damage. The model asked to run a tool, but your code decides whether that tool should be allowed to delete, to spend money, to touch production. A tool the model can call is a capability you’ve handed it, and “the model wanted to” is not authorization. The interesting engineering in agents is almost entirely here, in the guardrails around the loop, not in the loop.

Why day 05 comes back immediately

An agent is much harder to evaluate than a single prompt, and that’s exactly why the eval habit from day 05 matters more, not less. A one-shot prompt has one output to check. An agent has a whole trajectory: which tools it called, in what order, whether each call was reasonable, and whether the final answer was right. It can reach a correct answer through a nonsense path, or a wrong answer through a reasonable-looking one, and a single spot check hides both.

So the table from day 05 grows a column. It’s no longer just input and expected output, it’s also which tools you’d expect a sensible run to call, so a change that quietly makes the agent take a dumber path shows up before it ships. Without that, you’re back to shipping on vibes, except now the vibes are driving something that can act on the world instead of just describe it.

What actually changed in how I think about it

Going in, “agent” sounded like a step change in capability. Coming out, it reads as a step change in responsibility. The model didn’t get smarter, it got hands, and hands are exactly the thing you have to be careful about. The framing that stuck is that building an agent is 20 percent prompting the model to use tools well and 80 percent ordinary engineering: validating arguments, handling tool failures, capping the loop, deciding what each capability is allowed to touch, and evaluating whole trajectories instead of single answers. It’s less magic than the word promises and more plumbing, which, after five days of this log, is starting to feel like the recurring lesson.

What’s next

Day 07 gets into cost and latency in production, looking at an agent’s multi-call loop through a backend engineer’s cost-per-request instincts, because a loop that calls the model five times to answer once has an economics all its own.

Regular posts continue in between, as always.