[nico]

Nice. How would you go about providing a dynamic list of delgates? Could it work to just give one delegate that can provide a list of delegates with a description of the actions they can perform (then that delegate can query a db and return a list)?

Re-reading, I’m guessing the prompt could also be dynamically generated to include the most relevant delegates.

[sprobertson]

> the prompt could also be dynamically generated to include the most relevant delegates

Yup that's how I'm doing it - the system prompt is re-generated for every request, and that includes getting a list of available delegates and the arguments they accept. I only have 10 so I'm just listing all of them, but if you had some huge number you could combine that with embeddings / vector lookup.

[behnamoh]

At that point we're basically back to the `AI is just nested if-else expressions` story. The only difference is that now there is a language reader on top that understands the semantic of your language. But actors (or agents in LangChain lingo) are just if-else. The tools you connect them to must be developed separately.

[nico]

Sure, you could also say that human language/action capacity is just a biological LLM with some ifs on top that give it access to actions.

In the case you describe, you can have an LLM write the tools.

Yes, the first tools and bridge code might need to be manually built. But after that it could be LLMs all the way down.

Kind of similar to writing a new programming language. At first you write it in another language but after compiling it for the first time, you can then write the language in the language itself.

[enricoros]

Very good point. Once you start breaking down a llm into presets/delegators, you introduce basically if-else, with all the problems of that split. Lack of visibility, local vs global optimization, lack of control and predictability, asymmetry of information. I wonder if the current Agents approach is a stopgap solution.