Skip to content
🧭
Street-level entry

🎓 Getting Started with Agents

Use this page to pick the first owner, the first ask, and the next Atlas page fast.
Validated · Oct 6, 2026The October 6 closing-wayfinding pass converged the route's exits onto the shared Continue band; agent counts still track the nine-agent network.
Opening payoff

Jump to the first owner, first move, five-minute path, or playbook before you read the full route.

First ownerFirst moveFive-minute pathPlaybook

Stop after the first four jumps once the next page and the first request feel obvious.

Switch to Capabilities for owner selection, Network for the map, or Workflows when you need a concrete handoff trace instead of a first ask.

Top-level route contracts

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.

Current lane: Entry
Getting StartedHere

Guided first-five-minutes path for readers who want a tour instead of a reference page.

Start hereCurrent pageSteady

Change pace: Usually current for a while, but revisit when routes, ownership, or workflows shift.

Best next move
Then graduate to Home or FAQ

After the tour, switch to the full map or a question-first route.

Open Home
Start here

Entry

Use these pages when you are still orienting and need the safest first click before you pick an owner or system.

3 pages
Home

Shortest whole-site overview before you choose a deeper page.

Steady
Getting StartedHere

Guided first-five-minutes path for readers who want a tour instead of a reference page.

Steady
FAQ

Question-first shortcut when the reader starts with confusion instead of a route plan.

Steady
Who owns the work

Ownership

Use these pages when your real question is who should handle the work, how it moves, or which charter owns the surface.

4 pages
Projects & Charters

Charter and surface ownership map for the network.

Steady
Capabilities

Worker-selection page for choosing the right agent and understanding execution boundaries.

Steady
Coordination

Decision-and-handoff layer for how work gets routed between people, agents, and systems.

Steady
Workflows

Execution-story page for how real work usually unfolds from intake to visible closeout.

Steady
How the network is built

Systems

Use these pages when you need the map, structure, services, and interfaces behind the network instead of the people or routing rules.

5 pages
Network Topology

Whole-network reference map of agents, systems, and relationships.

High-change
Architecture

Rationale layer for why the network is shaped this way and what tradeoffs drove it.

Stable reference
Bridge

Communication-system page for how agents ask, hand off, and consult one another.

Steady
Infrastructure

Platform-surface page for where the network runs and which services or access layers support it.

High-change
API Reference

Interface reference for endpoints, payloads, and package-level service details.

Steady
What to do when it hurts

Operations

Use these pages when something feels broken, you need a concrete next check, or you need the live-status companion surface.

2 pages
Troubleshooting

Symptom-first page for named failures, first checks, and practical fixes.

High-change
Watchtower Guide

Operational companion page for when the question is about live health and current status rather than static explanation.

High-change
First contact matrix

If you are not sure who to ask first, start here

The fastest way to get unstuck is to ask the right person first. Use this matrix when your real question is who should take the next move and what kind of reply you should expect back.
Best first agent · Clawdy
I need orientation before I ask for work

Best first stop when your question is broad and you need help finding the right page, agent, or next move.

First contact
Read Network first
What happens next

Expect a quick answer, one useful next page, and a handoff only if a specialist is clearly a better fit.

Good first phrasing

“I am new to the Saffron Network. What should I understand first, and which Atlas page should I read next?”

Best first agent · Scout
I found confusing or stale docs and want them fixed

Scout owns Atlas improvement cycles and is the right first stop for documentation clarity, freshness, and examples.

First contact
Open the docs playbook
What happens next

Expect Scout to clarify scope, update the docs, run checks, and close the loop with what changed.

Good first phrasing

“The Getting Started page still leaves me unsure when to ask Scout versus Currybot. Please tighten that section and add one concrete example.”

Best first agent · Currybot
I need a repo change, PR help, or code review

Currybot is the strongest first stop for GitHub work, implementation review, and code-focused follow-through.

First contact
See agent capabilities
What happens next

