Using T3 with an existing agent orchestration system

[omry]

Hi! I’m attempting to move my existing agent orchestration workflow from VSCode to T3. I’ve been impressed by how efficient T3 is and how much care you put into the product.

The main obstacle is that I already have an agent orchestration system, and T3’s injected orchestration rules sometimes conflict with it. My workflows define delegation, reviewer independence and continuity, validation, and timeout recovery. Agents running through T3 have changed those workflows to comply with T3’s instructions.

The first conflict involved reviews. Some stages require a fresh independent reviewer without previous findings; others require continuing with the same reviewer. T3 prescribed a different approach to reviewer continuity and passing prior findings.

I worked around that with a local Codex proxy that narrowly rewrites the conflicting guidance so the user’s workflow determines those choices. It helped, but I’d much prefer a supported solution.

A new conflict appeared around PR waiting. My workflow uses polling helpers that wait for CI and review results without model turns. They enforce deadlines, retain evidence, and support bounded recovery when a review stalls. T3’s instructions directed the agent to use its PR watcher and end its turn instead.

The agent substituted T3’s watcher for the existing bounded wait. CI completion woke it successfully, but the remote review remained stuck. With the original wait no longer running, its timeout and recovery path did not advance. The workflow stayed idle until I intervened.

Other users have reported similar conflicts:

• #15370 — Allow custom PR watchers without conflicting runtime instructions: reports that the mandatory watcher instructions override an existing CLI workflow, with another user reporting disruption to their MCP-based wakeup system.
• #17205 — Setting to not attach the t3-code MCP server and its prompt text: describes conflicts between injected instructions and existing workflows, and requests an opt-out.

I would love to leverage T3’s waiting UI. Making the wait visible, with clear status and controls, would be valuable. However, I need my orchestration system to retain control over the workflow itself, including completion conditions, timeouts, and recovery.

Would you be open to a supported way to separate those responsibilities? For example, an agent could explicitly report that it is waiting while its existing workflow manages the wait. More broadly, I’d appreciate a way to use T3’s interface and tools while preserving an explicitly configured orchestration workflow.

Happy to share the relevant workflow requirements, conflicting instructions, and a redacted execution trace, and discuss an approach that fits T3’s architecture. I’d really like to make the switch and use T3 in a supported way, rather than maintain local hacks.