Enable Agent-to-Agent Delegation via Tool Calls for Composable AI Behavior

[JonasHelming]

PO @planger

Description

This feature enables AI agents to delegate tasks to other agents through tool calls. By introducing delegation as a first-class tool mechanism, we can allow agents like @Coder to trigger specialized behavior by routing a task to another agent (e.g., @AppTester), leveraging its domain-specific tools and capabilities.

Delegation allows for scalable and modular agent behavior: a general-purpose agent can act as an orchestrator while offloading subtasks to agents with narrower but deeper functionality. The main agent can frame the request, summarize relevant context, and process the delegate’s response in a controlled way. This enhances both flexibility and clarity in complex multi-step tasks.

Example Use Cases

Use Case: Delegating a UI Behavior Test to Another Agent

Feature: Delegating a test to a specialized agent
  As a developer
  I want the @Coder agent to delegate a UI behavior test to the @AppTester agent
  So that I can validate the running application behavior as part of my development workflow

  Scenario: Using @Coder to delegate a UI check
    Given I am in a chat with the @Coder agent
    And I write "@Coder Please check that after clicking the 'Reset' button, the Token Usage goes to 0."
    When the @Coder agent processes the request
    Then it should create a tool call using the `delegateToAgent` function
      | agent name    | request                                                                 |
      | @AppTester    | Connect to localhost:8000 and check that clicking 'Reset' in Token Usage sets the value to 0 |
      
    When the delegated @AppTester agent performs the task
    Then its response should be streamed back and rendered inside the @Coder chat
    And I should see that the response was delegated from another agent
    And I should be able to continue the conversation with @Coder

Hints and Suggested Architecture

The implementation should follow a modular and extensible design, using the existing tool call infrastructure:

• Tool Function: Introduce delegateToAgent(agentName: string, requestText: string) as a core tool function. The function:

  • Instantiates a DelegatedChatSession for the delegate agent for this particular delegation request, but linked to the main chat session for traceability.
  • Submits the requestText to the agent
  • Streams back the result to the calling agent as a tool call response

• Delegated Response Rendering: Implement DelegatedResponseRenderer, a specialized response renderer for delegateToAgent calls. It shows the delegate agent’s response inline, fully rendered with the existing rendering mechanism, but visually differentiated to indicate it is a delegation from the main agent to the delegate agent. It should show the request of the initiating agent and the nicely and extensibly rendered response of the delegate agent.

• Change Set Behavior: Change sets require special handling. The delegate agents using may contribute to the change set, so we need to ensure that we install a DelegatedChangeSet in the request, which is instantiated from the original change set and delegates additions or changes to the change set to the parent change set.

• Configuration and Workflow: The system prompt of the main agent (e.g., @Coder) defines which agents are available for delegation and how to use them (e.g. which workflow to follow).

• Open Question: Tool call results are currently not part of the ongoing context of the chat. Should delegateToAgent responses become part of the main conversation history by default? This could allow referencing and follow-up.

Related Issues and Dependencies

• Depends on:

  • AppTester Agent via Browser Automation #196

Related Links

• Tool Call Infrastructure
• Tool Call Renderer

[planger]

Yeah, I agree, but I'd like to use the opportunity to explore those approaches a bit more, while strengthening the platform to support most of the approaches to a certain degree. I don't think that introducing the infra for that is so difficult.

I've sketched the structure in #197 (comment).
This would split creating the tools and the infrastructure, from combining them into different variants of Coders, to see what works best. Essentially the different variants of Coder would just be system prompt template variants.

It would include 1, 2 (manual and automatic) in a and b above.

[JonasHelming]

Sounds very good!

[CamilleLetavernier]

Draft PR: eclipse-theia#15736