Expect direct repo work or review feedback. If the request changes product direction, policy, or ownership, another agent may get pulled in.

Good first phrasing

“Review PR #234 and tell me the biggest risk, what passed, and the one fix you would make first.”

Best first agent · Meg
I need a design opinion or UI quality check

Meg is the design authority for visual decisions, component patterns, and design-system fit.

First contact
Open Meg’s guide
What happens next

Expect judgment on layout, consistency, and UX quality, often with concrete design corrections or approval to proceed.

Good first phrasing

“I changed this screen. Can you audit the layout and tell me what feels off before we ship it?”

Best first agent · Atticus
I need approval, a ruling, or a scope decision

Atticus handles governance questions, policy boundaries, and decisions that should not be guessed locally.

First contact
See Atticus decision patterns
What happens next

Expect a clear yes, no, or escalation path, plus the policy reason behind it when that matters.

Good first phrasing

“This change touches architecture and operating policy. Does it fit the current rules, or should it be escalated?”

Start here selector

Choose your goal, then follow one clear next move

If Atlas feels wide at first, use this shortcut. Pick what you want to do, the kind of help you need, and how much context you want before acting.

1. What are you trying to do first?
2. What do you need most right now?
3. How deep do you want to go before acting?

Sky shows the whole map; District narrows to an owner; Street stays here for the exact request.

Current first move

Start with the Ask a Question playbook

Best when you need orientation first, not a build. You will get a fast answer, one useful next page, and a clear follow-up question.

Who to ask

Scout or Clawdy

Default depth

Street

Best when

Use this when you want a fast answer, one next page, and a low-risk first request before you ask for implementation work.

You can stop after

Stop once you have the first answer, one onward page, and a follow-up question you can actually send.

Starter phrasing

“What changed in Atlas this week, and which page should I read next if I am trying to understand how work moves?”

Open the question playbookJump to the matching playbook

Recommendation path: Getting Started first, then Start with the Ask a Question playbook.

Start here

Your First Five Minutes

You just got access to the network. Here is the exact sequence of clicks and reads that will get you from zero to oriented, using real paths and real questions.

1

Open the Network Map — see what exists

The Network page shows every agent and service as a connected graph. Don't try to memorize it — just notice that there are nine agents: a core seven (Clawdy, Scout, Currybot, Atticus, Meg, Grafton, Samwise) plus Dexter and Buzz in the Labs lane, and a handful of shared services (Recall, Bridge, Observability). The connections tell you who talks to whom.

You'll know it worked when: you can point to Clawdy on the graph and say “that's Jake's front door,” and to Atticus and say “that's the policy check before big actions.”
2

Pick one agent that matches your job — use the Capabilities page

You don't need all nine agents. You need one that matches what you're trying to do right now. Open Capabilities, find the “how to ask” card for that agent, and read the example phrasing. That single pattern is worth more than memorizing every agent's full profile.

Example: if you need a code change, find the Scout card and note the phrasing pattern — “In the [repo], add [change] so that [reason].” That template works every time.
3

Read one worked workflow — the Real Scout Cycle below

Scroll down to the A Real Scout Cycle, Start to Finish section on this page. It shows exactly what happens when an agent runs a cycle: cron fires, the freshness gate runs, Atlas chooses the right next slice, and the closeout lands in the project update stream. Understanding that one loop unlocks most of what you'll see in the network.

Why this one: Scout cycles are the most common activity in the network. If you understand one cycle, you understand how most work actually moves.
4

Make your first request — keep it small

The fastest way to learn is to ask for something real. Start with a question, not a build task — questions get inline answers in seconds, which gives you a feel for how agents respond before you try a multi-step workflow.

Starter requests that work well
  • →
    For Scout: “What changed in the last Atlas cycle, and which page should I read next?”— tests the docs+context loop with the primary assistant
  • →
    For Currybot: “Are there any open PRs on saffron-atlas that need review?”— tests the GitHub integration
  • →
    For Samwise: “What task are you driving right now, and what is blocked?”— tests the delivery-status loop
