Great point, I completely agree. The real challenge is not just making the agent “smarter,” but making its behavior bounded, observable, and recoverable in production. A structured flow with one well-placed AI reasoning step can often deliver more business value than a fully autonomous agent that has too much freedom and too little accountability. And yes, execution traces are critical. Once an automation becomes multi-step, teams need to see what happened at each stage: what context was used, what decision was made, which tool was called, what data came back, why a branch was selected, and where the workflow failed. Without that, debugging becomes guesswork. That’s exactly why I think the future of AI agents is less about “maximum autonomy” and more about controlled autonomy: clear workflow boundaries, deterministic steps where needed, AI reasoning where it adds value, and full traceability across the execution path.

This is exactly the right framing. I strongly agree with keeping the test side deterministic. Once the agent and the evaluator are both probabilistic, debugging becomes much harder because you no longer know whether the failure came from the workflow, the model, or the test judge. In Hexabot, we usually think about this in two layers: First, the action/tool contract should be tested as regular code. When developing a custom action, we expect the action schema, parameters, output shape, error handling, and edge cases to be covered with unit tests. That’s the first place where a tool signature change should be caught before it affects workflows: https://docs.hexabot.ai/developer-guide/develop-custom-actions/testing-custom-actions Second, workflow tests should be tied to workflow versions. Hexabot separates drafts from published versions, so the version that runs in production is not just “whatever is currently being edited.” This makes it possible to reason about tests against a specific workflow artifact/version: https://docs.hexabot.ai/workflow-editor/versions-drafts-and-publishing For workflow-level testing, the current approach is to export the workflow and generate a test file from it. I would treat those generated tests as version-coupled fixtures: if the workflow changes, or if an action contract changes, the test should either fail clearly or be intentionally regenerated/reviewed. I would not want signature drift to be discovered only after deploy through integration tests. So practically: action unit tests catch tool-level contract drift, exported workflow tests catch workflow-level behavior drift, and published workflow versions give us a stable reference point for what is actually running.