Skip to content

Comments

sub-agent delegation#71

Merged
dexhorthy merged 25 commits intohumanlayer:mainfrom
dexhorthy:dexter/eng-1116-delegation-to-sub-agents
Apr 25, 2025
Merged

sub-agent delegation#71
dexhorthy merged 25 commits intohumanlayer:mainfrom
dexhorthy:dexter/eng-1116-delegation-to-sub-agents

Conversation

@dexhorthy
Copy link
Contributor

@dexhorthy dexhorthy commented Apr 14, 2025

Important

Add sub-agent delegation functionality to allow agents to delegate tasks to sub-agents, with validation and testing.

  • Behavior:
    • Adds sub-agent delegation functionality, allowing agents to delegate tasks to sub-agents.
    • Updates AgentSpec in agent_types.go to include SubAgents and Description fields.
    • Implements sub-agent validation in validateSubAgents() in agent_controller.go.
    • Handles sub-agent delegation in processDelegateToAgent() in toolcall_controller.go.
  • Tests:
    • Adds tests for sub-agent delegation in agent_controller_test.go, collect_tools_test.go, and toolcall_controller_test.go.
    • Tests cover scenarios like sub-agent readiness, task delegation, and tool call processing.
  • Misc:
    • Updates README.md to include a section on delegating to a sub-agent.
    • Modifies kustomization.yaml to update the controller image tag.

This description was created by Ellipsis for e779a02. It will automatically update as commits are pushed.

dexhorthy and others added 3 commits April 13, 2025 11:08
Implement support for delegating tasks to sub-agents by enhancing the collectTools function to create delegate tools for each sub-agent referenced in an agent's spec. This feature allows parent agents to dispatch work to specialized sub-agents.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
@dexhorthy dexhorthy changed the title DRAFT - wip on sub-sagent delegation DRAFT - wip on sub-agent delegation Apr 14, 2025
@dexhorthy dexhorthy marked this pull request as ready for review April 15, 2025 21:03
}

// Check that the context about the user/channel is provided based on the channel type
// todo(dex) why does this happen at runtime in the agent controller and not when the contact channel is created?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah 🤔

Copy link
Contributor

@ellipsis-dev ellipsis-dev bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 Looks good to me! Reviewed everything up to e779a02 in 3 minutes and 43 seconds

More details
  • Looked at 1830 lines of code in 18 files
  • Skipped 0 files when reviewing.
  • Skipped posting 8 drafted comments based on config settings.
1. acp/test/utils/toolcall.go:33
  • Draft comment:
    Avoid hardcoding the 'acp.humanlayer.dev/toolcallrequest' label value ("test123"). Consider parameterizing it for better test flexibility.
  • Reason this comment was not posted:
    Comment was not on a location in the diff, so it can't be submitted as a review comment.
2. acp/test/utils/toolcall.go:31
  • Draft comment:
    Avoid using a hardcoded label value ('test123'); consider parameterizing it or adding a clarifying comment for test flexibility.
  • Reason this comment was not posted:
    Comment was not on a location in the diff, so it can't be submitted as a review comment.
3. README.md:523
  • Draft comment:
    Typo: In the 'Adding Tools with MCP' section, please remove the apostrophe in "Agent's aren't that interesting without tools" to read "Agents aren't that interesting without tools."
  • Reason this comment was not posted:
    Comment was not on a location in the diff, so it can't be submitted as a review comment.
4. README.md:953
  • Draft comment:
    Typo: Please capitalize 'next' to 'Next' at the beginning of the sentence "next, we can create a router agent that can delegate to the web search agent."
  • Reason this comment was not posted:
    Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50%
    While technically correct that sentences should start with capital letters, this is a very minor stylistic issue in documentation. The rules state not to make comments that are obvious or unimportant. Capitalization fixes fall into this category - they don't affect functionality and are trivial to spot.
    The comment is technically correct about proper English capitalization rules. The change would make the documentation slightly more professional looking.
    While correct, this type of minor stylistic fix is exactly what the rules say to avoid - it's an obvious and unimportant change that doesn't affect functionality or understanding.
    Delete this comment. It points out a trivial capitalization issue which falls under the "obvious and unimportant" category that we should not comment on.
5. README.md:1203
  • Draft comment:
    Typo: In the userMessage for the human-expert-task, there's a duplicate 'the' in "Ask an expert what the the fastest animal on the planet is." Please remove one instance to correct it.
  • Reason this comment was not posted:
    Comment was not on a location in the diff, so it can't be submitted as a review comment.
6. acp/api/v1alpha1/toolcall_types.go:38
  • Draft comment:
    The comment on the ToolType field (currently stating 'ToolType identifies the type of the tool (MCP, HumanContact)') is outdated, as it should now include 'DelegateToAgent' to be consistent with the updated file-level comment and constant definitions. Please update this comment to reflect all available tool types.
  • Reason this comment was not posted:
    Comment was not on a location in the diff, so it can't be submitted as a review comment.
7. acp/internal/controller/toolcall/toolcall_controller.go:1118
  • Draft comment:
    Typographical error: In the comment above, 'the current namends up like -' should be corrected to something like 'the current name ends up like -' for clarity.
  • Reason this comment was not posted:
    Comment did not seem useful. Confidence is useful = 30% <= threshold 50%
    This comment is pointing out a typographical error in a comment within the code. While it is not directly related to the functionality or logic of the code, correcting typographical errors can improve code readability and maintainability. However, it does not suggest a change in the code's behavior or logic, nor does it ask for tests or confirmation of intent. It is more of an informative comment about a non-functional aspect of the code.
8. acp/internal/controller/toolcall/toolcall_controller_test.go:52
  • Draft comment:
    Typo noticed in the test description: 'todo wth is an MCPTool...' might be better written as 'todo what is an MCPTool...'. Consider fixing this for clarity.
  • Reason this comment was not posted:
    Comment was not on a location in the diff, so it can't be submitted as a review comment.

Workflow ID: wflow_lKvO7yWjiE6IeOXK


You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.


BeforeEach(func() {
// Create a test LLM
llm := &acp.LLM{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What was the reason for not using TestLLM from utils?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh i tried to refactor this test to follow the patterns better, looks like it didn't pick up the "use utils" instructions.

anyhow fine to improve this more later

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

// Check for LLMRequestError with 4xx status code
// todo(dex) this .As() casting does not work - this error still retries forever
//
// langchain API call failed: API returned unexpected status code: 400: An assistant message with 'tool_calls' must be followed by tool messages responding to each 'tool_call_id'. The following tool_call_ids did not have response messages: call_N38DB1obDYZF0yDYxZhK6lTe
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I ran into this too, we gotta deal with this I think

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah added to backlog

}

// For delegate tools, extract the agent name from the format "delegate_to_agent__agentName"
parts := strings.Split(tc.Spec.ToolRef.Name, "__")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not gonna fight hard on it just yet, but it bothers me this is the way we're now doing this across all three types. We should consider just passing down an additional field.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i mean at a certain point, "function name" is a single parameter we expose to the LLM, so at some point we're gonna have to parse a single name back into a multi-field object.

we could contort the jsonschema we feed to the llm to make it call like "delegate" and inject a parameter "agent_name": ..., I guess

agree this could use a clean up - open to proposals.

@dexhorthy dexhorthy changed the title DRAFT - wip on sub-agent delegation sub-agent delegation Apr 16, 2025
@dexhorthy dexhorthy merged commit 69608e7 into humanlayer:main Apr 25, 2025
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants