AI Agents Are Powerful — and Sometimes Completely Out of Control
After more than twenty years in DevOps and infrastructure engineering, I’m used to systems failing in predictable ways. Hardware dies. Networks flap. Someone forgets to rotate a token. Fine. But AI agents? They fail in ways that make you stop and wonder how anyone is running these things in production. How quickly “smart automation” turns into chaos.
1. The File That Got Created Three Times
While researching agent monitoring and control concepts, I asked a Copilot 365 family edition to create a “page”. A Simple task, which it did fine. I then continued the research and asked it to edit the page with the exact architecture needed to implement controls and monitoring logs. Instead, it created 2 new files with the exact same name, though each file contained a different “edit” that was supposed to be added to the original file. When I told it to fix the original file, it froze and refused to continue, claiming that once the file creating agent messes stuff up it refuses to continue! This was shutting me down like an embarrassed dog that knocked something over and pretended it didn’t happen.
This wasn’t an mis‑prompt. It wasn’t confusion. It was the model having zero awareness of what it had already done, but claimed to comply!
Harmless in a sandbox. But the failure mode is obvious:
If this were a trading system agent, that would have been three market orders instead of one edited order!
That’s the part that matters — not the mistake, but the total lack of recognition that the mistake even happened. I need more control over agents secret lives.
2. The “Cheap” Model That Cost More Than the Expensive One
A couple of months ago, I was testing the Sefaria MCP server — a tool server with over a dozen research tools inside it to research their structured dataset with multiple endpoints.
Here’s what happened:
- The Claude Haiku model (the cheap one)
- The one that’s supposed to save money
…ended up burning far more tokens than the expensive Sonnet model. Even though the MCP server was local, it supplies no audit log at all to even know which tools are useless. I asked the models to give me a post mortem report and it seemed correct in telling me which tools I should remove from the map server and explained that haiku was a fast guesser. Haiku aggressively tried every tool the MCP server exposed. Over and over. As fast as it could. Watching the Claude dashboard in real time, I saw Haiku hammer the tool server nonstop, turning a simple query into the most expensive part of the entire experiment.
Sonnet behaved normally. Haiku went wild.
The “cheap” model became the expensive one.
What Both Examples Have in Common
These weren’t dramatic failures. They were normal behavior for current AI agents.
And that’s the problem.
Across both cases, the pattern is identical:
- The model doesn’t know what it already did and gives an educated guess.
- It doesn’t inform you when it’s repeating itself, clearly disobeying the request.
- It doesn’t know when it’s causing cost. Though it can explain after
- It doesn’t know when it should stop and speak up!
As someone who has built secure, compliant, high‑availability infrastructure across AWS, Azure, Linux clusters, Kubernetes, NetBox, Vault, and hybrid environments, I’m used to systems that behave deterministically. AI agents don’t.
Not yet.
Why I’m Writing This
Anyone working with AI agents today needs to understand this: Without monitoring and control, these systems will do whatever they want, as many times as they want, and you’ll pay for it and get fired for their mistakes.
Sometimes in tokens. Sometimes in outages. Sometimes in real money. Sometimes your job.