Coordination Patterns
Open the first-run map, find the right receiver, or see one full handoff workflow — before you scroll.
Stay here when you need delegation patterns, advisory loops, escalation paths, and examples of how work moves from one agent to another.
Open the coordination route in the lane that matches your question
This page is broad because coordination questions come in different shapes. Pick the lane below and Atlas will carry you straight to the section that answers that version of the question best.
If you are unsure, start with the first message and first owner, then drop deeper only if the handoff still feels ambiguous.
I need the first message and first owner
Use the first-run map to match your situation, choose the first agent, and borrow the opening message shape without reading the whole route.
Best for new asks, unclear starting lanes, and moments where you need one confident opening move.
Stop after the first-run map once you know who should receive the first ask and what usually happens next.
Pick the lane, then the page
Atlas stays easier to scan when the route map reads like navigation first. Start with the lane that matches your question, then expand the full page-job model only when you need the deeper contract details.
Decision-and-handoff layer for how work gets routed between people, agents, and systems.
Change pace: Usually current for a while, but revisit when routes, ownership, or workflows shift.
Once the routing pattern is clear, use workflows to see the typical step-by-step shape.
Open WorkflowsEntry
Use these pages when you are still orienting and need the safest first click before you pick an owner or system.
Ownership
Use these pages when your real question is who should handle the work, how it moves, or which charter owns the surface.
Systems
Use these pages when you need the map, structure, services, and interfaces behind the network instead of the people or routing rules.
Operations
Use these pages when something feels broken, you need a concrete next check, or you need the live-status companion surface.
First-run coordination map
Clawdy routes user-facing work and can delegate. Scout is the right lane for autonomous project execution, research, and documentation cycles.
Start with Clawdy or Scout
Share the goal, the repo or project surface, and what “done” looks like.
Clawdy usually routes to the best-fit specialist. Scout reviews dirty state, syncs in, runs preflight, closes the freshness gate, and then ships the scoped work or names the blocker.
Atlas owns the audit and docs update. Grafton is the lifecycle steward that helps make sure the handoff is visible and gets closed out.
Route it to Atlas, often with Grafton context
Name the page or claim that looks stale, what changed, and the best evidence you have.
Atlas runs a bounded freshness gate, checks the affected page against current evidence, then either ships the correction or records why the claim was not actually drift.
Samwise runs intake and triage on Linear as parent-identity skills and owns delivery end to end. When a task needs full lifecycle ownership from intake to completion, Samwise is the right lane.
Start with Samwise
Share the work item, its priority context, and what done looks like.
Samwise triages the item against current WIP, confirms the execution path, then either owns delivery directly or routes to the best-fit execution agent.
Operational findings belong with the agent doing the work. Governance, scope, and “should we do this?” questions go to Atticus before implementation grows.
Share findings with the working agent, ask Atticus for policy
Include the proposed change, the reason for it, and the decision you need back.
The working agent can keep moving if the rules are already clear. If they are not, Atticus returns a ruling that unblocks the next implementation step.
Who to involve, at a glance
Talk to Clawdy when you need one concrete owner and next step.
The ask, the context, and who needs the answer.
Clawdy routes it or answers directly if no specialist is needed.
Talk to Scout when you need one concrete owner and next step.
The project surface, the reader or user problem, and the done signal.
Scout reviews dirty state, syncs in, runs preflight, checks the live backlog and freshness gate, then ships the scoped improvement or names the blocker.
Talk to Currybot when you need one concrete owner and next step.
The repo, PR, branch, or failing area that needs engineering attention.
Currybot reviews code, runs tooling, or ships the technical fix path.
Talk to Atticus when you need one concrete owner and next step.
The proposed action, why it matters, and the decision threshold.
Atticus rules, escalates, or narrows the safe path so execution can continue.
Talk to Meg when you need one concrete owner and next step.
The screen, the visual question, and the quality bar you need help evaluating.
Meg gives direction before build work or audits the shipped UI after it lands.
Talk to Grafton when you need one concrete owner and next step.
The Seed or work item, current gate, and where follow-up may be slipping.
Grafton records the handoff state and makes the next owner visible.
Talk to Samwise when you need one concrete owner and next step.
The work item, its priority context, and what done looks like.
Samwise runs intake and triage on Linear, then either owns delivery directly or routes to the right execution lane.
Talk to Dexter or Buzz when you need one concrete owner and next step.
The hypothesis, the audience or channel question, and what evidence you need back.
Dexter owns experiment validity and honest assessment. Buzz owns audience discovery, distribution experiments, and market-signal playbooks.
Concrete examples
Freshness Drift Handoff
1. Detect
Grafton sweeps or Watering Bucket reviews surface a likely Atlas drift item.
2. Handoff
The follow-up lands in Atlas project scaffolding so the work is visible and owned.
3. Audit
Atlas verifies the claim against current workspace and network evidence before changing docs.
4. Update
Atlas refreshes the affected pages, routes, or lifecycle notes with the corrected state.
5. Close the loop
Atlas leaves visible progress signals so later Grafton sweeps can confirm movement instead of guessing.
Why it matters: the system no longer depends on Atlas manually remembering that a drift reminder happened. The handoff is written down, the audit is attributable, and completion is visible to the next sweep.
Bounded freshness gate
Atlas does a quick, explicit freshness check at the start of every cycle — enough to catch real network drift without letting verification consume the whole session. If the check finds material changes, Atlas updates docs first. If it finds nothing new, the cycle immediately shifts into explanatory improvements for readers.
Graceful fallback
Sometimes the advisor path or bridge dependency is unavailable. That does not stop the cycle. Atlas closes the gate using local workspace evidence, records the failed check in the log, and still ships either a real freshness fix or a reader-visible improvement.
Delegation Pattern
Clawdy → Currybot
Why: Clawdy focuses on Jake's tasks and strategy. When code review or technical work is needed, it delegates to Currybot (the coding specialist).
Clawdy → Scout
Why: When Jake needs research, prototyping, or autonomous project work, Clawdy delegates to Scout. Scout works in cycles, building and iterating without constant supervision.
Advisory Loop
Scout
Doing the work
Advisor
Guidance & feedback
- Scout gets course correction without blocking Jake
- Advisor has read-only access (safe, focused)
- Multi-turn conversations enable iterative refinement
- Sessions maintain context across turns
Sub-Agent Hierarchy
Clawdy
Currybot
Scout
Atticus
Meg
sessions_send()bridge call <target>Governance Check Pattern
How the Governance Loop Works
Agent submits a proposal — e.g., "I want to deploy a new Vite config change that modifies port bindings." Sent via Bridge with context: action type, rationale, expected impact.
Atticus evaluates against established policies — existing decisions in QMD (the network's shared knowledge retrieval service), scope boundaries, and safety rules. Cross-references LC knowledge base for precedent.
Response is classified:
Decision logged to observability as service: "atticus", creating a full governance audit trail.
Clawdy checks
- • Infrastructure changes
- • Multi-agent task spawning
- • External integrations
- • Spending above thresholds
Scout checks
- • Major architectural changes
- • New service dependencies
- • Public-facing deployments
- • Scope expansions
Currybot checks
- • Engineering standard changes
- • Tooling decisions
- • CI/CD modifications
- • Security-relevant PRs
Meg checks
- • UI merges (visual gate)
- • New component patterns
- • Design token changes
- • Design system updates
Governance activity is auditable rather than summarized live here. A February 2026 capture counted 3 governance decisions since Feb 16, 2026, with Clawdy → Atticus the most frequent route (13 historical calls via Bridge) — treat those counts as a point-in-time snapshot, not a live total. Every decision is logged to observability as service: "atticus" and stays queryable via GET /events?service=atticus in the OpenObserve-backed telemetry stream. Live runtime truth starts at /system/observability.
Real-World Workflows
Workflow 1: PR Review Request
Workflow 2: Scout's Autonomous Cycle
Workflow 3: Meeting Notes Processing
Powered by the Atticus Ledger — autonomous pipeline, no manual trigger required.
How Agents Decide
Each agent has a defined scope. When a task falls outside that scope, delegate.
Scout consults advisor for direction. Multi-turn conversations enable iterative refinement.
All agents query QMD — the shared knowledge retrieval service — for context before making decisions. QMD provides semantic search across team notes, decisions, and project history.
Use submit mode for long-running tasks. Don't block when you don't need to.
Key Principles
Each agent excels at specific tasks. Delegate to leverage expertise.
Agents query knowledge bases and session history before acting.
Long tasks use submit/query pattern to avoid blocking.
Advisory loops enable course correction without human intervention.