5

Bookmark FAQ and Troubleshooting for later

You don't need to read them cover-to-cover now. But when something feels confusing later — “which agent handles this?”, “why did my request route to someone else?”, “the dev server won't load” — those two pages have named answers with specific fixes. Knowing they exist is enough for now.

After five minutes you should be able to: name two agents and what they're for, phrase a basic request, and know where to look when something goes wrong. Everything else on Atlas is deeper detail you can reach from here when you need it.
First-task playbooks

Pick the first move that matches your intent

If you're staring at the network and wondering what to do first, use one of these three playbooks. They are intentionally small, concrete, and written the way a first successful request usually sounds.

❓

Ask a question

When to use it

Use this when you need orientation, status context, or a pointer to the right page before asking for work.

Who to ask

Scout for project and docs context, or Clawdy when you want the network's main front door.

Exact request
“What changed in Atlas this week, and which page should I read next if I'm trying to understand how work moves?”
Good response looks like

A short answer that names the relevant page, summarizes the latest change in plain language, and gives you one clear next click.

Next move if it needs follow-up

Ask one narrower question immediately, like “Show me the workflow that proves that,” or “Which agent owns that step?”

📝

Ship a documentation fix

When to use it

Use this when a page is confusing, outdated, missing an example, or leaves a first-time reader stuck.

Who to ask

Scout, because Scout owns most doc and product-page improvement loops.

Exact request
“In saffron-atlas, update the Getting Started page so a first-time reader can tell when to ask Scout versus Currybot. Add one concrete example and keep the tone plain-language.”
Good response looks like

A reply that names the file or page being changed, restates the user-facing outcome, and later comes back with the exact improvement shipped.

Next move if it needs follow-up

If the change touches structure or meaning, ask for the diff in plain English: “What did you change, and what should I re-read now?”

💻

Request a code change

When to use it

Use this when you need a real implementation change, not just an explanation, copy tweak, or routing question.

Who to ask

Scout for product and repo work, with Atticus pulled in if the change crosses architecture or policy lines.

Exact request
“In the Atlas repo, add a clearer empty state to search results so users know which routes to try next. Keep the current visual style and tell me what changed when you're done.”
Good response looks like

A scoped plan followed by an implementation update that names the affected area, the visible behavior change, and whether it was validated.

Next move if it needs follow-up

If the ask turns out to be larger than expected, narrow it on the spot: “Ship the smallest useful version first, then tell me what should come next.”

Pattern to remember: give the outcome, the place, and the constraint. For example: “In this repo, make this change, and keep this part intact.” That structure works across questions, docs work, and code requests.
Orientation checkpoint

You are oriented. Leave onboarding now.

If you can name who to ask, phrase one concrete request, and pick your next route, you are done with onboarding for now. Start real work and come back only when you need deeper reference.

Fast self-check
  • Can you pick the first agent for your current ask?
  • Can you write a one-sentence first request with outcome + place + constraint?
  • Can you choose the next Atlas page without guessing?
Open Network mapOpen CapabilitiesOpen WorkflowsStay for deep reference
Optional deep reference

Everything below is reference, not the newcomer path

Use these sections when you need background, edge cases, or operating details. Most first-time readers should skip this on day one.

Background
What agents are

Use this when the basic mental model is still fuzzy and you need the plain-language definition before anything else.

Reference only
Open agent model
Communication
How to talk to agents

Open this when the blocker is request phrasing, iteration style, or how much context to include.

Reference only
Open request phrasing
Ownership
Agent directory

Jump here when you need the broader cast and not just the first owner for today’s ask.

Reference only
Open agent directory
Handoffs
Common workflows

Use this when you want the reusable handoff shapes instead of a single task-specific answer.

Reference only
Open workflow patterns
Worked example
A real Scout cycle

Best deep-reference stop when you want one concrete example that proves how autonomous work actually moves.

