[Agent] Revisit Agent Component Interface

[chr-hertel]

This is something that is keeping my head busy for a while now, and I'd like to get some feedback/input.

Motivation

• Platform and Agent interface are quite similar despite having quite different purpose
• Agents are well more defined from a functional point of view than the current interface offers
  • Tools are only second level citizen, which is not great - ofc they are optional, but that extra way to register them feels odd
  • Every agent should have a name and instruction - having it optional or also with that SystemPromptProcessor is extra effort
  • i'm considering the component, not the bundle integration which basically fixes parts of it with hiding the extra work
• promote MultiAgent capability into the main agent

Goal

$agent = new Agent(
    name: 'research',
    instruction: '...',
    tools: [...], // which could include local tools, remote tools, and subagents
    handoffs: [...], // routing like with MultiAgent
);

On top it would be great to design for progress updates, human interactions, or parallel executions.

a) Similar to Process component:

$execution = $agent->run($input, $options);

echo $execution->getOutput();

$execution = $agent->start($input, $options);

foreach ($execution as $type => $update) {
    if (Agent::INTERACT === $type) {
         // on hold until main runtime provides feedback => $feedback
         $agent->continue($feedback, $options);
    }

    if (Agent::PROGRESS === $type) {
         echo $update; // "Search for xyz on the web."
    }
}

b) More promise style

$agent->run($input, $options)
    ->onInteraction(...)
    ->onProgress(...)
    ->onResult(...);

for both we could wrap it into an runner service, that takes care for putting an agent to rest, wakes it up, maybe handles async, and integrates with the event dispatcher - similar to features we see in Chat right now, including forking/branching/rewind?

just sharing thoughts, no point of action right away

[aszenz]

I would like to add examples to each agent, so one could clearly see what prompts it can handle, in addition to name and description. This could be useful for multi/sub agent scenarios too.

[chr-hertel]

I would like to add examples to each agent, so one could clearly see what prompts it can handle, in addition to name and description. This could be useful for multi/sub agent scenarios too.

you mean in examples/ folder and docs then or when refining here?

[aszenz]

I would like to add examples to each agent, so one could clearly see what prompts it can handle, in addition to name and description. This could be useful for multi/sub agent scenarios too.

you mean in examples/ folder and docs then or when refining here?

No i meant when creating the agent, it can have a name + description while also having example prompts for the agent.
These example prompts can then be used in multi-agent to help it understand what kind of questions are relevant for the agent.
These example prompts can also be used when running the agent via cli, as hints

Context:

I'm building a ui for the agents, and it shows the user what each agent can do by example prompts, right now I have to decorate each agent to add that information.

[chr-hertel]

Okay @aszenz, interesting, let's talk code, how would you bring that into the interface? :)

[OskarStark]

For me this is domain logic. You should be able to get the instructions from the agent. So you can add the examples at the end of your instructions and extract them. Another option is to add generic metadata to the agent interface