Let an outside coordinator turn off injected orchestration instructions and get durable thread events

[BGamboa13]

We run T3 Code as the host for several agent threads that an outside coordinator process supervises. The agents bring their own delegation rules, and two gaps make the layers collide:

1. Add a per-project or per-thread setting to omit T3's injected orchestration instructions and the delegate_task tool, so an outside coordinator's own workflow is not overridden (see [Bug]: Host delegation routing overrides an explicit Bash/tmux agent workflow #30663). Today the instructions are added whenever a T3 MCP session exists, and the only per-project switch turns whole providers off.
2. Revive the idea from the closed PR feat(server): tell outside agents when a watched thread needs them #22595: a durable way for an outside process to learn that a thread finished, failed or is waiting, either a webhook per thread or an append-only event log with an ack offset. Today the only options are polling t3 thread show or holding t3_thread_wait open.

We are happy to test a change against our setup.

[thomasvan]

We run into the first point here too, and we measured it.

T3 injects orchestration guidance into every thread. On Claude it goes through the SDK's systemPrompt.append, ahead of any --append-system-prompt-file text. On Codex it arrives as <t3_code_orchestration_0N> developer messages, after the instance's own developer_instructions. Part of that guidance is workflow policy, and a host that runs its own process may need to differ from it. Three examples:

• "Every new delegate review or re-check is a new delegate_task …, never a t3_thread_send."
• "Fix small review findings yourself; start no delegate for them."
• "t3_thread_launch and create_threads make new top-level threads, only when the user asks for a new thread."

We ran a Codex agent whose own instructions told it to send a re-check to the same reviewer with t3_thread_send. In 4 of 5 runs it followed T3's text instead. In one of those runs it refused to do the re-check at all, because "T3 instructions … prohibit reusing a Reader". We then added a sentence to our instructions saying that ours take precedence, and that fixed it in 3 of 3 runs. The fix still depends on the model weighing two texts that contradict each other.

Two things would help:

• A setting on a provider instance that appends to, or replaces, the workflow part of the injected guidance, while keeping the facts about the tools.
• Failing that, T3 could phrase those lines as defaults ("unless your instructions say otherwise").

Measured on T3 Code (Beta) Desktop 0.1.7, codex-cli 0.167.0 and Claude Code 2.1.319, on macOS. Related: #30663.

[notanobject]

Yes, this is a PITA. I also have my own review workflows and don't appreciate having the law dictated to me (or the wasted tokens.)

[kkolodziej7]

+1 on point 1, with a concrete shape.

We run a role-based coordinator on top of T3: one coordinator thread per product, a lead thread per issue, engineer threads per task. Roles address each other through our own MCP server, and our repo instructions define delegation (which provider to use, when a review is a new thread, how to wait). T3's orchestration section (about 4,000 characters in 0.1.9) reaches every one of those threads, and parts of it contradict our rules. So each agent pays for both versions, and our AGENTS.md has to say "where T3's notes offer a choice, this file decides".

The shape in #35134 would solve this if it also covered the orchestration section. There, visualInstructions takes custom text to replace the section, "" to omit it and null to restore the default. The same for orchestration, e.g. orchestrationInstructions, is what #26879 offered before it was closed for conflicts. We would keep T3's MCP tools and the other sections (PR linking, background waits) as they are; only the orchestration text needs to be replaceable or omittable, ideally per project.

Happy to test it against our setup.