https://docs.all-hands.dev/ logo
Join Slack
Powered by
Would you want to build a workflow like this in Ag...
# proj-agent-canvas
a
Would you want to build a workflow like this in Agent Canvas? Audit this codebase for bugs and missing tests. GPT-5.6 plans and use DeepSeek V4 Pro for the fixes You can already do this today with the API and SDK. But what would it take to make this easily promptable in the Agent Canvas UI?
To start with you can use: LLM Profiles for each model (GPT-5.6, DeepSeek V4 Pro) Enable Subagents in settings (enable_subagents: true, tools: null) — this adds the task tool to every conversation
To get this to work, I also needed to create subagent definition .md files Each one is YAML frontmatter + a system prompt:
Copy code
---
name: ds-coder
model: deepseek-v4-pro
tools: [terminal, file_editor]
---
You are a fast coding subagent. Make exactly the change requested.
l
Did you try adding that prompt?
I think it should just work
a
Type your prompt normally — e.g.: > "Audit this codebase for bugs and missing tests. Decompose into > subtasks and delegate to ds-researcher and ds-coder. Synthesize > and propose fixes."
l
(You will need both LLM profiles enabled)
Also, you don’t need subagents, it can just switch mid-conversation.
a
Yea, I am trying to replicate the workflows of a smart planner and then subagents that go do the work. Where I can easily prompt it and not have to manually switch and manage the orchestration. But I also want this all from a prompt.
l
Did you send exactly the prompt you wrote above and it didn’t work?
Audit this codebase for bugs and missing tests. GPT-5.6 plans and use DeepSeek V4 Pro for the fixes
In that case what didn’t work?
I think the only thing you should need to do is make sure that you have the two language model profiles set beforehand, but it might not work 100%.
a
If you prompt Agent Canvas with two different models, the main agent may switch to the second model rather than delegate work to it. For real delegation—where GPT-5.6 remains the parent, DeepSeek V4 Pro runs as a separate worker, and GPT-5.6 synthesizes its results—you must first define DeepSeek as a named subagent. Today, that means adding a subagent definition to 
.openhands/agents/
. You can then prompt:
Remain on GPT-5.6. Delegate the fixes to 
ds-coder
using the task tool. Do not switch the parent model. Synthesize the subagent’s result.
The built-in subagents support real delegation, but they inherit the parent’s model. A custom definition is currently required when the parent and subagent need to use different models.
l
I agree, but did the agent fail at the task you gave to it? Or was it too slow?
I'm just wondering what the problem is before jumping to the solution
a
This is really for the use cases when you have a large job that you can run across many subagents. I agree the normal switching works for many regular tasks. But what happens when you have a big job that can be breaken down into smaller chunks. In that case you want the planning and many workers. Its also a larger trend for attacking problems to balance smarts with cost.
l
That makes sense but the prompt that you sent above didn't seem like one that would really benefit from having lots of sub agents? Anyway I agree we can make this more intuitive. Right now my most effective way to do this is to ask it to use the agent canvas environment skill to create a new conversation for each new task and then check on the conversations when they finish
s
The agent used the switch_llm tool when you wanted sub-agents instead, right? I think I'm following
✅ 1
Yeah, I see it. Part of the problem is maybe the sequential nature of the work. GPT-5.6 makes the plan and that's over before DS-V4 needs to start coding. Logically, switching makes some sense if you're just trying to infer the strategy.
a
I am flexible on the how -- I just want an easy way to do this pattern of main agent kicking off many subagents in a very easy way, where a user just has to give a simple prompt.
s
well, the default configs are switch_llm is on and enable_sub_agents is off. right?
if i didn't accidentally cause that somehow
a
Yes, that is the default, you have to manually (for now) enable subagents
l
For now I think the easiest thing is to say “delegate to a local conversation” using the agent canvas environment skill: github.com/OpenHands/extensions/…/agent-canvas-environment
But we should make that easier
One piece of context is that a lot of people, including previous versions of me, greatly overestimate the benefit of having lots of parallel subagents working on things. We have a paper here on it with some positive results, but to be perfectly honest we had to work really hard to make this work and it’s somewhat dependent on the behavior of previous models quitting too early: arxiv.org/abs/2603.21489 We weren’t able to get that many speed gains, and the cost was higher by using multiple subagents. It’s just really hard to get task decomposition and context passing right, so unless it’s something that’s super-parallelizable (e.g. working on different, independent repos), you’re often much better off not using sub-agents
s
this is fantastic!
i mean, you might be a little crazy. i can't get one agent to do anything without hand-holding that definitely prevents taking hands off the wheel. far as being a human-in-the-loop goes, i'm a nosy and opinionated one. when the robots take over, i will not be spared.
😂 2
c
👀 That’s a useful skill! Sometimes I think the way to make it easier, for a type of task like this, when we want the user to insert a “standard” prompt, is a template like an Automation, just not scheduled… if that makes sense. Like, reuse an interface like the Automation interface, with a part of the prompt pre-filled 🤔
s
I wanted to try this because it solves a problem that I have. Agents tend to spawn subagents of kind. And that choice happens someplace you can't reach with guardrails in the file system. Kimi Code prefers to spawn Kimi subagents and I can't inject a trigger in their closed solution. The options are "deal with it". What I want is K3 or Qwen or Opus or whatever model I'm using as boss to always write plans and then delegate the coding of those plans to M3. Once M3 has written the code, GLM-5.3 performs adversarial audit. Those results are reviewed by the boss. The boss can go N rounds thru the process before surfacing. This is what my personal tooling tries to enforce and it's hard. In their native harnesses, the agents don't want to do it. So, I tried building this as MVP/prototype that would allow for better enforcement. If this strategy is good then I'd suggest a follow-up PR that would display the subagent. Workers are sequential unless you increase 'tool_concurrency_limit'. This would also create a universe in which someone definitely wants a default subagent setting. Would be grateful if somebody would give opinions on the approach. 🙏 github.com/OpenHands/software-agent-sdk/pull/4510
l
cc @modern-fireman-99755
m
Hey @straight-dog-12443 I was looking at your solution. However, I don't think it is the best way to solve the problem. As you saw, there are a couple of things that you have to patch to make it happens (I didn't test it so I don't know if it works). If you want to have sub-agents that are cheap or using a very specific llm profiles, I will say to use the file based sub-agents. I started a while ago to implement that but then we had other priorities. However, the rest API in agent-server is already in place. So what is really missing is the UI. I have a draft PR for that: github.com/OpenHands/OpenHands/pull/16662 If you want to give a look.
🙏 1
3 Views
Open in Slack
PreviousNext
Powered by