What is an AI Agent?

This is the mistakes post, and the cover sets the tone bluntly: agents are easy to demo and brutal to ship. The failures are rarely clean crashes; they're an agent that loops forever, burns budget, confidently calls the wrong tool, or takes an irreversible real-world action because no guardrail stood in front of it.

The five mistakes covered are the ones almost everyone hits early: the unbounded loop, vague tool descriptions, compounding errors across steps, dangerous powers without a checkpoint, and flying blind with no tracing. Each has a concrete, cheap fix, which is the point of the post.

The first and most fundamental mistake is letting the loop run without a ceiling. An agent that gets confused — picks a tool that doesn't resolve its goal, then tries again, and again — will happily call tools forever, accumulating cost and latency while never converging on an answer.

The fix is non-negotiable and trivial: cap the number of steps and return a clear message when you hit the cap. Every agent loop needs a brake. This is the single most common way a demo agent becomes a runaway bill, and it's the easiest of all the mistakes to prevent.

This code slide shows the fix as a one-line discipline: wrap the loop in range(MAX_STEPS) so it always terminates. Inside, the structure is the familiar one — call the model, return if there's no tool call, otherwise run the tools and continue.

The crucial detail is the final line after the loop: when the step limit is hit, you return a clear, honest message with whatever partial result you have, rather than silently failing or hanging. A bounded loop that degrades gracefully is the difference between an agent that's safe to deploy and one that can take down a budget or a service.

The second mistake is underestimating how much the model depends on tool descriptions. The model chooses among tools using nothing but their names, descriptions, and schemas. A tool called 'process' with no typed parameters is an invitation for the model to call the wrong thing or pass malformed arguments.

The fix is to write each tool's spec as if briefing a new hire who will only ever read that one paragraph: a precise name, a clear statement of what it does and when to use it, typed parameters, and any limits. Tool descriptions are prompt engineering — they directly determine the agent's reliability.

The compare diagram makes the second mistake tangible by putting a vague spec next to a clear one. On the left, a tool named 'handle' with untyped parameters and a description of 'does stuff with data' leaves the model guessing. On the right, 'refund_order' with a typed JSON schema and a precise description of refunding an order by id leaves no ambiguity.

The contrast drives home that the name and description aren't documentation for humans — they're the model's entire interface to the tool. A clear spec is the cheapest, highest-leverage improvement you can make to an agent that picks the wrong tools.

The third mistake is ignoring how errors compound over a multi-step run. Because each step builds on the previous one's output, a single early mistake poisons everything downstream. The math is unforgiving: a step that's 95% reliable, run ten times in sequence, yields only about 60% end-to-end reliability.

The practical implications are to keep agent chains as short as the task allows, validate tool outputs before trusting them, and design the agent to re-check rather than blindly accept its own prior steps. Long, unvalidated chains are fragile by arithmetic, not by bad luck, and treating reliability as multiplicative changes how you architect an agent.

The bar chart quantifies the third mistake so the reader feels the decay curve. One step at 95% is fine; five steps drops to roughly 77%; ten steps falls to about 60%. The subtitles show the arithmetic — it's just 0.95 raised to the number of steps — to make clear this isn't pessimism, it's multiplication.

The takeaway is to treat every added step as a reliability cost, not a free capability. It argues directly for shorter chains, validation between steps, and breaking a big task into smaller, independently-checkable agent runs rather than one long fragile sequence.

The fourth mistake is the most dangerous: exposing irreversible actions without a guardrail. An agent will eventually call any tool you give it, including the one that deletes records, spends money, or emails customers. The model's reasoning is good but not infallible, and a single wrong call on a powerful tool is a real incident.

The fix is layered: never expose an irreversible action without a confirmation step, scoped permissions, or a human in the loop for the risky calls. This is where the model-emits, your-code-executes boundary from post 3 pays off — because execution happens in your code, you can intercept and gate dangerous actions before they run.

This code slide shows the guardrail concretely. You maintain an allowlist of safe, read-only tools — search, read_file, calculator — that execute freely. Any tool not on that list routes through a human approval check before it runs, and is denied if the reviewer says no.

The pattern is simple but powerful: by default, deny anything that can cause real-world change, and require explicit approval to proceed. It turns the model's autonomy into a proposal rather than a command for the risky operations, which is exactly the posture you want when an agent has access to tools that spend money or delete data.

The fifth mistake is shipping an agent you can't see inside. When an agent misbehaves, you need to know why — but if you only logged the final answer, you're left guessing. The internal sequence of thoughts, tool calls, arguments, and observations is where the actual story of a failure lives.

The fix is to trace the full loop from day one: log every thought, every tool name and its arguments, and every observation. This is the single highest-return investment in agent reliability, because it turns 'the agent gave a wrong answer' into 'on step 3 it called the wrong tool with a bad argument' — a problem you can actually fix.

The checklist slide gathers all five fixes into a scannable pre-flight list the reader can apply directly. Cap MAX_STEPS so the loop always terminates. Write tools like a precise API spec. Validate outputs and keep chains short to fight compounding errors. Gate irreversible actions behind approval. And log every thought, call, and observation.

Run down this list and you avoid every failure mode in the post. It's ordered roughly by how early and how often each one bites — the unbounded loop and vague tools hit you immediately, while observability is the practice that makes fixing all the others possible.

The CTA closes both the post and the day. The reader has now seen agents from five angles: what they are, why they matter, how the loop works, how to build one, and how they fail in production. They have a complete, deployable mental model.

The teaser keeps the series momentum without promising a specific topic, pointing simply to the next entry in the 100 Days of AI. The reader leaves equipped to build a real tool-using agent and, just as importantly, to make it safe enough to ship.