Reference only
Open Scout cycle
Operating tips
Best practices

Open this when you already know the path but want the operating habits that prevent bad asks and wasted loops.

Reference only
Open best practices
Recovery
Troubleshooting communication

Jump here when the ask went sideways and you need recovery moves, not more orientation.

Reference only
Open communication recovery
Advanced
Advanced patterns

Use this only after the basics feel predictable and you need deeper multi-agent or higher-judgment patterns.

Reference only
Open advanced patterns

What Are Agents?

Agents are autonomous AI assistants that can help you with a wide range of tasks — from writing code and reviewing PRs to managing infrastructure and answering questions about your projects.

Unlike traditional tools where you execute specific commands, agents understand context, plan multi-step workflows, and collaborate with other agents to get work done.

Mindset Shift

  • →From: "I need to run specific commands in the right order"
  • →To: "I need this outcome — agents figure out how to achieve it"

How to Talk to Agents

Clear Requests

The best requests have three parts: what you want, why you need it, and any constraints or preferences.

❌ Vague Request

"Make the app faster"

✅ Clear Request

"The homepage takes 3 seconds to load. Can you profile the React components and identify what's causing the slowdown? I need load time under 1 second."

Provide Context

Agents work better when they know what you're trying to accomplish:

  • What project are you working on?
  • What have you already tried?
  • Are there any constraints? (time, budget, compatibility)
  • What's the bigger goal behind this task?

Examples Matter

When describing visual changes, data formats, or expected behavior — show examples:

"Format dates like this throughout the app:"

❌ 2026-02-15T17:07:29Z

✅ Feb 15, 2026 at 5:07 PM

Ownership

Working with the current core agents

Atlas onboarding treats the seven-agent core as the default mental model within a nine-agent network. Use this directory when you need the broader cast, not just the first owner for today's ask.
Front door
Clawdy — broad questions and first routing

Start with Clawdy when the question is still broad and you need help finding the right agent, page, or next move before asking for deeper work.

Open Clawdy district
Builder
Scout — product, docs, and charter work

Use Scout for the five registry product charters — Atlas, Watchtower, Forge, Anvil, and Podcast Platform — plus product-facing implementation and freshness work that needs a durable artifact and a closed loop.

Open Scout district
Repo helper
Currybot — GitHub work, reviews, and code follow-through

Use Currybot when the task is anchored in a repo, PR, diff, or code-focused review path and you want the strongest first stop for GitHub-heavy work.

Open Currybot district
Governance
Atticus — rulings, policy, and scope decisions

Route architectural approvals, policy boundaries, or human-judgment questions through Atticus when the answer should not be guessed locally.

Open Atticus district
Design authority
Meg — design direction and UI quality

Use Meg for layout judgment, design-system alignment, component consistency, and pre-ship audits on major visual work.

Open Meg district
Lifecycle steward
Grafton — autonomous pipeline upkeep

Grafton is part of the default map now: it keeps the Seed and stewardship loops healthy, but it is usually something you understand, not something you ask directly.

Open Grafton district
Delivery operator
Samwise — intake, execution, and reporting lanes

Bring in Samwise when the missing answer is task flow, project delivery state, or the work-routing lane between planning and execution.

Open Samwise district
Labs-facing routes

Start with the core directory above for most newcomer asks. Widen here when the question is specifically about turning an idea into an experiment or finding its audience.

Labs
Dexter — experiment design and assessment

Widen to Dexter when an idea needs a bounded experiment, explicit kill criteria, and an honest continue, pause, or sunset decision.

Open Dexter district
Labs
Buzz — distribution and market signals

Widen to Buzz when an experiment needs audience discovery, message variants, and an approval-aware path to distribution.

Open Buzz district

Understanding Agent Tiers

Not all agents have the same autonomy scope. The network uses three tiers, and the current core-agent map routes most newcomer requests through them this way.

🔵

Domain

