Supporting multiple agents with a discoverable registry of agents.

[nareshnarayanan]

Cool project! I'm still getting used to the Langgraph concepts and came across a few ways to instantiate multiple agents. It would be great to be able to invoke a specific agent that's registered with the API server based on a name. An agent could work on a pre-existing thread that was already formed through multiple other agents' outputs.

A very powerful way to model these agents are to be able to expose any Agent as a directly invokable entity via the service APIs, but each agent also be able to communicate with each other and delegate work. The interface of communication * between * agents could either be structured or natural language but I think it would be very powerful to have a hierarchy of agents which may or may not be implemented using Langgraph. In addition, if each Agent's "interface" could be standardized, you could also look at discovery of agents from other remote endpoints and create a whole protocol specification for various agents to be discoverable, invocable and be able to coordinate with each other.

I have a few prototype implementations locally but wanted to kick off this discussion to see how this could scale out further with multiple agents. I'm not sure this is a direction this repository would want to go in, but I found the separation of a service API to be a useful abstraction for an agent, no matter how complex, with the nice ability of streaming the state of steps, token streaming etc. for a nice user experience on the UI.

[JoshuaC215]

Hi @nareshnarayanan , thanks for the kind words!

I am definitely interested in extending the repo to support multiple agents which can be called from the same running service. Maybe something like /invoke/<agent-name>. The idea of agent discovery is also interesting! If you want to work on this feel free to post a rough design or a prototype PR.

I think for this repo, I'm less interested for now in going too far with "agents calling other agents" being baked into the architecture but open to talk more about it. The idea of an agent being able to directly invoke another agent as a graph step makes sense, but I'm not sure I'm as interested in maintaining a whole protocol or interchange for less structured communication between agents.

[nareshnarayanan]

Agree - the agent communication protocol and hierarchical agent calls are a bit out there :) - I have some time over the next week and will look into sending a PR out for supporting registering and invoking multiple agents.

[antonioalegria]

I think /<agent-name>/<op> is cleaner and you could even eventually apply different processing for different agents with routers down the line (e.g. /research_agent/invoke)

[JoshuaC215]

I have a PR up for this: #75

[JoshuaC215]

Now merged ✅

A next step would be an agent discovery endpoint which lists the available agents and models running on the service

[antonioalegria]

On that topic, it seems that currently the agents are all setup up beforehand statically but would be good if they could be setup dynamically in runtime on the service's startup. Could be on the service's startup or with a configuration step, doesn't need to necessarily be adding and removing agents after the service is running.

[JoshuaC215]

That sounds interesting and maybe a modest change. Would welcome a PR if you have an idea or maybe a specific GitHub issue describing in more detail?