Working With Agentic AI (Part 2): What Broke First — and Why That Matters

Last week, our team shipped the first version of an agentic, multi-tool AI system to about a dozen testers. The big question wasn’t “did it work?”—it was: what broke first?

Why look for breaks?

Releasing a complex AI, especially one that interacts with multiple tools via APIs, is less about chasing “completion” and more about discovering reality. In complex, probabilistic systems, the weaknesses don’t always show up where you expect. The “failure map” is the real spec. Think of this as “failure-oriented engineering.”

What failed (and how)?

• The AI got stuck in a loop when a tool returned a rare error code it hadn’t seen before.
• A chain of tool calls produced subtle hallucinations (“phantom success” responses).
• Unusual but valid user requests led to path explosions—lots of partial work, nothing finished.
• APIs updated upstream (API drift) without warning, breaking agent plans mid-flight.

Why does this *matter*?

Because the way an agent breaks tells you more about AI capability than its success cases do.

• Failure modes define boundaries: You see the real shape of your system—what’s robust, what’s wishful thinking.
• Testing to break, fast: Instead of iterating for perfection, iterate for insight faster.
• Stronger product intuition: You learn more in 48 bug-ridden hours than 2 weeks of “quiet” QA.

Takeaways for teams:

• Schedule “destructive testing” sprints, especially after adding new tools/abilities.
• Map not just happy paths, but all the weird detours your agents might take.
• Assume “API drift” and prepare fallback procedures for upstream changes you can’t control.

Release early, watch for cracks, and learn deeply from what breaks first.

📖 Read on LinkedIn

Visit fig-io.com for more insights