Pattern Abstract Grammar

Pattern Abstract Grammar

Structured Instructions for AI Systems

Orchestration Fundamentals

Multi-agent orchestration coordinates sequential agent execution through shared documents, handoff signals, and validation gates. This section covers the core concepts for building orchestrations.

Core Concepts & Bookend Patternα

Orchestration is a PAG pattern for coordinating multiple AI agents to accomplish complex tasks. Instead of one agent doing everything, orchestration divides work across specialized agents that execute in sequence, each passing context to the next. Every orchestration phase follows a VERIFY → VALIDATE → ACTION → VERIFY structure:

What Is Orchestration?

  • Sequential execution — agents run one after another, not in parallel
  • Shared documents — all agents read and write to the same workspace
  • Handoff signals — structured context passing between agents
  • Validation gates — checkpoints ensuring quality before progression
  • Single source of truth — no local copies that drift out of sync

Bookend Pattern Roles

  • Entry verifier (position 1) — documents baseline state, verifies prerequisites
  • Architecture validator (position 2) — analyzes integration points, finds dependencies
  • Action agents (positions 3-6) — execute implementation tasks
  • Exit validator (position 7) — analyzes post-implementation state
  • Completion verifier (position 8) — verifies phase completion, creates handoff

Agent Role Separationβ

Action agents are scoped to implementation tasks only. Verification agents are scoped to documentation tasks. This separation may reduce context pollution:

  • Action agent prompts omit documentation instructions
  • Verification agent prompts omit implementation instructions
  • Clear separation prevents conflicting responsibilities
RolePositionsDocuments?Purpose
VERIFICATION + DOCUMENTATION1, 8YesBaseline/completion verification
VALIDATION + DOCUMENTATION2, 7YesArchitecture tracing
ACTION (no documentation)3, 4, 5, 6NoImplementation only

8-Agent Phase Structureγ

A standard orchestration phase uses 8 agents with specialized roles:

PositionAgent RoleResponsibility
1Entry VerifierDocuments baseline state, verifies prerequisites
2Architecture ValidatorAnalyzes integration points, finds dependencies
3Primary ImplementerExecutes core implementation tasks
4Refactor SpecialistOptimizes and migrates code
5Compliance AgentApplies architectural patterns (SRP/SOC)
6Testing AgentValidates implementation via test gates
7Exit ValidatorAnalyzes post-implementation state
8Completion VerifierVerifies phase completion, creates handoff

Shared Document Protocolδ

Orchestrations use a fixed set of documents that persist across all phases. The orchestrator pre-creates these before Phase 1 begins:

DocumentPurposeUpdated By
prerequisite-statusBaseline state, phase prerequisites, readiness reportsEntry/Completion verifiers (1, 8)
implementation-logChronological actions, file modifications, test resultsAll documentation agents (1, 2, 7, 8)
architecture-decisionsChoices, rationale, pre/post architecture statesArchitecture validators (2, 7)
integration-pointsTraced relationships, import paths, dependenciesArchitecture validators (2, 7)
validation-resultsGate results, test outcomes, failure analysisArchitecture validators (2, 7)
workflow-stateCurrent phase/agent, blockers, handoff contextAll documentation agents (1, 2, 7, 8)

Document Lifecycle & Why This Worksε

Documents follow a strict lifecycle that prevents conflicts:

Document Lifecycle & Why This Works
SET document_lifecycle = "orchestrator-creates-agents-refine" SET lifecycle_create = "Pre-create empty with template" SET lifecycle_update = "Surgical replacement of sections" SET lifecycle_read = "Full document read before any write" SET lifecycle_delete = "NEVER during workflow"

Lifecycle Rules

  • Orchestrator creates — documents pre-created before agents run
  • Agents refine — agents only read and edit, never create
  • Surgical updates — targeted section replacement aims to prevent data loss
  • No deletion — documents persist throughout workflow

Why This Structure May Help

  • Context loss — shared documents aim to preserve context across agent invocations
  • Drift — single source of truth aims to prevent divergent states
  • Missing prerequisites — entry verifier blocks execution until conditions pass
  • Unverified output — exit verifier confirms results before handoff
  • Lost progress — workflow-state enables resumption from any checkpoint

Building Orchestrations

A step-by-step guide to creating multi-agent orchestrations from scratch.

Define Goal, Phases & Agent Typesζ

Start with the META block to establish clear intent, then break the work into phases with prerequisites:

1. Define the Goal (META)

  • intent — single sentence describing the orchestration's purpose
  • objective — measurable success criteria
  • context — what the orchestration depends on
  • priority — high, medium, or low

2. Break Into Phases

  • Entry prerequisites — conditions that must be true before phase begins
  • Defined scope — what gets implemented in this phase
  • Exit criteria — validation gates that must pass
  • Handoff to next phase — context passed forward