Front-line builders, helpers, and delivery owners. Route substantial policy or scope decisions through Atticus before shipping.

ClawdyScoutCurrybotMegSamwise
🟢

Operator

Pipeline stewards with high autonomy for bounded bookkeeping tasks. No decisions — only pipeline mechanics within strict scope.

Grafton
🟡

Governance

Policy authority and institutional memory. The only tier that can approve or reject proposals from other agents.

Atticus

Tier assignment reflects the type of work, not importance — all three tiers are necessary and complementary. See the full Trust Tiers breakdown →

Common Workflows

Asking for Code Changes

What you say: "In the Atlas project (saffron-atlas repo), refresh the troubleshooting page's top freshness proof so the shared trust packet makes the latest route update easier to scan."

What actually happens
1. Scout reads app/routes/troubleshooting.tsx and confirms the route already uses the shared FreshnessProof wrapper for its trust surface
2. Delegates the smallest proof-copy or layout adjustment to Codex with a precise prompt instead of inventing a new badge pattern
3. Runs bun run typecheck and bun run lint to verify
4. Commits with feat: refresh troubleshooting freshness proof
5. Syncs the durable repo change, then closes the loop with verification notes and any needed GitHub or Linear follow-through instead of relying on a Slack-only receipt

Time: ~30 minutes for a small trust-surface refresh like this. The durable artifact is the verified repo change plus the closing note, not a chat update alone.

Checking the latest Atlas cycle outcome

What you say: "Clawdy, what did Atlas ship most recently, and is the project currently blocked?"

What actually happens
1. Clawdy checks the latest Scout-authored Atlas Linear Project Update first, because every healthy charter cycle closes there
2. If the summary needs confirmation, Clawdy cross-checks the current Atlas issues or Watchtower health signals
3. Clawdy summarizes what shipped, what remains open, and whether the next move is clear or blocked
4. If the project update is missing, that itself is a signal: Clawdy points you to the failure path or the charter files instead of inventing status

Time: Seconds to a minute. This is a question, not a build task, so expect a direct answer with a source of truth behind it.

Scheduling a Reminder

What you say: "Remind me at 10 AM Monday to review whether Atlas needs a new route for individual agent detail pages — it's been on the backlog."

What actually happens
1. Agent creates a one-shot cron job with { kind: "at", at: "2026-04-07T10:00:00-05:00" } and your reminder text
2. Confirms the job was created with its ID and scheduled time
3. At 10 AM CT Monday, the gateway fires the event — you see the reminder in your chat surface
4. The job auto-deletes after firing (one-shot by default)

Pitfall: If you forget tz: "America/Chicago", the reminder fires at 10 AM UTC (5 AM CT). Always specify timezone.

Reviewing PRs with Currybot

What you say: "Currybot, review PR #24 in saffron-atlas (adds example requests to the Capabilities page). Focus on whether the examples are accurate and not misleading for a first-time reader."

What actually happens
1. Currybot runs gh pr diff 24 --repo lambda-curry/saffron-atlas to get the changes
2. Reads the changed Capabilities route, checks each agent's example against its real access scope and tool list
3. Posts a review on GitHub with specific line-level feedback or approval
4. If changes are needed, follows up after you push a new commit

Tip: The more specific your review criteria, the better the result. "Focus on accuracy for first-time readers" works better than "take a look."

Asking for Something That Needs Governance Approval

What you say: "Add a page to Atlas that shows cost data for all API calls across the network, broken down by agent."

What actually happens
1. Scout recognizes this involves exposing cost data — a governance boundary, not a routine content change
2. Scout sends a proposal to Atticus via Bridge: "Add cost data page to Atlas. Contains per-agent API spend. Public-safe audit needed."
3. Atticus evaluates against the public-safe policy and returns needs-human — dollar amounts need Jake sign-off
4. Atticus notifies Jake in #atticus-digest with the proposal and recommendation
5. Only after Jake approves does Scout implement — and even then, the page uses abstracted cost tiers, not raw dollar amounts

