[Feature]: Add Orchestration/Delegation

[DivineRuins]

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

apps/web

Problem or use case

t3code have native support for major provider but lacks the proper communication between then, its currenctly serving as a QoL app rather than a Real power full workhorse

Proposed solution

implement dispatching cross provider agents and orchestration

Why this matters

It matters because it trasnforms T3code from just a conveiniece to a real powerhouse in code geenration.

Smallest useful scope

a model can signal an another provider models to start implementation or start a review.

Alternatives considered

No response

Risks or tradeoffs

No response

Examples or references

No response

Contribution

• I would be open to helping implement this.

[mrpunyetaz-cloud]

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

apps/web

Problem or use case

t3code have native support for major provider but lacks the proper communication between then, its currenctly serving as a QoL app rather than a Real power full workhorse

Proposed solution

implement dispatching cross provider agents and orchestration

Why this matters

It matters because it trasnforms T3code from just a conveiniece to a real powerhouse in code geenration.

Smallest useful scope

a model can signal an another provider models to start implementation or start a review.

Alternatives considered

No response

Risks or traders off

No response

Examples or references

No response

Contribution

• [✓] I would be open to helping implement this.

[Keesan12]

The smallest useful scope here is probably not 'cross-provider orchestration' in the abstract, but one bounded handoff contract.

Something like:

• planner model creates a task dossier
• implementer model gets a bounded artifact target
• reviewer model can only return approve / reject / requested changes with evidence
• the parent run needs a typed receipt before it can hand off again

Without that, multi-provider orchestration can look powerful while mostly just multiplying retries and context drift. The hard part is not getting model A to call model B. It is making each handoff explicit enough that you can tell whether the chain is actually improving the work. MartinLoop keeps reinforcing that for me: orchestration becomes much more useful once every hop has a stop rule and a receipt instead of just another prompt.

If you build the first slice, I’d bias toward one planner -> implementer -> review path before adding broader arbitrary delegation.

[juliusmarminge]

our new orchestrator (#2829) will have all of this