3. Assign Agent Types

  • Entry verifier and completion verifier use the same agent type
  • Architecture validator and exit validator use the same agent type
  • Update the registry once when agents change — not every workflow
  • Sequence follows: ev → av → pi → rf → ce → ts → av → ev

Define Documents, Gates & Handoffsη

Create purpose-specific documents, validation gates, and handoff signal structure:

4. Define Shared Documents

  • Documents are created empty before agents run
  • Each document has a single, clear purpose
  • Agents edit documents in-place — never create new versions

5. Define Validation Gates

  • Gates block progression until all conditions pass
  • Conditions should be verifiable — not vague assertions
  • 3-5 conditions per gate is typical

6. Define Handoff Signals

  • critical_files — list of files with line references the agent modified
  • key_findings — discoveries the next agent should know
  • blockers — issues preventing completion

7. Define Final Summary

  • gap_analysis — what was planned but not done
  • delivered — what was successfully completed
  • already_implemented — pre-existing functionality
  • recommendations — actionable next steps

Complete Minimal Exampleθ

A simplified orchestration showing the 8-agent bookend pattern (ev → av → pi → rf → ce → ts → av → ev):

Advanced Constructs

PAG supports advanced patterns for multi-agent orchestration and complex workflow scenarios.

Agent Registry & Sequencingι

Maps logical role names to concrete agent implementations. When an agent changes, update the registry once rather than every workflow:

Registry Pattern

  • agent_types — lookup table mapping role names to actual agent file names
  • agent_sequence_pattern — ordered array defining execution order
  • Positions 1 & 8 share verifier type — bookend pattern
  • Positions 2 & 7 share validator type — bookend pattern

Coordination Sequence

  • coordination_sequence — audit trail of planned operations, useful for debugging and resumption
  • Orchestrator creates empty documents first — agents never create, only read and edit
  • Phase 1 agent writes initial content; subsequent agents refine existing content
  • Each agent explicitly removes contradictions from prior phases — documents may converge toward accuracy

Phase Definition & Executionκ

Each phase runs all 8 agents in sequence. Phases are sequential units of work with prerequisites:

Phase Structure

  • agent_count = 8 — each phase runs the full 8-agent sequence
  • prerequisites — conditions checked before phase begins; blocks execution if unmet
  • success_criteria — what must be true for this phase to be considered complete
  • workflow_file/checklist_file — external documents that define phase-specific behavior

Nested Execution Loop

  • Outer loop iterates phases; inner loop runs all 8 agents in sequence
  • VALIDATION GATE prerequisites — blocks phase execution until all conditions pass
  • agent_config — bundles context (phase name, focus points) passed to the agent
  • EXECUTE Task — invokes the agent as a subagent with the configured prompt

State Machines & DAG Executionλ

Models workflows as finite states with explicit transitions, or as directed acyclic graphs for complex dependencies:

State Machine Pattern

  • STATE_MACHINE — declares a named state machine with defined states
  • STATE — a discrete workflow position; workflow is always in exactly one state
  • ENTRY: — action executed when entering this state
  • TRANSITION FROM...TO...ON — defines legal state changes and their triggers
  • Only transitions listed are allowed — invalid state changes are blocked

DAG Pattern

  • DAG — declares a dependency graph where tasks form a directed acyclic structure
  • NODE — a single task with its dependencies listed
  • DEPENDS_ON [] — empty array means no dependencies; this node can run first
  • PARALLEL_GROUP — explicitly marks nodes that can execute concurrently
  • DAGs prevent cycles — if A depends on B and B depends on A, the structure is invalid

Final Summary & Zone Accessμ

Structured output at workflow end that categorizes results, plus workspace partitioning for access control:

Final Summary Categories

  • gap_analysis — what was planned but not done; includes blockers and reasons
  • delivered — what was successfully completed with quantified metrics
  • already_implemented — functionality that existed before the workflow ran
  • recommendations — actionable next steps, not vague suggestions

Zone Access Rules

  • agent_shared — all agents can read and write; used for cross-agent documents
  • agent_specific — only the owning agent can write; others can read
  • meta_factory — read-only zone for templates; agents consume but never modify
  • RULE — enforcement block that checks every file operation against permissions

Discovery Rulesν

