Orchestration

Crewship’s orchestration system manages multi-agent missions through the MissionEngine (internal/orchestrator/mission.go). It handles task scheduling, dependency resolution, failure recovery, and cross-crew coordination.

“Orchestration” here means the engine subsystem in internal/orchestrator/, not a navigable page. After the Plan/Run/Build/System IA refactor, the user-facing surfaces are split: Routines for reusable recipes, Issues for the work-item tracker, Inbox for your actionable feed, and Activity for the live trace canvas. The legacy /orchestration route now soft-redirects to /activity.

Mission Lifecycle

PLANNING --> IN_PROGRESS --> REVIEW --> COMPLETED
                |              |
                v              v
             FAILED        CANCELLED

A mission progresses through these states:

PLANNING — Mission created, tasks defined (or waiting for Lead to plan)
IN_PROGRESS — Tasks being scheduled and executed
REVIEW — All tasks finished (none failed). The mission enters review before final completion, allowing humans to inspect results
COMPLETED — Mission accepted after review
FAILED — A task failed and could not recover, or deadlock/timeout detected
CANCELLED — Manually stopped by user or system

The REVIEW state is inserted between IN_PROGRESS and COMPLETED. When all tasks reach a terminal state (COMPLETED, FAILED, or SKIPPED) and none have failed, the mission transitions to REVIEW rather than directly to COMPLETED. If any task failed, the mission transitions to FAILED instead.

The Mission Engine

The MissionEngine is the central orchestrator. Its behaviour is governed by a handful of fixed parameters:

Parameter	Value	Source
Polling interval	3 seconds	`time.NewTicker(3 * time.Second)`
Circuit breaker threshold	3 consecutive failures	`circuitBreakerThreshold = 3`
Mission timeout	2 hours	`missionTimeoutDefault = 2 * time.Hour`
Max result summary	8,000 chars	`maxResultSummaryLen = 8000`
Max brief total	32,000 bytes	`maxBriefTotalLen = 32000`
Per-dependency output truncation	4,000 chars	`maxDepOutputLen = 4000`

Mission Loop

The runMissionLoop function runs as a goroutine for each active mission. Every 3 seconds it:

Check mission status (still IN_PROGRESS?)
Lead planning phase: if 0 tasks, dispatch Lead to create plan
Schedule ready tasks (dependencies met, status PENDING)
Check mission completion (all tasks done?)
Detect deadlocks (all tasks BLOCKED with no progress)

Restart Durability

Mission loops are in-memory goroutines, but missions survive server restarts. At boot — right after orphaned-run recovery — the server scans the database for missions still in IN_PROGRESS and re-attaches an orchestration loop to each one. Tasks the previous process never dispatched are picked up on the next tick, and BLOCKED tasks whose dependencies already completed are self-healed back to PENDING. No operator action is needed after a restart or crash; the 2-hour mission timeout restarts from the moment of re-attach.

Scaling / Concurrency

Separate from per-mission task scheduling above, the orchestrator bounds how many agent-run exec fan-outs (RunAgent) may be in flight across the whole server at once, via a semaphore (runSem in internal/orchestrator/orchestrator.go). Each run fans out roughly a dozen container execs — sidecar start, mkdir/manifest/credential setup, and the long-lived agent CLI exec — all against a single Docker daemon, so unbounded concurrency here is the fastest path to daemon saturation or host OOM.

Setting	Default	Configured via
Max concurrent agent runs	8	`orchestrator.max_concurrent_runs` in `config.yml`, or the `CREWSHIP_MAX_CONCURRENT_RUNS` env var

Precedence when both are set: CREWSHIP_MAX_CONCURRENT_RUNS (env) wins over orchestrator.max_concurrent_runs (config file), which wins over the built-in default of 8.

orchestrator:
  max_concurrent_runs: 16

export CREWSHIP_MAX_CONCURRENT_RUNS=16

Tuning guidance:

Raising the cap increases parallelism, but the practical ceiling is whichever comes first: host RAM (each run’s container + agent CLI + MCP processes) or your LLM provider’s own rate limits.
Idle agents and provisioned-but-inactive crews cost nothing against this cap — it only limits agent runs actively executing at a given moment.
The semaphore is sized once when the orchestrator is constructed at server startup. Changing CREWSHIP_MAX_CONCURRENT_RUNS or orchestrator.max_concurrent_runs requires a server restart to take effect.
There is no hard upper limit, but a value above 128 is treated as suspicious: the server emits a loud WARN at startup (orchestrator max concurrent runs is far above the default) so an accidental extra zero — an intended 80 typed as 800, or a stray 1000000 — is caught before it saturates the daemon. The value is still honored; the warning is advisory only.

Task States

PENDING --> RUNNING --> COMPLETED
   ^          |             |
   |          v             v
   +------ FAILED    AWAITING_APPROVAL ---> COMPLETED
              |                         |
              v                         v
           BLOCKED                    FAILED (rejected)
           SKIPPED

State	Description
`PENDING`	Ready to be scheduled
`RUNNING`	Currently being executed by an agent
`COMPLETED`	Finished successfully
`FAILED`	Execution failed
`BLOCKED`	Waiting for dependent tasks to complete
`AWAITING_APPROVAL`	Task completed but held for human review before proceeding
`SKIPPED`	Task was intentionally skipped (counts as terminal, does not cause mission failure)

SKIPPED tasks are treated as terminal alongside COMPLETED and FAILED when checking mission completion. A skipped task does not block downstream dependencies and does not cause mission failure.

Token Budget Calculation

The orchestrator allocates system prompt space using a token budget system defined in internal/tokenutil:

Constant	Value	Description
`MaxSystemPromptTokens`	32,000	Total conservative budget for the system prompt
`ConversationBudgetPct`	60%	Percentage of remaining budget for conversation history
`MemoryBudgetPct`	40%	Percentage of remaining budget for agent memory

The allocation works as follows:

Estimate base system prompt tokens
remaining = MaxSystemPromptTokens - baseTokens (min 2,000)
convTokenBudget  = remaining * 60 / 100
memTokenBudget   = remaining * 40 / 100
Inject conversation history (up to convTokenBudget)
Inject memory context (up to memTokenBudget)

After conversation and memory injection, the orchestrator appends additional context blocks in order: lead crew context (for LEAD agents), peer communication context (for crew AGENT members).

Mission Brief Construction

When an agent is dispatched for a mission task, the buildMissionBrief function constructs a rich context prompt with five sections. The total brief is capped at 32KB (maxBriefTotalLen); if exceeded, the brief is truncated with a note.

1. IMPORTANT Preamble

Only included when dependency outputs exist. Instructs the agent not to ask clarifying questions:

IMPORTANT: You are part of a multi-agent mission pipeline.
Previous tasks have already been completed and their outputs are provided below.
DO NOT ask for additional information or clarification -- everything you need is in this prompt.
Use the dependency outputs below as your input and execute your task immediately.

2. [MISSION]

Mission title, goal, and a DAG overview listing all tasks with their status markers:

+ COMPLETED
> IN_PROGRESS
x FAILED
PENDING/BLOCKED

3. [INPUT FROM PREVIOUS TASKS]

Outputs from completed dependency tasks, injected before the assignment so agents read context first. When a task produced a structured handoff block, only the handoff summary, artifacts, and confidence are included (more concise). Otherwise the full result summary is included, truncated to 4,000 characters per dependency.

4. [YOUR ASSIGNMENT]

The specific task title, description, and iteration number (if this is a retry).

5. [OUTPUT FORMAT]

Structured handoff instructions requiring the agent to produce a ---HANDOFF--- block with summary, confidence, and artifacts.

Lead Planning Phase

When a mission starts with 0 tasks, the engine dispatches the Lead agent to create a plan. The Lead uses its crew context to understand available agents and creates tasks via the sidecar /mission/create endpoint.

Mission (0 tasks)
    |
    v
Lead agent dispatched (LEAD role, with sidecar)
    |
    v
Lead creates tasks via curl to localhost:9119/mission/create
    |
    v
Mission engine detects new tasks -> begins scheduling

LeadPlanning Flag

The DispatchRequest includes a LeadPlanning flag that tells the API layer to dispatch the agent as a LEAD with sidecar access. This is essential because Lead agents need access to the mission management API (/mission/create, /mission/{id}) to define tasks, while regular AGENT tasks skip the sidecar for security.

TOCTOU Prevention

A time-of-check-to-time-of-use race is prevented by inserting a sentinel missionState into the active map before loading the mission from the database. The planningDispatched flag on the mission state prevents re-dispatching the Lead if it is still working. This flag is only set to true after dispatchLeadPlanning succeeds.

Scaling Rules

The Lead agent follows complexity-based scaling rules injected via the system prompt:

Complexity	Agents	Tool Calls	Duration	Tokens
SIMPLE	1	3-10	~5 min	~10K
MEDIUM	1-2	10-15	~15 min	~50K
COMPLEX	2-4	15+	~30 min	~100K

Workflow Templates

Four built-in workflow templates are defined in internal/orchestrator/workflow.go:

Sequential
Parallel
Dev-Test Loop
Pipeline

Tasks execute one after another in order.

step-1 --> step-2 --> step-3

All tasks run simultaneously, then results are aggregated by the Lead.

task-a --|
task-b --|---> aggregate (Lead)
task-c --|

Developer writes code, tester reviews. On failure, loops back to developer (max 3 iterations). This is the Ralph Loop pattern.

develop <---(failure)--- test
   |                      ^
   +----(success)---------+
(max 3 iterations each)

Sequential preparation, parallel work streams, final aggregation.

prepare --> work-a --|
        --> work-b --|---> finalize (Lead)

The Ralph Loop Pattern

The LoopController (internal/orchestrator/loop.go) manages task retry logic:

When a task fails and has max_iterations > 1, the controller increments the iteration counter and resets the task to PENDING
For loop-back patterns (dev-test-loop), when a downstream task fails, the upstream task is reset to restart the cycle
Previous failure context from the progress log is injected so the agent learns from mistakes

The ShouldRetry method checks if a failed task has remaining iterations. If yes, it resets the task:

Status back to PENDING
Iteration counter incremented
All execution fields cleared (assignment_id, result_summary, error_message, started_at, completed_at, duration_ms)

The RetryLoopBack method handles the upstream reset pattern: when a downstream task (e.g., “test”) fails, it checks the dependency chain. If an upstream task (e.g., “develop”) has remaining iterations, that task is reset to PENDING and the failed downstream task is set to BLOCKED — ready to run again once the upstream completes.

Tasks without max_iterations set (or max_iterations <= 1) are never retried. A failed task without retry configuration causes the mission to fail.

Task Approval Gate

The checkApprovalGate function determines whether a completed task should be held for human review. The gate evaluates three inputs:

Explicit flag — if approval_required = 1 on the task, it is always held
Confidence threshold — the agent’s self-reported confidence from the handoff block
Escalation config — per-crew configuration with tiered thresholds

Escalation Config

Each crew can define an escalation_config JSON object with three thresholds:

{
  "auto_approve_threshold": 0.9,
  "notify_threshold": 0.7,
  "require_approval_below": 0.5
}

Threshold	Behavior
`auto_approve_threshold`	Confidence at or above this value: auto-approve (task goes to COMPLETED)
`notify_threshold`	Confidence below this value: send a `confidence.low` WebSocket notification
`require_approval_below`	Confidence below this value: hold the task in AWAITING_APPROVAL

The evaluation order is:

