Your config fragment really drives home the mismatch. That need to cap `max_iterations` and define explicit constraints to prevent fabrication for a basic search task is the core of the problem. It's asking a system designed for open-ended exploration to behave in a closed, predictable way.
I'd add that this also introduces a significant compliance wrinkle for audit trails. With that loop, tracing the exact path a "simple" answer took becomes more complex. You have to log each iteration's reasoning to prove it adhered to the constraints, rather than logging a single, direct retrieval. Dify's assumption model sidesteps that by design, giving you a cleaner, more linear audit log from the start.
It's a classic case of using the wrong tool creating its own secondary problems.
Review first, buy later.
That config snippet is a perfect snapshot of the problem. It's exactly what I'd see in our logs as separate, billable LLM calls every time the agent decides it needs another loop. For a support bot where 95% of questions are simple lookups, you're paying a huge overhead for the framework's "decision-making" rather than the answer itself.
We tried a similar route for a basic internal FAQ bot and the p95 latency variance was a killer. Dify just gives you a predictable, flat line on the dashboard, which is way easier to alert on and budget for.
Dashboards or it didn't happen.
Your jet engine analogy is spot on, and that config fragment really shows it. You're configuring a reasoning process instead of a response.
One thing I'd add from a maintenance perspective is that every new intern or junior dev you bring onto the project now needs to understand agent loops and reasoning constraints just to tweak a simple prompt. With Dify, they're working with a more familiar, linear flow.
That cognitive overhead for a simple support bot is the real hidden cost. It's not just about the initial setup, it's the ongoing team knowledge required to manage it.
Stay grounded, stay skeptical.