Declarative Dynamic Workflows foundation for Codex
What variant of Codex are you using?
CLI
What feature would you like to see?
Summary
I would like to propose an experimental foundation for declarative Dynamic Workflows in Codex.
I understand from docs/contributing.md that unsolicited PRs are not currently accepted, so I am opening this as a proposal first rather than requesting code review directly.
Prototype branch:
https://github.com/ErenAri/codex/tree/dynamic-workflows-pr4
Compare view:
https://github.com/openai/codex/compare/main...ErenAri:codex:dynamic-workflows-pr4
Motivation
Codex already has subagent and MultiAgentV2 infrastructure. A workflow layer could provide a typed foundation for repeatable, bounded, inspectable multi-agent orchestration without placing all intermediate orchestration state inside the main model context.
The goal is not to add a broad user-facing workflow runtime immediately. The goal is to establish a conservative foundation that can later support workflows safely.
Prototype scope
The prototype includes:
- a standalone
codex-workflowscrate - TOML workflow manifest parsing and validation
- strict unknown-field rejection
- deterministic DAG validation and phase waves
- an in-memory workflow run store
- a mock workflow executor
- an async-compatible workflow scheduler/executor abstraction
- a private core-side MultiAgent workflow executor adapter
- a minimal CLI validation command:
codex workflows validate <path>
### Additional information
_No response_
7 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Thanks for the duplicate suggestion.
I reviewed #24721. It is closely related and describes the broader product concept of user-defined Codex workflows.
I think this issue may still be useful as a more implementation-oriented follow-up/prototype. The scope here is intentionally narrower:
codex-workflowscrateThis proposal does not try to define the full UX surface yet, such as slash-command workflows, workflow progress panels, persistent workflow state, JavaScript workflow scripts, or runtime workflow execution exposed to users.
If maintainers prefer to keep the discussion centralized in #24721, I’m happy to close this and move the implementation notes/prototype link there.
deterministic DAG validation and phase waves -> this is the way.
I agree with this. Claude code implemented dynamic workflows recently and it is hugely superior to subagents when doing large scale refactoring etc.
Thanks for the feedback. The strongest initial slice may be the deterministic workflow foundation rather than the full runtime surface. If maintainers are interested, I can narrow this down to a first invited PR containing only:
The broader runtime pieces can stay out of scope until the direction is confirmed.
This is what I need most !
Thanks for the additional feedback from others here.
I think the strongest low-risk first slice is not a full user-facing workflow runtime, but a deterministic workflow validation foundation that could later support whatever product surface Codex chooses.
A narrow invited PR could be limited to:
codex-workflowscrateThis keeps the proposal separate from the broader product question in #24721.
On the “skills referencing other skills” question raised there: the main difference is that a workflow needs explicit structure and validation before execution:
A skill chain can describe a process in natural language, but it does not give Codex a typed, validated execution graph. The proposed foundation is mostly about making the orchestration boundary explicit and safe, not about adding a broad workflow product immediately.
If this direction aligns with the team’s thinking, I can reduce my prototype to only the validation/DAG foundation and wait for an explicit invitation before opening any PR.