Pipeline & Roles

When a task needs more than direct execution, maestria can separate it into three stages. The orchestrator selects the stages that add information or reduce risk; it does not run every stage for every task.

The Three Stages

Stage	Question	Specialists	Output
Thinker	What do we know, and what should we do?	adventurer, architect, planner, diagnose	Reconnaissance, a decision, a plan, or a confirmed cause
Worker	Can we produce the requested result?	builder, writer	The implementation or documentation change
Verifier	Does the result meet the evidence and quality requirements?	reviewer	An independent review with actionable findings

Thinkers analyze and plan; workers produce the artifact (diagnose may apply a confirmed fix); verifiers inspect without editing. The separation keeps one agent from approving its own work.

Flow

The common route, with each stage optional:

orchestrator
    -> thinker (when context, design, planning, or diagnosis is needed)
    -> worker
    -> verifier (when independent validation is required)

Each handoff carries the outcome, context and constraints, acceptance evidence, and next step; link to existing artifacts instead of copying the conversation.

Adapt the route to the task:

• Use adventurer when the code or dependency path is unfamiliar.
• Use architect when the approach has meaningful trade-offs.
• Use planner when delivery needs milestones, verification criteria, or rollback points.
• Use diagnose when a failure’s cause is not established.
• Skip the thinker when the task is familiar and already scoped, or stop after it for research-only requests.

If a verifier rejects the result, route an implementation defect back to the worker and a design or scope defect back to a thinker. Do not ask the worker to guess at a rejected design.

Maker/Checker Split

The specialist that produces an artifact must not be the specialist that validates it. This is the pipeline’s core quality boundary.

Reviewer independence

A reviewer may need context from a thinker, but it must inspect the maker’s result independently and report findings without editing it.

Use one independent reviewer for ordinary work; add a security, architecture, performance, or UX lens only when the requirements or diff expose that risk. See Workflow Patterns for practical review routes.

Bound the Repair Loop

Define a verifiable stopping condition before delegating. One repair/re-review pass is the default; another only when a named blocker remains unresolved or the repair introduces a new material regression, capped at three per outcome. If the same cause recurs, escalate with:

Tried X, Y, Z. Blocked by [cause]. Need [input] to proceed.

Choose a Route

The pipeline is optional: When to Use maestria compares direct execution, one specialist, and full orchestration, and Specialist Reference details each role.