Until now, Orca planned missions as a linear chain — each phase waited for the previous one, even if there were ten of them with no overlap. The result: with three sessions configured, only one agent actually ran while the rest of the queue sat idle.
That changes now. The planner can build a dependency graph (DAG) where independent phases start simultaneously — and genuinely use parallel capacity.
How it works
Each phase in the plan now gets an id (a short slug like api, ui, tests) and optionally a dependsOn — a list of phase ids that must complete before this one starts. A phase with no dependencies starts immediately.
Example plan output:
[
{ "id": "schema", "title": "New DB schema", "dependsOn": [] },
{ "id": "api", "title": "API endpoint", "dependsOn": ["schema"] },
{ "id": "ui", "title": "Dashboard component", "dependsOn": ["schema"] },
{ "id": "tests", "title": "Integration tests", "dependsOn": ["api", "ui"] }
]Both api and ui depend only on schema — they start at the same time. tests waits for both. Four sequential steps become three time slots.
Two-pass dependency wiring
Graph persistence happens in two passes:
- Create tasks — all phases are written to the database first, so
dependsOncan reference siblings defined before or after in the array - Wire dependencies —
dependsOnmaps to real DB ids, hallucinated slugs silently fall back to the previous phase, and cycles are never formed
Backward compatibility is preserved: if no phase carries an id, Orca automatically falls back to a linear chain — legacy plans and manual mode work without changes.
Auto-PR: parallel agents need isolation
Parallel agents cannot work in a shared checkout — one commit would overwrite the other. So when you set more than one session, Orca automatically enables PR-native mode: each phase gets its own worktree, makes changes, and Orca consolidates them into a single PR.
If you explicitly disable PR mode (even with multiple sessions), Orca respects your choice — but parallel phases then run sequentially. That is safer than silently clobbering.
Resume notes instead of task description
The second major improvement in this commit: review feedback and relaunch reasons are no longer appended as text blocks inside the task description.
Before, a task description would accumulate five stacked [Review rejected — ...] blocks after repeated failures. The new agent could not tell which feedback was current and which had already been addressed.
Now every task has a resume_note column — a single place for the current input. A review reject writes the new reason, overwriting the previous one. On a clean close, the note is cleared. The agent receives it as a separate block in its prompt, distinct from the static task brief.
Phase prompt respects parallelism
The phase agent prompt now says:
Other phases may already be done, or may be running RIGHT NOW alongside you in the SAME working tree. Do NOT redo or re-verify other phases’ work — and edit ONLY the files your own deliverable needs.
This is a fundamental shift from the earlier “earlier phases were already completed”. The agent no longer assumes it is in a serial pipeline — it knows others may be running alongside and must respect its own file boundaries.
Replan preserves graph width
When Orca replans mid-mission (e.g. after a review reject or new requirements), it picks up the current max_sessions and isolation settings from the mission. The new plan gets the same parallelism context — it does not silently collapse back to a linear chain just because planning is happening again.
Together, these changes mean Orca is moving from “one agent and a queue” to a real orchestrator that uses parallel capacity where it makes sense — and safely falls back to serial execution where it does not.