Using Agentic: Should We Use One Agent Class with Many Tools, or Split into Multiple Agents?

[samushi]

With Agentic, is it enough to create a single Agent class and then define many tools within that agent? Or is it better to separate concerns into multiple agents for example, a SeoAgent, an OrderAgent, and a ProductAgent?

If we go with the multi-agent approach, how would we implement it in a way that still understands and responds correctly to a client’s question that might touch multiple domains?

[ilvalerione]

Hi @samushi, very interesting question.

I'm quite sure about the need to separate your agents based on the macro tasks they are delegated to do. The more tools you attach to the agents, the higher the chance it makes a mistake. This probability increase even more when your tools refer to completely different domains.

I see more specialized agents the way to go.

The basic strategy to connect multiple agents one another is always based on tools. Just as an inspiration you could take a look at this article that shows an example of how a multi-agent cooperation can be organized: https://valentinaalto.medium.com/modularity-and-abstraction-in-multi-agent-applications-c566a510f142

At the current stage of Neuron, you can basically have a top level agent with other specialized agents attached as tools.

class SupervisorAgent 
{
    public function provider(): AIProviderInterface
    {
        ...
    }

    public function tools(): array
    {
        return [
            Tool::make(
                'get_product recommendation',
                'Get products recommendation based on user preferences.'
            )->addProperty(
                new ToolProperty(
                    name: 'preferences',
                    type: 'string',
                    description: 'A description of what user loves.',
                    required: true
                );
            )->setCallable(function (string $preferences) {
                $response = ProductAgent::make()->chat(new UserMessage($preferences));
                return $response->getContent();
            }),
            
            Tool::make(
                'order_agent',
                'Manage orders.'
            )->addProperty(
                new ToolProperty(
                    name: 'product',
                    type: 'integer',
                    description: 'The ID of the product to order.',
                    required: true
                );
            )->setCallable(function (string $product) {
                $response = OrderAgent::make()->chat(new UserMessage("I want to order the product with ID: {$product}"));
                return $response->getContent();
            }),
        ];
    }
}

Ask directly to the supervisor:

$response = SupervisorAgent::make()->chat(new UserMessage('I love skiing, but I'm a beginner. What skis do you recommend?'));
echo $response->getContent();

$response = SupervisorAgent::make()->chat(new UserMessage('I would like to by the blue one.'));
echo $response->getContent();

Don't take this example too literally. It needs highly curated prompts and system instructions. It can give you just an idea.

Always consider that LLM based interactions is a relatively new product experience. There are not well known patterns to follow. We have to experiment to innovate.

Facilitate the orchestration of multiple agents is in our roadmap but nothing implemented for now. If you have any resource, or if you want to share here the result of your next experiments is really appreciated.

[marcelfolaron]

Has anyone explored that further with streaming responses? I have the general orchestration logic but if I want to use a tool for cross agent delegation I have to use chat and can't stream the response.

It makes sense since the recursion in the stream call tries to build the ToolResult Message Object. Can't wrap my head around how to do the hand off during an existing stream.

[marcelfolaron]

Just to check in. I think I may have a solution but would love to get some feedback.

I think the main problem with tool hand off is that the original agent is waiting for the tool result before continuing as part of the recursion. Instead, what I think should happen is that it takes the signal of an agent change and then streams the content from the new agent.

So what I have right now is this:

• I created a new baseAgent that overrides stream()
• I created a tool that allows delegation to new agents. It only returns a simple json string with: {"action": "delegateToAgent", "name": "NewAgentName"}
• I have a agentBuilder and registry that can instantiate agents based on name
• The new current agent is stored in cache so my next prompt will automatically go to the newly selected agent
• The tool response recursion checks for a new agent and then streams from there

BaseAgent Class (currently extending vendor Agent and overriding stream

$stream = $this->resolveProvider()
            ->systemPrompt($this->instructions())
            ->setTools($this->tools())
            ->stream(
                $this->resolveChatHistory()->getMessages(),
                function (ToolCallMessage $toolCallMessage) {

                    $toolCallResult = $this->executeTools($toolCallMessage);

                    //Parse results for agent swap result
                    $result = $toolCallResult->getTools()[0]->getResult();
                    if (is_string($result)
                        && ($toolResult = json_decode($result, true))
                        && isset($toolResult["action"])
                        && $toolResult["action"] === "delegateToAgent") {

                        $agentRegistry = app()->make(AgentRegistry::class);
                        $agent = $agentRegistry->getAgentByName($toolResult['name'], $this->userContext);

                        yield "\n\nConnecting to new agent...\n\n";
                        //Conversation is now streamed by new agent.
                        yield from $agent->stream([$toolCallMessage, $toolCallResult]);
                    }

                    //If it's a regular tool or if the new agent is done, continue with the old agent
                    // Process normally
                    yield from $this->stream([$this->resolveChatHistory()->getMessages(), $toolCallMessage, $toolCallResult]);
                }
            );

It's still not really a hand off as much as it is a wrapper. I'm wondering if the execution of the old agent should stop somewhere else but have not done this. Any feedback on this approach?

It would be nice to have a more deliberate signal that an agent hand off is happening. Maybe ToolCallResultMessage could be AgentSwap or something similar. Again this is just proof of concept and still trying to validate it does what I think it does :D

[ilvalerione]

I believe the multi agents orchestrator should be a dedicated layer. Even released as a separate package that accept AgentInterface as contract to register the agents involved in the process. This could be a solid community project.

[marcelfolaron]

I'll give it a try and send a PR your way.