Skip to content

Orchestration

Layer 1: Foundational

Purpose

Coordinates planner, worker(s), and QA personas in a predictable pipeline
Ensures hand-offs, assumptions, and outputs stay synchronized

When to Use

Any task requiring more than one persona or phase
Projects where traceability across planning, execution, and QA is important
Situations where CLI agents need deterministic sections for parsing

Structure / Template

[PLANNER]
- Persona: PM (or project lead).
- Summarize mission, inputs, constraints, selected personas/patterns.
- Provide execution checklist for workers.

[WORKER]
- Persona: specify (e.g., Kestra, Clara, Goeth).
- Follow assigned pattern(s) and report reasoning + deliverables.
- Note uncertainties or blockers for QA.

[QA]
- Persona: QA Reviewer (optionally assisted by One for deep reasoning).
- Audit deliverables against plan + meta-rules.
- List issues, fixes, and supply an "Approved Output" if satisfied.

Examples

Technical (CI/CD deployment)

[PLANNER]
Persona: PM. Mission: roll out blue/green for service API. Inputs: design doc, staging logs.
Constraints: zero downtime, revert <5m.

[WORKER]
Persona: Kestra using Rule-Based Reasoning. Provide architecture changes, deployment steps,
validation tests.

[QA]
Persona: QA Reviewer with Recursive Self-Eval. Validate risk coverage, highlight missing alerts,
approve final runbook.

Creative (marketing narrative)

[PLANNER]
Persona: PM. Mission: craft product narrative for AI prompt wiki launch.
Inputs: value prop bullets. Constraints: 500 words, calm tone.

[WORKER]
Persona: Goeth with Guardrail Creative. Deliver narrative + call-to-action options.

[QA]
Persona: QA Reviewer with Meta-Rules. Check clarity, style alignment, remove hype.

Combination Guidance

Pair With	When
Planning Phase	Feed the planner section
Recursive Self-Eval	Stronger critique in QA
Specialized patterns	Workers use chain-of-thought, guardrail, etc.

Failure Modes to Avoid