Add first-class workflow profiles: delivery and co-creation

[Ilanbux]

Problem statement

Overstory seems optimized today for execution-oriented orchestration, which works very well for well-scoped implementation tasks.

I would like to propose first-class support for two workflow profiles:

delivery
For tasks where the solution is already known or tightly specified:

bug fixes
focused features
targeted refactors
In this mode, the human should not need to stay in the loop during execution. The system should optimize for:

autonomous execution
strong quality gates
tests, review, docs
escalation only on ambiguity, risk, or unexpected blast radius

co-creation
For larger, more open-ended work where the best solution emerges during the process:

building a product/site from scratch
architecture/design work
major UX or product direction efforts
In this mode, the human should stay in the loop at explicit decision points. The system should optimize for:

discovery before implementation
option generation with tradeoffs
milestone reviews
structured human decision gates

Why
These are two different collaboration problems:

some tasks need speed, rigor, and autonomy
others need exploration, iteration, and human judgment
Using the same execution-first orchestration model for both creates friction, especially for open-ended work where discussion and innovation are part of the process, not an exception.

Proposed solution

Possible direction
A workflow profile could influence:

agent prompts
expected artifacts
escalation behavior
whether the default posture is “execute now” or “explore and align first”
whether human approval gates are expected
Examples:

delivery: compact spec, autonomous build/review flow
co-creation: discovery notes, option memos, ADRs, milestone checkpoints, “waiting for human decision” states
This would make Overstory more flexible without reducing its autonomy for implementation-heavy workflows.

Alternatives considered

No response

[lucabarak]

Good proposal — the tension between autonomous execution and exploratory work is real.

The current orchestration model is built around the propulsion-principle ("execute immediately, don't ask for confirmation"), which works well for delivery but creates friction for open-ended work exactly as you describe.

Architecturally, I see a few natural integration points:

• Agent definitions (agents/*.md) are already modular per capability. A workflow profile could ship as alternative definition sets — e.g., a co-creation coordinator that pauses after decomposition for human plan approval instead of dispatching leads immediately.
• Config already has per-capability overrides (agents.capabilities). A top-level workflow: delivery | co-creation field could influence which agent definitions and constraints get injected.
• Mail system already supports typed escalation routing. A decision_gate message type that blocks execution until the human responds would be the mechanical backbone of co-creation mode.

The hardest design question is defining the checkpoint granularity — does the coordinator pause after planning? Do leads generate option memos instead of specs? Are there mandatory human gates at milestone boundaries? These choices shape the entire flow.

Flagging this as architectural since it's cross-cutting. @jayminwest — thoughts on whether this fits the project's direction?

[EugeneTrapeznikov]

I had similar idea. But I wanted to make it flexible.

My idea is two steps backward compatible changes:

1. Specify coordinator on start. This is main workflow entry point. PR for that I just created feat: add --def flag to coordinator start command #107

The idea is that now we are using only coordinator.md. We can have multiple coordinators. And do not need to add all of them to this repo. Anyone can have their own custom workflow.

2. Add to agent-manifest.json new field "spawnableAgents". This agent would be able to spawn only specific next level agents. This way we control workflow. Again anyone can add their own custom agents here.

[Koroqe]

Having separate commands for "explore and plan" vs "execute" solves this naturally. Planning phase is collaborative — you review the spec and adjust. Execution phase is autonomous and structured. Combining both always creates friction. https://github.com/Koroqe/claude-code-sdlc splits this into /bootstrap-feature (exploration) and /implement-slice (execution) for exactly this reason.

[RogerNavelsaker]

Implemented in #130.

This adds first-class delivery / co-creation workflow aliases, a new ov workflow start <workflow> entrypoint, OpenSpec-backed co-creation task specs at openspec/changes/<task-id>/tasks.md, and a fallback to emitted workflow prompt files when canopy is unavailable.

[jayminwest]

Resolved in v0.9.3 — PR #130 landed first-class workflow profiles with OpenSpec-backed task specs and fallback to emitted workflow prompts when canopy is unavailable. Both delivery and co-creation modes are now supported.