If confidence >= auto_approve_threshold, return COMPLETED
If approval_required is explicitly set, return AWAITING_APPROVAL
If no config or no confidence data, return COMPLETED
If confidence < require_approval_below, return AWAITING_APPROVAL
If confidence < notify_threshold, send notification but return COMPLETED

Approving or Rejecting Tasks

The ApproveTask method transitions a task from AWAITING_APPROVAL:

Approved: task moves to COMPLETED, dependent BLOCKED tasks are unblocked
Rejected: task moves to FAILED, all downstream dependent tasks are recursively failed with reason “upstream task rejected”

Approval requires a userID for the audit trail. The approval status (APPROVED or REJECTED), approver, timestamp, and evaluation notes are persisted on the task.

When a task is held in AWAITING_APPROVAL, the mission engine sends an approval.required WebSocket message to the workspace so dashboards can display a badge or notification.

Circular Dependency Detection

The ValidateDAG method checks all mission tasks for:

References to nonexistent task IDs — any depends_on entry that does not match an existing task ID causes validation to fail
Circular dependencies — detected using Kahn’s algorithm (topological sort)

DAG validation runs before the mission loop begins scheduling, preventing tasks from being dispatched into an unresolvable dependency graph. The error message reports the number of tasks involved in the cycle: "circular dependency detected: N tasks involved in cycle".

Kahn's Algorithm internals

The implementation builds an adjacency list and computes in-degrees for each task:

Initialize in-degree for each task based on depends_on count
Enqueue all tasks with in-degree 0 (no dependencies)
For each dequeued task, decrement in-degree of tasks that depend on it
If a task's in-degree reaches 0, enqueue it
If visited count != total tasks, a cycle exists

Deadlock Detection

The mission engine detects deadlocks when all remaining tasks are BLOCKED with no task currently IN_PROGRESS, PENDING, or AWAITING_APPROVAL. The detection logic:

If any task is PENDING, IN_PROGRESS, or AWAITING_APPROVAL — not deadlocked (progress is still possible)
COMPLETED, SKIPPED, and FAILED tasks are terminal — they cannot contribute to progress
If all non-terminal tasks are BLOCKED — deadlock confirmed

When a deadlock is detected:

The mission is marked as FAILED
A mission_deadlock progress event is emitted
All AWAITING_APPROVAL tasks are failed with “mission timed out”

Circuit Breaker

The circuit breaker tracks consecutive failures per agent. After 3 consecutive failures (circuitBreakerThreshold), the agent is considered unhealthy and tasks are not dispatched to it.

CooldownManager

The CooldownManager (internal/orchestrator/failover.go) handles rate limit detection and credential cooldown. When an agent run fails due to a rate limit, the associated credential is placed in a cooldown period to avoid hammering the provider.

Rate Limit Detection

The IsRateLimitError function checks stderr output against known patterns. Detection requires exit code 1 and a case-insensitive match against any of these patterns.

Rate-limit patterns

Pattern	Example
`rate limit`	”Rate limit exceeded”
`rate_limit`	”rate_limit_error”
`429`	”HTTP 429”
`too many requests`	”Too many requests”
`quota exceeded`	”Quota exceeded for model”
`insufficient_quota`	”insufficient_quota”
`billing_hard_limit`	”billing_hard_limit_reached”

Cooldown Behavior

When a rate limit is detected:

MarkCooldown(credentialID, 5*time.Minute) places the credential in a 5-minute cooldown
IsInCooldown(credentialID) returns true during this period, causing the orchestrator to skip that credential
ClearExpired() removes stale entries

The cooldown is per-credential, not per-agent. If an agent has multiple credentials assigned, only the rate-limited credential is paused — the orchestrator can fall back to an alternate credential.

Progress Logging

The ProgressWriter (internal/orchestrator/progress.go) appends structured JSONL events to a per-mission progress file at data/crews/{crewSlug}/missions/{traceID}/progress.jsonl.

Event Types

