Align Dynamic Task Interface with Recipe Interface

[tlongwell-block]

Summary

This PR unifies the dynamic task and subrecipe systems by treating dynamic tasks as inline recipes, enabling agents to leverage the full power of the recipe infrastructure without requiring recipe files.

Key Changes

1. Unified Task Format

Dynamic tasks now accept all recipe fields (instructions, prompt, extensions, settings, retry, response schema, etc.), providing agents with ad-hoc access to recipe capabilities previously only available through recipe files.

2. Extension Control

Agents can now precisely control subagent extensions:

• Omit field: Use all current extensions (backward compatible)
• Empty array []: No extensions (sandboxed execution)
• Array with names: Only specified extensions

This addresses a critical bug where subagents always loaded all enabled extensions regardless of task specification.

3. Output Control

Added return_last_only flag allowing agents to receive only the final message from subagents instead of the full conversation, reducing token usage and improving efficiency when intermediate steps aren't needed.

Benefits

Performance

• Reduced token consumption in calling agent with selective output
• Lower overhead by loading only required extensions
• Efficient subagent execution with precise resource control

Safety

• Sandboxed execution with no extensions when needed
• Explicit extension control prevents unintended capabilities
• Security validation inherited from recipe infrastructure

Power

• Full recipe features available without file creation
• Model/provider settings per task

Implementation Details

The implementation leverages existing recipe validation and building infrastructure, requiring minimal new code (~300 lines). Dynamic tasks are converted to inline recipes internally, maintaining backward compatibility while providing forward-looking capabilities.

Technical Approach

• Extended TaskConfig to include extensions field
• Modified SubAgent::new() to respect specified extensions
• Enhanced dynamic task tool to accept all recipe fields
• Reused existing recipe validation and security checks

Testing

• Exhaustive tests covering all new functionality
• Backward compatibility verified
• Extension control edge cases tested
• Output control functionality validated

Breaking Changes

None. All existing dynamic task usage continues to work unchanged.

Migration Path

Existing code requires no changes. New features are opt-in through additional fields in the dynamic task parameters.

[DOsinga]

Sorry, didn't really get through this or really to the meat of the thing, looks promising so far, questions so far mostly about whether we are having premature backwards compatibility stuff

[tlongwell-block]

Sorry, didn't really get through this or really to the meat of the thing, looks promising so far, questions so far mostly about whether we are having premature backwards compatibility stuff

I've now removed all the backwards compatibility branches around text instructions

[yingjiehe-xyz]

overall it looks good, would like to see how others feel

[michaelneale]

@tlongwell-block I'm not seeing this make use of subagents at all - is that expected? DOesn't seem to break anything but I dont' really follow this change, seems fine otherwise, but not sure what expectation is (is there another change to get it to plan better to make use of subagents more efficiently?)

but have been using it today, and seems A-ok, FWIW

[michaelneale]

almost there - but I think the system prompt has to be adjusted for sub-agents to be more effective.

[michaelneale]

nice!

[michaelneale]

have tried this out, benches well apparently, and addresses a bunch of things I wanted to fix with a subagent hardening PR, a good improvement.

[michaelneale]

also for subagents to be useful at all - need this so it doesn't flood the session.

[r0x0d]

Looks like this addition broke the integration with providers using llama.cpp: #4815

I'm not 100% familiar with the codebase yet, but I'm trying to propose a fix in the upcoming days. I have tracked it down to this line of code.

I'm testing this with ramalama + llama3.2 (with llama.cpp).

[r0x0d]

cc: @iandouglas

[michaelneale]

@r0x0d is that lamma.cpp with rust or out of process? (have a branch playing with former as it is easier to ensure it works, but less powerful).

[r0x0d]

So, I'm suing ramalama for that, and playing out with goose from main brranch (latest commit).

I've seen that with ollama it works fine, the problem seems to be with llama.cpp

[tlongwell-block]

#4897