## The Six-Phase Pipeline
Every Robot execution runs through up to six phases in sequence:
| Phase | Name | Trigger | Description |
|-------|------|---------|-------------|
| P0 | Inspiration | Clock only | Generate a daily briefing from context, schedule, and resources |
| P1 | Goals | All | Translate the trigger input (or P0 report) into concrete objectives |
| P2 | Tasks | All | Break each goal into an ordered list of executable tasks |
| P3 | Run | All | Execute each task using an Agent, MCP tool, or Yao Process |
| P4 | Delivery | All | Summarise results and push them to external systems |
| P5 | Learning | All | Extract patterns and save them to the Robot's private KB |
**Clock trigger** starts at P0. **Human** and **Event** triggers skip P0 and start at P1 — the trigger input itself serves as the goal context.
```
Clock ──► P0 ──► P1 ──► P2 ──► P3 ──► P4 ──► P5
Human ──────────► P1 ──► P2 ──► P3 ──► P4 ──► P5
Event ──────────► P1 ──► P2 ──► P3 ──► P4 ──► P5
```
## Phase-Agent Slots
Each phase is served by a dedicated Agent. Yao resolves the Agent ID through a two-level priority chain:
1. **Per-robot override** — `resources.phases` in `robot_config`
2. **Global default** — `uses` section in `agent.yml`
```yaml
# agent.yml — global defaults for all robots
uses:
inspiration: myns/inspiration-agent
goals: myns/goals-agent
tasks: myns/tasks-agent
delivery: myns/delivery-agent
learning: myns/learning-agent
host: myns/host-agent # cross-phase, handles human interaction
validation: myns/validation-agent # task output validation
```
> **Note:** P3 (Run) has no agent slot — it is the built-in task dispatcher. P0–P2, P4–P5, Host, and Validation are configurable.
Override for a specific robot in its `robot_config`:
```json
{
"resources": {
"phases": {
"inspiration": "myns/special-inspiration",
"delivery": "myns/slack-delivery"
}
}
}
```
Only the phases you override are changed; the rest keep the global defaults.
## The Execution Object
All phases share a single `Execution` object that accumulates state as it flows through the pipeline:
```
Execution
├── TriggerType ("clock" | "human" | "event")
├── Input (trigger payload)
├── Inspiration (P0 output)
├── Goals (P1 output)
├── Tasks[] (P2 output)
├── Results[] (P3 output — one per task)
├── Delivery (P4 output)
└── Learning[] (P5 output)
```
Each phase reads from earlier fields and writes to its own field. The Delivery Agent (P4) has access to the complete execution history, so it can make informed summaries even when individual tasks failed.
## Concurrency and Quota
A single Robot can run multiple executions concurrently. Quota controls are set in `robot_config`:
```json
{
"quota": {
"max": 2,
"queue": 10,
"priority": 5
}
}
```
| Field | Default | Description |
|-------|---------|-------------|
| `max` | `2` | Maximum concurrent executions |
| `queue` | `10` | Maximum queued executions |
| `priority` | `5` | Scheduling priority (1 = lowest, 10 = highest) |
If a new trigger arrives when `max` is reached, it is queued (up to `queue`). Triggers beyond the queue limit are rejected.
## Executor Modes
The Robot supports three executor modes:
| Mode | Description |
|------|-------------|
| `standard` | Production mode — real Agent calls, full persistence |
| `dryrun` | Simulation mode — no LLM calls, useful for testing phase wiring |
| `sandbox` | Container-isolated mode (reserved for future CLI Agent integration) |
The mode is set per-execution at trigger time. Dry-run is especially useful when configuring a new Robot to verify the phase routing before enabling live LLM calls.
