refactor: unify subagent and subrecipe tools into single tool

[tlongwell-block]

Unifies the subagent tool interface by consolidating three separate tools into one:

• dynamic_task__create_task (ad-hoc tasks)
• subrecipe__create_task_* (predefined recipes)
• subagent__execute_task (execution)

The new subagent tool supports three modes:

1. Ad-hoc: subagent(instructions: "...")
2. Predefined: subagent(subrecipe: "name")
3. Augmented: subagent(subrecipe: "name", instructions: "additional context")

Removes ~2500 lines of code. Updates CI tests and goose-self-test.yaml.

The new augmented mode allows for built in subagent personalities via subrecipes without additional machinery or plumbing. This is a standard feature on other agent platforms. These should be added in a subsequent PR as built in subrecipes much the same way we bundle the system prompts.

[lifeizhou-ap]

Looks good by consolidating the existing tools into one tool!

I noticed that with this PR change we cannot control sequential or parallel execution when the same subrecipe runs multiple times with different parameters inside the parent recipe because sequential_when_repeated is no longer used.

For example, a parent recipe: “use the weather subrecipe to get the weather for Melbourne, Sydney, and Brisbane,” so we call the weather subrecipe three times for each city. Before this PR we can set sequential_when_repeated on subrecipe to run them in sequential if the subrecipe accesses shared resources.

Is there way that we can maintain this behaviour?

[tlongwell-block]

Looks good by consolidating the existing tools into one tool!

I noticed that with this PR change we cannot control sequential or parallel execution when the same subrecipe runs multiple times with different parameters inside the parent recipe because sequential_when_repeated is no longer used.

For example, a parent recipe: “use the weather subrecipe to get the weather for Melbourne, Sydney, and Brisbane,” so we call the weather subrecipe three times for each city. Before this PR we can set sequential_when_repeated on subrecipe to run them in sequential if the subrecipe accesses shared resources.

Is there way that we can maintain this behaviour?

I'm don't think I understand.

When a recipe is run, there can be multiple subrecipes specified in it. Previously, these were turned into tools that the agent would call at its discretion.

That is also what happens now, just as a parameter instead of a custom tool.

Is there supposed to be a way where the subrecipes execute without being called by the agent? I don't understand what sequential_when_repeated actually does.

Right now, if the agent is told to run subrecipes sequentially, it will just make separate sequential calls to the subagent tool.

[lifeizhou-ap]

Looks good by consolidating the existing tools into one tool! I noticed that with this PR change we cannot control sequential or parallel execution when the same subrecipe runs multiple times with different parameters inside the parent recipe because sequential_when_repeated is no longer used. For example, a parent recipe: “use the weather subrecipe to get the weather for Melbourne, Sydney, and Brisbane,” so we call the weather subrecipe three times for each city. Before this PR we can set sequential_when_repeated on subrecipe to run them in sequential if the subrecipe accesses shared resources. Is there way that we can maintain this behaviour?

I'm don't think I understand.

When a recipe is run, there can be multiple subrecipes specified in it. Previously, these were turned into tools that the agent would call at its discretion.

That is also what happens now, just as a parameter instead of a custom tool.

Is there supposed to be a way where the subrecipes execute without being called by the agent? I don't understand what sequential_when_repeated actually does.

Right now, if the agent is told to run subrecipes sequentially, it will just make separate sequential calls to the subagent tool.

Hi @tlongwell-block

# multi_city_weather.yaml
version: 1.0.0
title: Multi-City Weather Comparison
description: Compare weather across multiple cities for trip planning
instructions: You are a travel weather specialist helping users compare conditions across cities.
prompt: |
  get the weather forecast for the three biggest cities in Australia 
  to help me decide where to visit
sub_recipes:
- name: weather
  path: "./subrecipes/weather.yaml"
  sequential_when_repeated: true
extensions:
- type: builtin
  name: developer
  timeout: 300
  bundled: true

This is the example. By default, it will run ./subrecipes/weather.yaml with params of Sydney, Melbourne, and Brisbane. This creates 3 tasks and runs in sequential.

Without sequential_when_repeated, these 3 tasks will run in parallel by default. The sequential_when_repeated gives user flexibility if the sub recipe access to some shared resources and avoid issues from concurrent access.

[tlongwell-block]

Thanks, @lifeizhou-ap! I think I see.

So, before, the subagent/subrecipe tools were special in that a single tool call in a single message could launch many parallel subagents.

Now it's just a regular tool call like any other, which can be done in parallel through the standard tool call mechanism.

With this move to the standard mechanism, there isn't a way to enforce sequential_when_repeated without bigger changes to 'multiple tool calls in a single message' handling.

But, I have put in a dynamic hint to the LLM when a subrecipe has sequential_when_repeated set that it should not be run in parallel. I think this will cover it. Testing shows it works as intended

[alexhancock]

Would love to see the conflicts resolved here and merged