A clean connector does not make a reliable agent

This is a common trap with agents. A working tool call does not mean the agent knows when to stop or what success looks like.

Fair point on the varying arguments, and it breaks the stop condition I wrote. The counter has to key on the error rather than the call, and it has to live in the harness.

The distinction between connector-level testing and system-level testing is one I had to learn the hard way too. What pushed it home for me was watching an agent cycle through the same three tools forty times, each time getting the same error, and each time trying a slightly different argument instead of stopping. The connector was flawless. The agent had no budget, no circuit breaker, and no way to say I tried everything reasonable and I cannot do this.

The prompt-based approach you mention is the most seductive trap in the space. It feels like you are adding a control, but what you are really doing is adding a suggestion. The model can override it, forget it, or reinterpret it on the next turn. Code that says if tool_call_count > 10, stop and report is not elegant, but it is a control that survives model changes and prompt rewrites.

The test that separates the two is exactly right. Most teams are still running connector-green and calling it agent-ready. The trajectory-based evaluation is harder to build, but it is the only thing that tells you whether the system actually works.