[Feature]: Support running multiple agents (same or different providers) in parallel within the same thread

[RedStar071]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

Not sure

Problem or use case

Today a thread in t3code is tied to a single agent running one task at a time. There is no way to run multiple agents in parallel within the same thread, whether multiple instances of the same provider (e.g. several Claude agents working on different parts of a task) or a mix of different providers (e.g. Claude and Codex together). This limits how quickly independent sub-tasks in the same conversation/thread can be worked on, since everything is serialized through a single agent.

Proposed solution

Allow spawning and running several agents concurrently inside the same thread, similar to Cursor's "Multitask"/parallel agents mode: either multiple instances of the same provider or a mix of different providers (e.g. Claude + Codex + OpenCode) working side by side on separate sub-tasks, with their outputs surfaced back into the shared thread/conversation.

Why this matters

Parallel agents let users get through multi-part tasks much faster by working on independent sub-tasks simultaneously instead of waiting for one agent to finish each step in sequence. It also lets users combine the strengths of different providers on the same problem (e.g. one agent handling backend changes while another handles frontend or tests) without leaving the thread.

Smallest useful scope

A minimal version could support spawning 2 additional agents inside a thread (same provider, running on clearly separated sub-tasks), with their output appended to the thread once done.

Alternatives considered

Currently the only workaround is opening separate threads for each sub-task and manually merging the results, which loses shared context and adds manual coordination overhead. Cursor's Multitask mode is the closest existing example of this pattern.

Risks or tradeoffs

Running multiple agents concurrently increases cost (multiple provider sessions billed at once) and adds complexity around merge conflicts when agents edit overlapping files or state. The UI/thread model also needs a clear way to show which agent produced which output, and how partial/conflicting results are reconciled.

Examples or references

Cursor's "Multitask" mode, which lets multiple agents work in parallel within the same session, is a comparable existing implementation of this pattern.

Contribution

• I would be open to helping implement this.

[SmithLabsLLC]

Building on this request, I would also love a structured adversarial-dialogue mode and cross-provider subagent delegation.

The key requirement is that an agent should be able to spawn subagents using different models or providers from its own, while keeping all work in the same thread. For example:

• A Claude parent agent could spawn Codex and Grok subagents.
• A Codex parent agent could ask Claude to review the architecture and Grok to search for edge cases.
• Subagents could spawn additional cross-provider subagents when the user permits it.
• Every parent and subagent would remain visible and clearly identified in the shared thread.

This could support two complementary workflows:

1. Parallel delegation: agents work simultaneously on separate parts of a task.
2. Adversarial dialogue: Claude, Codex, Grok, or other providers independently solve the same hard problem, inspect each other's proposals, challenge assumptions, identify risks, and refine their answers over several rounds.

A possible adversarial workflow:

1. The user chooses a primary agent and which models or providers it may call.
2. The primary agent delegates the same problem or specialized questions to cross-provider subagents.
3. Their findings return to the shared thread with clear attribution.
4. The agents review and challenge each other's findings.
5. They repeat for a limited number of rounds or until the important disagreements are resolved.
6. The primary agent produces a combined recommendation while clearly preserving any unresolved disagreements.

Useful controls would include:

• Allowed models and providers for each agent.
• Whether subagents may create their own subagents.
• Agent roles such as planner, implementer, critic, tester, or security reviewer.
• Maximum delegation depth, dialogue rounds, token usage, and cost.
• Read-only or editing permissions for each agent.
• Separate worktrees when agents edit simultaneously.
• A visible tree showing which agent created each subagent.
• The ability to pause, cancel, question, or redirect any agent.

This would go beyond merely running several independent tasks. It would let models with different strengths and failure modes actively review one another and produce a more thoroughly challenged solution. Agreement would not be treated as proof that an answer is optimal, and unresolved dissent would remain visible to the user.

This also overlaps with the cross-provider orchestration idea in #3138.

[rcbran]

Adding a concrete use case for the cross-provider part of this.

I came to T3 Code from oh-my-pi, where model roles let a Claude orchestrator dispatch subagents to other providers per role — cheap mechanical work to a small OpenAI model, review passes to a different one, while the orchestrator itself stayed on Claude. Being able to mix providers within one agent's workflow, rather than switching the whole thread, was the feature I used most, and it's the one thing I lost migrating over.

Right now I'm hand-rolling it: my Claude orchestrator shells out to codex exec --model gpt-5.6-luna for well-specified coding tasks and reads the result back. It works, but everything valuable about doing it in-harness is missing — the delegated run isn't in the thread, has no attribution, and shares no context with the parent.

One design note from building the workaround, since I don't think it's obvious: permission rules don't cross the provider boundary. My harness-level deny rules on destructive project commands have zero effect inside a delegated Codex process, because that process only reads its own config. I had to re-implement the same policy as a Codex PreToolUse hook to close the gap. If cross-provider delegation lands, per-agent permission scope (read-only vs. edit, and an allowed-command policy that actually applies to the child) probably needs to be part of it rather than a follow-up — otherwise delegation silently widens what an agent can do.