Why this extra step: Not every request is a direct code change. Anything involving costs, public-facing data, or cross-agent scope goes through Atticus first. The governance loop protects the network from shipping things that need human judgment.

Worked example

A Real Scout Cycle, Start to Finish

The most common behind-the-scenes activity in the network is a Scout charter cycle. Here is exactly what happens when Scout runs an Atlas cycle — the same pattern applies to Watchtower and Forge.

1

Cron fires, session starts

The gateway’s cron scheduler fires the Atlas cycle job (runs every 4 hours). A new isolated session starts. Scout checks the Atlas Linear project for live backlog first, then reads SCRATCHPAD.md, ROADMAP.md, and BLOCKERS.md from the charter workspace to orient.

2

Freshness gate — local evidence closes first

Scout checks the current Atlas surfaces, route content, and known source-of-truth files for drift first. A bounded consult can still help, but the cycle does not depend on a separate Advisor loop to decide whether the map is current. If a consult times out, Scout closes the gate on local evidence and keeps moving.

3

Decide: fix drift, or improve content?

If the freshness gate found material changes (new agent, new service, port change), Scout updates the affected pages first. If the gate closes clean, Scout pulls the top unblocked Atlas backlog issue in Linear. Only when that backlog is empty does Scout fall through to the roadmap improvement queue. Standing by is not a valid outcome. Every cycle ships something.

4

Delegate, verify, and make it durable

For code changes, Scout delegates to Codex CLI with a precise prompt. After Codex finishes, Scout runs bun run typecheck and bun run lint to verify. Then the cycle commits and syncs the change so the artifact is durable. If there is an open PR lane, Scout reconciles it; if not, the proof can simply be the shipped main-branch change plus verification evidence.

5

Close the visibility loop

Scout rewrites SCRATCHPAD.md with the current state, syncs out, and posts one Scout-authored Linear Project Update for Atlas with explicit health. Slack is failure-only now: it appears only if the cycle cannot land that Linear closeout.

What this looks like from the outside

If you watch the Atlas Linear project, you see one project update with explicit health per healthy cycle. If you check the repo, you see the durable code or content change that update links to. If you check Watchtower, you see the cron fire event and session activity. You only need Slack if the cycle failed before that project update could land.

Best Practices

✅ Do

  • →Be specific about constraints (time, budget, compatibility)
  • →Ask follow-up questions to refine unclear responses
  • →Share context about what you've already tried
  • →Let agents suggest better approaches — they might know shortcuts
  • →Check the latest project update if you're waiting on a Scout cycle outcome
  • →Verify changes in git diff before asking agents to commit

❌ Don't

  • →Assume agents have context from previous conversations (provide it)
  • →Ask multiple unrelated questions in one message (break them up)
  • →Expect instant results for complex tasks (agents need time to think)
  • →Skip verification — always check agent work before deploying
  • →Micromanage steps — describe the goal, let agents plan the path
  • →Forget to mention blockers — agents can't read your mind

Understanding Responses

Agents think through problems step-by-step and may ask clarifying questions. This isn't a bug — it's how they ensure they understand your request correctly.

What to Expect

  • 1.
    Confirmation questions: "Just to clarify, you want this change to apply to both mobile and desktop views?"
  • 2.
    Progress updates: "Reading the existing code... Planning changes... Delegating to Codex... Verifying build..."
  • 3.
    Blockers: "I can't access the GitHub API without credentials. Can you add GITHUB_TOKEN to my environment?"
  • 4.
    Suggestions: "I noticed the data is already available in the /events endpoint. Would that work instead of adding a new endpoint?"

Tip: If an agent's response seems off-track, don't hesitate to redirect: "Actually, I meant..." Agents adapt quickly to clarifications.

Troubleshooting Communication

"The agent didn't understand my request"

