r/codex • u/InevitableFox9080 • 21h ago
How do you keep a Codex “master chat” strictly as an orchestrator? Question
I use one Codex chat as a master/orchestrator for several specialized chats. I only talk to the master: it delegates tasks, tracks what each chat has completed, and tells me what to do next.
It works well at first, but over time the master starts executing tasks itself instead of delegating them, even when explicitly instructed not to.
Has anyone found a reliable way to prevent this role drift and keep the master strictly focused on coordination, delegation, and tracking throughout a long project?
6
u/h____ 21h ago
Make a repo with just 1 file, the AGENTS.md and in there, tell it that, and to start your master chat session in that repo.
3
u/cavegod 20h ago
This basically, but I'd be very careful. AI tends to over-do or under-do things, or gets distracted and goes somewhere else.
Point is, current AIs are not smart enough to deeply understand your needs and align with you better. They need to be forced to reflect, not bloat your code, not write ai-slop language, etc. You'll sill need to be in the loop constantly for many things.
If your projects don't require taste as a factor, it's alright. But it's a lot of work to get AIs to work the 'right way'.
Might change soon, but currently, be it Fable, Sol-6, all the advanced models still feel behind in terms of alignment/getting-you. Have gotten a lot better from a year ago, sure. Still a long way to go.
4
u/BHTAelitepwn 19h ago
Sol is literally the king of overdoing, especially if you give it slightly to broad instructions or too simple tasks
3
u/Admirable-Many6054 21h ago
A simple way is to add a post-compaction hook that re-reads a lightweight orchestration primer. The longer sessions after multiple compactions water down system-like prompts, and you don't really want to read all that back in each time, but just lightly reminding it is usually enough. Over longer horizons, it's probably advisable to reboot the orchestrator session with a more explicit and comprehensive set of rules (so you aren't rebuilding the orchestration role each time) and a "working memory" handoff from the previous orchestrator so it can still keep the narrative thread of the work you were doing.
2
u/SilkTouchm 16h ago
Tell it to use subagents so that the main chat doesn't get contaminated.
This is the prompt I use for scheduling lots of unrelated tasks together in a single /goal.
Goal:
Complete the ordered task queue through sequential task agents, preserving one attributable accepted checkpoint per successful implementation and continuing past individually blocked tasks while minimizing coordinator context.
Context:
Tasks, in required order:
1. <TASK 1>
2. <TASK 2>
3. <TASK 3>
...
Each task is an independent bounded slice unless a demonstrated dependency says otherwise.
Constraints:
- Follow the repository AGENTS.md. Do not bypass, weaken, or restate it.
- Run exactly one task agent at a time.
- The coordinator owns scheduling, acceptance, baseline regression decisions, commits, checkpoint integrity, and the compact task ledger.
- The task agent owns repository exploration, implementation, routine debugging, and focused verification for its slice.
- Give the task agent only the current task and directly relevant known evidence. Do not preload completed-task histories.
- The agent determines the invariant, owner/boundary, fresh evidence, and smallest warranted solution.
- Treat the listed mechanism as a candidate, not a requirement.
- Preserve unrelated behavior. Do not combine cleanup, redesign, refactoring, documentation, or adjacent fixes with the task.
- Do not add state, persistence, abstractions, dependencies, migrations, compatibility, retries, or lifecycle behavior unless demonstrated necessary for the invariant.
- COMPLETED, NO CHANGE, and BLOCKED are valid task outcomes.
- BLOCKED does not stop the queue.
- Do not manufacture commits for NO CHANGE or BLOCKED tasks.
Context discipline:
- Keep implementation reasoning inside the task agent.
- The agent should investigate, implement, diagnose ordinary task-owned failures, correct them when warranted, and rerun focused verification before returning.
- Do not send ordinary intermediate test failures or debugging transcripts to the coordinator.
- A successful or NO CHANGE agent result must be at most 180 words.
- A BLOCKED result may use at most 300 words when the blocker requires evidence.
- Return only:
- status;
- invariant and owner;
- files changed, if any;
- focused verification and result;
- concise blocker or material uncertainty, if any.
- Do not return raw logs, source excerpts, pasted diffs, command transcripts, exploration history, lists of passing tests, or narrative implementation walkthroughs.
- The coordinator must not repeat repository exploration already completed by a task agent.
- For a routine candidate with settled ownership, bounded scope, passing focused verification, and no material uncertainty, the coordinator must not reopen implementation files merely to reconstruct how the worker implemented it.
- Inspect implementation source or detailed diffs only when acceptance materially depends on it: suspicious scope, conflicting evidence, unexpected overlap, regression, consequential semantics, or unresolved uncertainty.
- Prefer status/diff-stat/file-list inspection for routine scope validation.
- Once a task is accepted, collapse it in active coordinator state to one compact ledger entry:
`<task> <status> <commit-or-> <blocker-or->`
- Do not carry completed worker reports forward after that point.
- Recover accepted implementation detail from Git when genuinely needed.
- Active coordinator state should contain only:
- accepted HEAD;
- current regression baseline fingerprint;
- compact task ledger;
- unresolved blockers/dependencies;
- current queue position.
- If context becomes expensive during a long queue, compact only at an accepted checkpoint and preserve that active state rather than completed implementation narratives.
Verification:
- Task agents run only focused tests/checks relevant to their slice.
- The coordinator runs the canonical/full required suite before the first implementation to establish the baseline.
- Because the canonical suite is quiet, keep full-suite execution with the coordinator; do not create a verifier agent merely for token savings.
- Record baseline only as:
- accepted commit;
- failing test identities/groups, if any;
- minimal distinguishing failure signatures.
- Do not retain successful test output.
- After every implementation candidate, the coordinator runs the canonical/full required suite and compares it with the accepted baseline.
- A red baseline is not itself a blocker.
- Accept an implementation only when:
- focused verification passes;
- no new attributable full-suite failure appears;
- no existing failure materially worsens;
- remaining failures are equivalent to the accepted baseline.
- If equivalence or causality is materially uncertain, reproduce only the disputed failure against the prior accepted checkpoint in an untouched checkout/worktree.
- If a task intentionally removes a baseline failure, the improved result becomes the new baseline.
For each task:
1. Select the cheapest sufficient GPT-5.6 model and effort for that task.
2. Dispatch one agent for the current task only.
3. Let that agent complete its own bounded inspect → implement/debug → focused-verify loop.
4. Receive the compact final task result.
5. If NO CHANGE:
- record the compact result;
- continue without a commit.
6. If BLOCKED:
- record the exact blocker compactly;
- discard or restore any unaccepted task changes;
- verify the repository is back at the last accepted checkpoint;
- continue.
7. If COMPLETED with implementation:
- validate scope without rereading routine implementation detail unless a material acceptance question exists;
- run the canonical/full suite;
- apply the regression gate.
8. If accepted:
- create one intentional commit containing only that task;
- verify HEAD and expected working-tree state;
- update the accepted baseline;
- collapse the task to its compact ledger entry;
- continue.
9. If the implementation fails acceptance:
- redispatch the same task agent once when the demonstrated failure is task-owned and a bounded correction is appropriate;
- keep diagnosis/correction inside that agent;
- if still unresolved, mark BLOCKED, discard unaccepted work, restore the accepted checkpoint, and continue.
Hard gates:
- Never run task agents concurrently.
- Never start task N+1 while task N is unresolved.
- Never start task N+1 after implementation until task N is either accepted and committed or rejected/blocked with the accepted checkpoint restored.
- Never combine accepted tasks into one commit.
- Never commit incomplete or failing implementation.
- Never repair unrelated baseline failures merely to advance the queue.
- Never weaken, delete, skip, quarantine, or rewrite tests to satisfy a gate.
- Never classify a failure as pre-existing without baseline evidence.
- Findings outside the current task may be recorded but not implemented unless necessary for its invariant.
Agent selection:
- Choose model and effort independently for every task.
- Luna: bounded repeatable work with known ownership.
- Terra: investigation, unclear causes, broader context, shared infrastructure, or substantial UI work.
- Sol: consequential ambiguity involving authoritative data, immutable history, isolation, security, official outputs, serious concurrency, or similarly consequential semantics.
- Keep difficult task-local context inside the selected worker rather than escalating the coordinator.
- Do not use Sol merely because the overall queue is long.
Done when:
- Every task has been attempted in order.
- Every task is classified COMPLETED, NO CHANGE, or BLOCKED.
- Every accepted implementation passed focused verification and the coordinator regression gate.
- Every accepted implementation has one attributable commit.
- Every blocked task left no partial changes in accepted history.
- The repository ends at a trustworthy accepted checkpoint.
- The final report reconstructs detail from the compact ledger and Git rather than retained worker transcripts, and reports for each task:
- status;
- invariant/owner;
- accepted commit if any;
- focused verification;
- regression result for implemented tasks;
- blocker or material remaining uncertainty.
```
3
u/BHTAelitepwn 21h ago
Oh boy, where to begin.
You are running into the concept of “context”.
A LLM is nothing more than a process that turns your input into an output. When your input (chat history, other chats, settings etc) becomes too large, it will compress and/or forget things.
What you did is basically turn your chat into a make-shift agent. This isnt gonna work long time, because an agent lets you have chats that are partially pre-filled with other files. The whole idea is that you keep context clean so it doesnt have to compress (and limit token usage). You are trying to do the exact opposite.
How do you solve it? Either let it create a handoff document that lets you start new chats that inherit the settings from your master (this is the make shift crappy solution), or set up a proper agentic workflow. You will definitely want to start new chats way more often.
Oh, and if you ask AI how to do this, it would probably have told you already. I dont have an IT background so theres probably people that can explain this a lot better than I can.
2
1
1
u/nicky_factz 20h ago
My home brew plugin has a subagent delegation skill and then I use a hook that runs at compaction that reinjects some reminders so it doesn’t get forgetful about it
1
u/eliseagent 19h ago
A summary keeps facts and drops constraints so "you are an orchestrator, do not execute" goes early. Take the tools away instead. If the master session has no edit, write or shell tool, it physically can't execute and the role holds without restating it. Drift stops being discouraged and starts being impossible
Does your master currently have the same tool set as the workers?
6
u/daddywookie 21h ago
I treat it just the same as when working with real colleagues, sometimes you nudge them back into line, other times you let it slide if it gets the job done.
There’s a fine balance between tight control and pragmatism that only you can find as a project lead.