Prohibits hardcoded paths and static assumptions. Agents must discover file locations at runtime using glob patterns and config queries:

  • hardcode_paths = prohibited — no literal paths like /src/components/ in workflows
  • glob_pattern_discovery — use patterns like **/*.ts to find files dynamically
  • runtime_state_queries — read config files to determine paths at execution time
  • WHEN discovery_made — event handler for when an agent finds relevant information
  • Multi-task discoveries go to shared zone — single-task discoveries stay in agent-specific zone
  • Aims to prevent workflows from breaking when directory structures change

Alternative Patterns

Beyond the standard bookend pattern, orchestrations can follow different structures depending on the task.

Pattern Selection Guideξ

Choose based on whether you're implementing, analyzing, self-improving, or migrating:

Building new features
WrongPipeline Enrichment, INVESTIGATE→ACTION
CorrectBookend (VERIFY→VALIDATE→ACTION→VERIFY)
Codebase analysis
WrongBookend, Cleanup-First
CorrectPipeline Enrichment
Iterative self-improvement
WrongBookend, Pipeline Enrichment
CorrectINVESTIGATE→ACTION Cycle
Migration/refactoring
WrongPipeline Enrichment, INVESTIGATE→ACTION
CorrectCleanup-First Implementation
PatternWhen to UseAgentsComplexity
Bookend (VERIFY→VALIDATE→ACTION→VERIFY)Implementation with clear phases8/phaseMedium
Pipeline EnrichmentAnalysis building comprehensive report4-6 totalMedium
Investigate→Action CycleSelf-improvement, iterative refinement1 type, multi-phaseLow
Cleanup-FirstRefactoring, migration, tech debt2 sequential workflowsHigh

Pipeline Enrichment Patternο

Each agent consumes artifacts from all previous agents and enriches them. Unlike the bookend pattern where verification agents handle documentation and action agents handle implementation, pipeline enrichment has every agent contributing to shared artifacts:

  • Artifacts grow richer with each agent
  • Each agent has access to all previous findings
  • Final agent creates cleanup checklist that must complete before implementation
  • Two-checklist system: CLEANUP-CHECKLIST.md (old) → CHECKLIST.md (new)
  • Use for codebase analysis where each agent adds perspective to shared findings

INVESTIGATE → ACTION Cycleπ

Alternates between analysis phases and fix phases. The same agent type executes repeatedly, each time discovering gaps then fixing them:

  • Single agent type throughout (self-recursive improvement)
  • Alternating investigation and action phases
  • Each investigation phase edits the same gap-analysis document
  • Surgical document editing (remove outdated → add new)
  • Versioning with backup before deployment
  • Use for iterative refinement within a single domain of expertise

Cleanup-First Implementationρ

Separates cleanup from implementation into two sequential workflows with a hard gate between them:

  • Implementation cannot start until cleanup finishes
  • Clean slate principle — old architecture removed before new begins
  • Two separate checklists with explicit dependency
  • Reduces "ship of Theseus" problems where old and new code coexist
  • Use for migrations and technical debt removal

Handoff Signals

When an agent completes, it emits a structured handoff signal. The orchestrator reads this to determine the next action.

Signal Types & Structureσ

Orchestrations use a vocabulary of signals to communicate status:

  • agent_completed — which agent just finished
  • artifacts_location — where shared documents live
  • orchestrator_action — what should happen next
  • handoff_context — detailed context for the next agent
SignalBehaviorUser Action
ACTIVATE_NEXT_AGENTExecute next in sequenceNone
PAUSE_FOR_USERWait for approvalRequired
ESCALATE_BLOCKERUnrecoverable errorRequired
PHASE_COMPLETECurrent phase finishedNone
WORKFLOW_COMPLETEPresent final summaryNone

Context Passing & Next Agentτ

The orchestrator reads the handoff signal and constructs input for the next agent:

Context Passing & Next Agent
WHEN handoff_signal_received: IF orchestrator_action === "ACTIVATE_NEXT_AGENT": SET next_agent = agent_sequence[current_index + 1] SET next_prompt = { "phase": current_phase, "focus_points": next_agent.focus_points, "previous_findings": handoff_signal.handoff_context.key_findings, "critical_files": handoff_signal.handoff_context.critical_files } EXECUTE Task( subagent_type = next_agent.type, prompt = next_prompt )
  • Next agent receives previous findings directly
  • Critical files list tells agent where to look first
  • Focus points direct agent to specific tasks
  • Handoff context fields: phase_status, validation_gates_passed, critical_files, key_findings, blockers, next_agent_focus

Failure Handling & Propagationυ

When validation gates fail, the handoff includes failure context. Failures don't halt immediately — they propagate through documentation agents (positions 1, 2, 7, 8):

  • phase_status: incomplete — signals failure to next agent
  • blockers — specific issues preventing completion
  • issues_noted — context for resolution in subsequent phases
  • Document failure — write details to validation_results
  • Trace root cause — Exit Validator (position 7) analyzes execution
  • Create failure handoff — Completion Verifier (position 8) preserves context
  • Stopping immediately loses context — flowing failures through documentation agents preserves it

User Pause & Best Practicesφ

When human intervention is required:

User Pause & Best Practices
IF failure_severity === "BLOCKER": SET handoff_signal.orchestrator_action = "PAUSE_FOR_USER" SET handoff_signal.handoff_context.blockers = [ "Critical dependency missing", "Decision required: proceed with workaround or abort" ] SET handoff_signal.handoff_context.user_decision_required = true REPORT handoff_signal AWAIT user_decision INTO resolution
Always include artifacts_location in handoff
List critical_files with file:line references
Keep key_findings to 5-10 items maximum
Blockers should be specific and actionable
Signal completion only after validation gates pass
Include enough context for next agent to start immediately
Never signal WORKFLOW_COMPLETE without final summary
Use PAUSE_FOR_USER sparingly — only for true blockers

Orchestration Principles

Guidelines and invariants extracted from working orchestrations. These rules prevent common failures.

ALWAYS / NEVER Rulesχ

Invariants that must hold throughout orchestration. Define these explicitly in your workflow:

Document Rules

  • ALWAYS pre-create documents before Phase 0
  • ALWAYS edit documents in-place
  • ALWAYS read before write
  • NEVER create new document versions
  • NEVER use generic names (output.md, results.md)

Agent Rules

  • ALWAYS execute via EXECUTE Task tool
  • ALWAYS verify sequence pattern
  • ALWAYS append handoff_context
  • NEVER simulate agents in orchestrator
  • NEVER skip validation gates

Phase Rules

  • ALWAYS verify prerequisites first
  • ALWAYS write failures before handoff
  • ALWAYS create final_summary from last agent
  • NEVER proceed without completion verification

Policy Rules

  • Zero tech debt — no TODOs that persist
  • Zero fallback — no silent failures
  • Zero dual path — one way to do each thing

Agent Type Definitionsψ

Define agent types with full metadata. Note how verification types are reused at bookend positions (1 & 8, 2 & 7):

  • Full metadata objects enable runtime introspection of agent capabilities
  • positions array shows where each type appears in the sequence
  • responsibilities lists what each agent type handles
  • See Orchestration Fundamentals for the complete 8-agent sequence pattern

Semantic File Extensionsω

Documents use semantic extensions to indicate their purpose. This aims to provide explicit signals for document type identification:

Semantic File Extensions
FOR EACH document IN documents: VERIFY document.purpose !== "" VERIFY document.name NOT MATCHES /^(output|results|data)\./ VERIFY document MATCHES semantic_naming_convention
ExtensionPurposeExample
.agent-context.mdAgent-specific context, logs, handoff dataimplementation-log.agent-context.md
.audit-report.mdVerification results, compliance reportsvalidation-results.audit-report.md
.task-checklist.mdProgress tracking, workflow stateworkflow-state.task-checklist.md

Good Names

  • prerequisite-status.agent-context.md
  • architecture-decisions.audit-report.md
  • integration-points.task-checklist.md

Bad Names

  • output.md — too generic
  • results.md — no semantic meaning
  • data.json — unclear purpose

Dynamic Phase Delegation & ResumptionΑ

Orchestrations can check workflow state and skip completed phases. This enables resumption after interruption:

Phase Completion Check

  • Read workflow-state to find current position
  • Extract completed_phases array from state
  • Skip phases already marked complete
  • Verify prerequisites before executing any phase

Phase Workflow Objects

  • workflow_file — path to the phase's workflow definition
  • artifact_path — where phase outputs are stored
  • agent_count = 8 — each phase runs the full 8-agent sequence
  • prerequisite — what must complete before this phase runs

Resumption Capabilities

  • Resume from any phase after interruption
  • Prerequisite verification before phase start
  • Clear artifact locations per phase
  • Modular workflow files enable partial execution

Workflow Templates & InheritanceΒ

Orchestrations can be templated for reuse. Templates use parameter placeholders that get replaced during instantiation:

CategoryExamplesPurpose
Workflow Identity{{workflow_name}}, {{implementation_domain}}Names and identifiers
Context Paths{{config_file_path}}, {{checklist_phase_0_path}}File locations
Agent Configuration{{agent_type_1}}, {{agent_type_1_abbrev}}Agent types and abbreviations
Phase Definitions{{phase_0_title}}, {{phase_0_focus}}Phase metadata
Agent Actions{{phase_0_agent_1_verify_1}}Specific agent tasks

Array Parameters with Iteration

  • {{#EACH array}} — iterate over array items
  • {{this}} — current item value
  • {{#unless @last}},{{/unless}} — conditional comma
  • Provide arrays in the parameter set for dynamic lists

Document Inheritance

  • Single-phase workflows inherit documents from previous phases
  • Documents persist across phases — later phases read and edit earlier ones
  • Use previous_phase_artifact_name to reference prior artifacts

Phase Linking

  • prerequisite — what must complete first
  • next_phase — what follows this phase
  • next_workflow_path — path to next phase's workflow
  • Each phase defines its relationship to adjacent phases