Try these refinements:

  • Break complex requests into smaller steps
  • Provide a concrete example of the desired outcome
  • Reference specific files or functions: "In app/routes/home.tsx..."
  • Clarify scope: "Only change the desktop layout, not mobile"

"The agent keeps asking questions"

This usually means your initial request was ambiguous. Agents prefer to confirm assumptions rather than make incorrect changes. Answer the questions or rephrase your request with more detail.

"The agent said it's blocked"

Common blockers include missing credentials, file permissions, or external dependencies. Check the agent's error message — it usually explains what's needed. If you can't resolve it, ask Clawdy or Jake for help.

"The agent made changes I didn't expect"

Always review git diff before committing. If the changes aren't right, explain what went wrong: "These changes look good, but I also need..." or "Actually, I wanted..."

"Scout hasn't posted an update in a while"

Scout runs on scheduled cron cycles — it doesn't post between cycles. If you expect an update and haven't seen one:

  • Check Watchtower first — look for recent cron run events for the charter (Atlas, Watchtower, Podcast Platform, and Forge run enabled cycles; Anvil's cron is recorded disabled)
  • Check the latest Atlas Linear Project Update next — every healthy Scout cycle writes one under the Scout identity
  • If the cron hasn't fired at all, check the OpenClaw cron list for the charter job and verify it's still enabled
  • If the cron fired but the project update is missing, treat that as a failure path and check for the failure alarm in #saffron-updates or inspect the charter files directly

"A consult timed out or the bridge didn't answer"

Atlas no longer depends on a permanent Advisor loop for normal closeout. If a bounded consult or bridge call does not respond in time, the cycle should note that and proceed on local evidence whenever the decision is still safe to make.

If timeouts are happening repeatedly across multiple cycles, check Watchtower for persistent connectivity or health issues. Occasional timeouts are normal and do not require intervention by themselves.

Advanced Patterns

Multi-Agent Workflows

Some tasks involve multiple agents working together:

Example: "Clawdy, have Currybot review PR #42 and then update the Watchtower docs to reflect the new API changes."

Flow: You → Clawdy → Currybot (PR review) → Scout (docs update) → Clawdy (summary) → You

Long-Running Tasks

For tasks that take hours or days, use Scout's project cycles or delegate to sub-agents:

  • Scout runs recurring charter cycles for Atlas, Watchtower, Podcast Platform, and Forge — Anvil's cycle is recorded disabled — plus direct product work when needed
  • Each healthy cycle closes with a Linear Project Update on the owning project
  • Slack is failure-only for charter cycles: expect it only when the cycle could not land the Linear closeout
  • Check status through Watchtower or the latest project update instead of waiting for an ad hoc chat summary

Scheduled Work (Cron)

Set up recurring tasks with cron jobs:

One-time: "Remind me at 2 PM to review the dashboard"

Recurring: "Every Monday at 9 AM, check for GitHub PRs that need review"

Complex: "Daily at midnight, run cost analysis and write the summary to the correct reporting surface"

Agents create cron jobs in your gateway config. View active jobs withopenclaw cron list

Bridge Communication

Agents can talk to each other via the Bridge:

  • Scout consults Atticus before adding new routes, major sections, or architectural concepts
  • Clawdy can route a GitHub-heavy ask to Currybot or a UI-quality ask to Meg
  • Keep bridge sessions short (3-5 turns) — they're for specific questions, not long conversations

Pick an agent based on your task, write a clear request, and see what happens — the best way to learn is by doing.

Continue from Onboarding

Network Topology

See the whole system — agents, gateways, and services — and how a request travels between them before you send your first one.

Open Network Topology
Agent Capabilities

Open the operating limits, tools, and action scope for the node you are about to talk to.

Open Agent Capabilities
Example Workflows

See real end-to-end scenarios that put the agents and handoff patterns you just met to work.

Open Example Workflows
Architecture & ADRs

Step up a level for the why, tradeoffs, and operating principles behind the platform shape.

Open Architecture & ADRs