Each event includes a UTC timestamp.

Progress event reference

Event	Fields	When
`mission_started`	`mission_id`	Mission loop begins
`task_started`	`task_id`, `agent`, `title`	Task dispatched to agent
`task_COMPLETED`	`task_id`, `agent`, `summary`	Task finished successfully
`task_FAILED`	`task_id`, `agent`, `error`	Task execution failed
`task_retry`	`task_id`, `agent`	LoopController resets a task for retry
`mission_deadlock`	`mission_id`	All tasks BLOCKED with no progress
`mission_REVIEW`	`mission_id`	All tasks terminal, mission entering review
`mission_timeout`	`mission_id`	Mission exceeded 2-hour timeout

The progress file is append-only and agents can read it during retry iterations to understand what happened in previous attempts (the Ralph Loop “external state” pattern). The BuildProgressContext method formats the JSONL into a human-readable text block suitable for injection into an agent’s system prompt.

Structured Handoff

Agents produce structured handoff data at the end of tasks:

---HANDOFF---
summary: Created the REST API endpoints for user management
confidence: high
artifacts: internal/api/users.go, internal/api/users_test.go
---END HANDOFF---

The parseHandoff function extracts this structure from agent output. Both summary and confidence are required for a valid handoff — partial blocks are treated as unparsed. The confidence value (low, medium, high) feeds into the approval gate. When parsed as a float (via escalation config), it determines whether the task auto-approves or requires human review.

Cross-Crew Work

Crews are isolated by default. A crew link (Settings → Crew links, or crewship crew connect) is what lets one hand work to another; it is created by a workspace admin and enforced server-side on every dispatch, message and shared-file access. A lead assigns across a link by naming the crew:

curl -s -X POST http://localhost:9119/assign \
  -H "Authorization: Bearer $CREWSHIP_AGENT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"crew":"ops","target":"morgan","task":"page the on-call"}'

Omit crew for your own crew. Results come back from /results/{assignment_id} either way, and curl -s http://localhost:9119/connections lists the links as they stand right now. A lead’s system prompt already names the crews it can reach and who is in them, so it does not have to discover them. Peer queries (/query) are crew-local by design and cannot cross a link. Mission tasks can likewise reference agents in linked crews; the system routes each assignment to the right crew container.

A one-way link points one way. If Ops → Engineering is unidirectional, Ops may dispatch into Engineering and not the reverse — the reverse attempt is refused with “crews are not connected”.

Crew-to-crew handoff with critique exchange (e.g. backend crew hands a draft to a testing crew for review) is on the v0.2 roadmap.

Delegation limits

Any agent in a crew can hand work to a crew member with /assign — leads and crew members alike. What bounds it is not who you are, it is how deep the chain already is and how much that run already has out.

Setting	Default	Meaning
`delegation.max_depth`	`2`	Delegation hops from the originating run. A lead’s own dispatch is depth 1; what that sub-agent dispatches is depth 2. `0` switches delegation off entirely.
`delegation.max_fanout`	`8`	Sub-tasks one run may have out. For a delegated run that is every task it dispatched; for a lead working a chat it is the ones still in flight, so a long conversation is not capped on lifetime output.

Both are instance settings, read live — a change applies to the next dispatch, not the next restart:

crewship instance settings set delegation.max_depth 3
crewship instance settings get delegation.max_fanout

Past either limit, /assign answers 403 with a message that names the limit and the setting, and no assignment row is written. The agent sees it and is told (in its system prompt) to do the work itself or report back rather than retry.

The numbers multiply. One originating run at the defaults bounds a tree at 8 + 64 dispatches, not 16. Raise max_depth with that in mind — and note that actual concurrency stays far lower, because each crew’s slot budget (max_concurrent_agents, or memory ÷ runtime.agent_min_memory_mb) queues everything past it.

