Most posts about AI agents show you the demo. The demo always works. Nobody writes about the part where it doesn't.
I built an agent to watch a few inputs, decide if something needed action, and either handle it or escalate to a person. That's a common shape for these projects — more common than most people realize, and worth telling apart from a plain chatbot before you even start building. The difference comes down to how much the system decides on its own versus just following a script.
It worked fine in testing. Then I pointed it at real, messy input, and it started doing things the demo never showed me.
It forgot what it had just decided
A few turns in, the agent would make a decision, act on it, and then reconsider the same thing later as if it had never happened.
The problem wasn't the model being careless. It was me mixing up two different things: the conversation history, and actual memory. Everything the agent had "seen" was technically still there in the transcript, but nothing was stored in a way the agent could reliably pull back out three steps later.
Once I split things into short-term context for the current task and a separate store the agent could deliberately write to and check, this stopped happening. I wrote more about that distinction in this piece on designing agent memory — if your agent seems to have short-term memory loss, that's usually the actual bug.
A failed tool call turned into a loop
One of the agent's tools called an internal service that timed out. Instead of surfacing that as an error, my retry logic and the agent's own instinct to "try again" stacked on top of each other and turned into something close to an infinite loop.
Nobody designed that behavior. It just emerged from two reasonable pieces of logic sitting next to each other.
The fix was boring: a hard limit on retries, real backoff between attempts, and a way for the agent to notice it was stuck and hand off instead of trying forever. This is also where I started questioning whether every step needed a model in the loop at all. Some of what I was calling "agent work" was really just a trigger and a response, and comparing Zapier and GitHub Actions for that part reminded me that plain automation handles retries and failure states like this out of the box.
It called a method that doesn't exist
This was the most interesting failure. The agent confidently called an internal function that was never real. It matched our naming conventions closely enough to look plausible, and the model just went with it.
That's the risk that comes with giving a model a set of tools and letting it decide which one to use. Two things helped. First, checking every tool call against a real schema before running it, so a made-up call fails immediately instead of quietly doing the wrong thing. Second, going back and being precise about what each tool actually was. Most of mine were thin wrappers around webhooks and internal APIs, and understanding what a webhook actually is versus what an API call actually does made it obvious where the model's idea of "how to trigger this" had drifted from what the system actually expected.
It wasn't as autonomous as I thought
By the end, I noticed most of the actual decisions in the system were hardcoded branches and guardrails. The model was doing one narrow judgment call in the middle, not really running the show.
That's not a failure. A lot of tasks people call "agent projects" are better off as a deterministic pipeline with a model handling the one part that genuinely needs judgment. The difference between RPA and an AI agent is worth understanding before you commit to the more complex version, because sometimes the boring, predictable bot is the right answer.
What I'd do differently
Separate memory from context before you need to. Put a ceiling on every retry path. Validate tool calls against a real schema instead of trusting that a plausible call is a correct one. And be honest about whether the task needs an agent at all, or just a script with a trigger.
None of that is a surprising lesson once you've hit it. It's just easy to miss while you're focused on getting the happy path working.
I write more of these build notes on agents and automation on Procwire, including a full archive of the guides linked above.
Top comments (0)