It's like anything - The devil is in the implementation details. I've found the most leverage with agent-based LLM solutions comes from including feedback from

It's like anything - The devil is in the implementation details. I've found the most leverage with agent-based LLM solutions comes from including feedback from prior iterations. For example, if you are trying to write a text-to-SQL bot you should actually attempt to parse any generated query using the desired provider and then pass any errors back into the prompt. You can also incorporate snippets of result sets (if successful parse) as another form of feedback. In my experience, this can make an incredible difference in performance. It's a LOT cheaper to just run the generated query against an actual SQL database (and try again as needed) than to get the whole thing right in one shot with fine tuning & RAG. I do think the right approach is to empathize with the agent. How far could you get with that complex 12-table query if you did not have a way to run your SQL against the actual database and see how it performs? You can extend this thinking to any domain. You can write your own "guard rails provider" that is deterministic and easy to inspect (i.e. you can set breakpoints and view locals). This can even recursively utilize the LLM in a more targeted way.