How the depth is known. It is not sent by the agent, and it cannot be. The sidecar resolves who is calling from that agent’s own bearer token, and crewshipd reads the depth off the assignment row that agent is currently executing (assignments.depth, with parent_assignment_id recording the chain). A depth field in the request body is read by nothing.

/query’s own depth >= 2 check is a different, weaker thing: it reads the depth from the request body. Do not model new controls on it.

Mission limits

The delegation limits above bound /assign. They do not bound a mission: the mission engine dispatches its task list through its own path, so a mission an agent authored is not a delegation hop and is not counted as one. Missions are bounded by their own two numbers, on the agent door (POST /mission/create):

Setting	Default	Meaning
`mission.max_tasks`	`16`	Tasks one agent-created mission may carry. `0` allows task-less missions only — every task then has to arrive through `/assign`, where the delegation limits apply.
`mission.max_active_per_crew`	`6`	Agent-created missions one crew may have in a non-terminal state at once. `0` switches agent-driven mission creation off.

Both are instance settings, read live — a change applies to the next call:

crewship instance settings set mission.max_tasks 24
crewship instance settings get mission.max_active_per_crew

Past either limit, /mission/create answers 403 with a body naming the setting an operator would change, and no mission or task row is written.

The second number is the one that bounds recursion. A mission created with no tasks makes the engine run its lead as a planning turn, and a planning turn can create another mission — so a per-mission task cap on its own would bound nothing. The crew’s live-mission budget does, because every mission an agent creates lands in the crew its token is bound to.

Missions you create through the dashboard or the JWT API are not capped and are not counted against the agents’ budget: an operator planning work is making a decision, not fanning out unattended.

Sidecar API for Orchestration

Any crew agent can reach the sidecar proxy at localhost:9119; the orchestration routes are:

Endpoint	Method	Description
`/assign`	POST	Assign a task to a crew member (subject to the delegation limits above)
`/results/{id}`	GET	Poll for assignment result
`/query`	POST	Ask a crew member a quick question
`/standup`	GET	Get crew standup summary
`/escalate`	POST	Escalate an issue to humans
`/mission/create`	POST	Create a multi-task mission (subject to the mission limits above)
`/mission/{id}`	GET	Check mission status
`/mission/{id}/start`	POST	Start a mission
`/mission/templates`	GET	List available workflow templates

Sidecar API for the issue board

Agents are participants on the issue board, not just reporters. Every verb below runs on the same sidecar proxy and is authenticated the same way (bearer token on file descriptor 3 — never on a command line), the GETs included.

Endpoint	Method	Description
`/issue/create`	POST	Open a new issue, authored by the calling agent
`/issues`	GET	Search / list the board (`q`, `status`, `assignee_id`, `limit`, `offset`)
`/issue/{identifier}`	GET	Read one issue
`/issue/{identifier}`	PATCH	Update status, priority, assignee, labels, estimate, due date
`/issue/{identifier}/comment`	POST	Comment on the issue, recorded as the calling agent
`/issue/{identifier}/link`	POST	Relate two issues, or make one a sub-issue of another
`/issue/{identifier}/attachments`	GET	List the files attached to the issue (metadata only)
`/issue/{identifier}/attachments/{id}`	GET	Read one attachment — text arrives fenced, everything else base64
`/issue/{identifier}/attachments`	POST	Attach a file the agent produced (`filename` + `content_base64`, max 6 MiB)

Identifiers are the human-readable ones (ENG-42), not row ids.

Updating an issue

Send only the fields you are changing — a PATCH carrying just a status does not blank the assignee. Status changes must follow the board’s workflow; an illegal jump comes back 400 naming the transition it refused.

curl -s -X PATCH http://localhost:9119/issue/ENG-42 \
  -H "Content-Type: application/json" \
  -K /dev/fd/3 --data @- 3<<AUTH <<'JSON'
header = "Authorization: Bearer $CREWSHIP_AGENT_TOKEN"
AUTH
{"status":"IN_PROGRESS","estimate":3,"due_date":"2026-09-01"}
JSON

