Locale: en
Note: This article separates public product facts available as of October 4, 2026 from hands-on operating impressions. Public information about Astra, Codex, and Claude Opus 5.5 is checked against official sources. Statements such as “Astra tends to explore too broadly” or “Dot works well as a supervisor” describe one workflow, not universal benchmark results. “Dot” here is simply the name used for the supervising AI role.
1. The basic idea: do not make one AI employee do every job
When an AI is strong, the tempting prompt is simple: do everything.
Research the problem, design the fix, edit the code, test it, recover from failure, manage progress, and explain the result.
That is several jobs hiding inside one sentence.
A useful split is:
- Explorer: Astra — search widely for causes, alternatives, missing assumptions, and architectural risks
- Supervisor: Dot — keep the scope narrow, track status, notice stalls, and choose the next action
- Executor: Codex — make concrete code, file, research, and test changes
If one model can reliably take a goal from start to finish, it can still be simpler to use one model. Anthropic explicitly positions Claude Opus 5.5 for agentic coding, complex multi-tool work, and long-running tasks.[5]
So the rule is not “multi-agent is always better.”
Use one agent when one agent closes the job. Split roles when one agent makes the job sprawl.
2. Powerful exploration can become scope expansion
A strong explorer is excellent when the problem is genuinely unclear.
It questions assumptions. It looks for hidden dependencies. It proposes alternate designs. It traces failures beyond the first visible error.
That is exactly what you want when a system is stuck.
The problem appears when every routine task gets the same treatment.
“Fix this button” becomes: “Let us revisit the component model.” “Let us inspect related services.” “Let us improve future extensibility.” “Let us clean old dependencies while we are here.”
The button is still broken.
That is not necessarily a bad model. It is a role-design problem.
OpenAI’s Agents SDK describes agent orchestration as deciding which agents run, in what order, and how the next step is chosen. It distinguishes LLM-led orchestration from code-led orchestration.[1]
Exploration is valuable. Endless exploration is not completion.
3. Dot works best as the foreman, not the genius
A supervisor does not need to produce the smartest answer in the room.
The supervisor needs to know:
- what task is active
- what has finished
- what failed
- who should act next
- when repeated failure should be escalated
That is why the supervisor role can be surprisingly effective even without being the most powerful model.
If Astra says, “I found a broader redesign,” Dot can answer, “Good. New task. First restore the broken service.”
If Codex fails a test, Dot can send it back with the failed log.
If the same failure repeats three times, Dot escalates the problem.
The supervisor is the AI version of the person who notices the factory line has stopped while everyone else is discussing a beautiful new factory.
4. Codex becomes easier to control when the input and output are bounded
Codex is useful as an executor when the assignment has clear edges.
Give it:
- repository
- target files
- symptom
- allowed scope
- success condition
- tests to run
- required return format
Do not ask it to decide the company strategy if the real job is to make a pull request pass.
OpenAI’s Symphony project takes a similar direction: it treats issues and tasks as durable units of work rather than making a coding session itself the center of the system.[2]
That distinction matters.
The conversation is not the job. The task is the job.
Chats can disappear. Models can change. The task state should survive both.
5. thread_id is useful, but task_id is the real primary key
If one AI collects a question and another AI answers it, source_thread_id is useful for routing the final response.
But one thread can contain several questions.
So the minimum state should separate:
- task_id — what work is this?
- source_thread_id — where does the answer go?
- source_message_id — which message triggered it?
- manager — who coordinates it?
- executor — who performs it?
- advisor — who handles escalation?
- status — where is the work now?
- attempt — how many tries?
- next_action — what happens next?
Useful statuses include pending, working, blocked, review, done, delivered, and failed.
“Probably finished” is not a status.
6. Keep the normal loop small; escalate only difficult cases
A cheap, stable loop can be:
Normal: Dot → Codex → Dot → Codex
Escalation: Dot → Astra → Dot → Codex
Astra does not need to sit inside every cycle.
Possible escalation rules:
- same failure three times
- several plausible root causes with no discriminator
- architectural change required
- multiple repositories involved
- request conflicts with existing specifications
This turns the most exploratory model into a specialist rather than a permanent committee member.
The goal is not only to save credits. It is to use broad reasoning where broad reasoning is actually valuable.
7. Do not make a temporary premium plan part of permanent infrastructure
A dangerous design mistake is building the whole production workflow around a feature that is only available while a particular subscription remains active.
Premium access can be a booster. It should not be the only place where the process exists.
Persist the real operating knowledge:
- task state
- prompts
- acceptance criteria
- test commands
- retry limits
- escalation rules
- failure logs
If the model changes, the workflow should still know what to do.
The worst possible migration plan is: “We cancelled the model, and apparently we also cancelled our memory.”
8. If Opus 5.5 reliably goes from 0 to 10, use the simpler system
Multi-agent diagrams are fun.
You can create supervisors, researchers, workers, reviewers, and escalation trees.
Then a human becomes HR for a company made entirely of bots.
That is not the objective.
Anthropic describes Claude Opus 5.5 as a model for agentic coding, multi-tool tasks, long-running work, and complex workflows with reduced supervision.[5]
If, in your real environment, it reliably goes from:
goal → research → implementation → tests → repair → completion report
then using it directly can be better than maintaining a multi-model control system.
Do not build AI Incorporated when one competent worker closes the ticket.
9. A practical minimum architecture
The whole design can be small:
- Put every incoming question or incident into a queue with task_id.
- Dot chooses priority and the next action.
- Codex performs the bounded task.
- Dot validates the result.
- Escalate to Astra only when a rule is triggered.
- Route the final answer back to source_thread_id.
- Close only after delivered is confirmed.
- Send truly end-to-end jobs directly to Opus 5.5 when that is simpler.
Then the infrastructure stores roles, not brand names:
manager executor advisor
Swap the model assigned to a role later.
The workflow survives product changes.
10. Final takeaway: automation is about closing work, not adding more AI
The hard part of AI work is often not generating more thoughts.
It is deciding when thinking stops and execution begins.
The explorer widens the map. The supervisor closes the loop. The executor moves the files.
Mixed together, you can get brilliant output that never finishes.
Separated, the exchange becomes:
Astra: “I found seven alternatives.” Dot: “Test number two.” Codex: “Fixed. Tests pass.” Dot: “Close.”
Suddenly it looks like a company.
That is fine—as long as the human does not have to be the department manager every five minutes.
Keep the loop tight.
More agents are not more automation.
Automation means the work reaches a verified end without a human repeatedly rescuing it.