Splitting an issue into sub-issues

Decomposition is the reason the link verb exists: a large issue is broken into pieces, each piece becomes a child issue, and each child can then be assigned its own agent.

POST /issue/create once per piece.
POST /issue/{child}/link with {"target_identifier":"<parent>","relation_type":"sub_issue_of"}.
PATCH /issue/{child} with the assignee for that piece.

relation_type is one of blocks, blocked_by, relates_to, duplicate_of or sub_issue_of. blocked_by is stored as the inverse blocks link, so the board never holds two shapes of the same relationship.

What an agent cannot do here

These are enforced on the server, not by convention — an agent that tries gets a 403 or a 400, and retrying will not help:

Author as someone else. A crew shares one container and one sidecar, so an agent_id in the request body is ignored; the author is always the agent whose bearer token made the call.
Change another crew’s issues. The workspace and crew come from the sidecar’s own token binding, not from the request, and every verb is gated on the issue named in the path. The single exception is the link target: a relation may point at another crew’s issue in the same workspace, because it does not modify that issue. sub_issue_of writes parent_issue_id on the path issue, so it is gated like any other mutation.
Rewrite the issue itself. title and description are not updatable through these verbs, and neither are project_id, milestone_id, routine_id or sort_order. Agents report progress; they do not rewrite the brief a human wrote.
Delete anything. There is no delete verb on this surface.

Issue titles, descriptions and comments an agent reads back arrive wrapped in an <untrusted …> block. Anyone who can file an issue chooses those bytes, so they are handed to the model as data rather than as instructions — the same fence the orchestrator uses for webhook payloads and mission comments. See Lookout.

What’s Next

Agent memory — persistent agent memory across sessions
Scheduling — cron-based automated agent runs

​Orchestration

​Mission Lifecycle

​The Mission Engine

​Mission Loop

​Restart Durability

​Scaling / Concurrency

​Task States

​Token Budget Calculation

​Mission Brief Construction

​1. IMPORTANT Preamble

​2. [MISSION]

​3. [INPUT FROM PREVIOUS TASKS]

​4. [YOUR ASSIGNMENT]

​5. [OUTPUT FORMAT]

​Lead Planning Phase

​LeadPlanning Flag

​TOCTOU Prevention

​Scaling Rules

​Workflow Templates

​The Ralph Loop Pattern

​Task Approval Gate

​Escalation Config

​Approving or Rejecting Tasks

​Circular Dependency Detection

​Deadlock Detection

​Circuit Breaker

​CooldownManager

​Rate Limit Detection

​Cooldown Behavior

​Progress Logging

​Event Types

​Structured Handoff

​Cross-Crew Work

​Delegation limits

​Mission limits

​Sidecar API for Orchestration

​Sidecar API for the issue board

​Updating an issue

​Splitting an issue into sub-issues

​What an agent cannot do here

​What’s Next

Orchestration

Mission Lifecycle

The Mission Engine

Mission Loop

Restart Durability

Scaling / Concurrency

Task States

Token Budget Calculation

Mission Brief Construction

1. IMPORTANT Preamble

2. [MISSION]

3. [INPUT FROM PREVIOUS TASKS]

4. [YOUR ASSIGNMENT]

5. [OUTPUT FORMAT]

Lead Planning Phase

LeadPlanning Flag

TOCTOU Prevention

Scaling Rules

Workflow Templates

The Ralph Loop Pattern

Task Approval Gate

Escalation Config

Approving or Rejecting Tasks

Circular Dependency Detection

Deadlock Detection

Circuit Breaker

CooldownManager

Rate Limit Detection

Cooldown Behavior

Progress Logging

Event Types

Structured Handoff

Cross-Crew Work

Delegation limits

Mission limits

Sidecar API for Orchestration

Sidecar API for the issue board

Updating an issue

Splitting an issue into sub-issues

What an agent cannot do here

What’s Next