Stay on the current district and jump straight to the street-level page you need.
These question-led rows give you the three route families with one “why this page” cue, so you can leave FAQ quickly without reading the whole library top to bottom.
Open Capabilities when the real question is which worker owns this kind of request, who to ask first, or whether you need Scout, Meg, Atticus, Grafton, Samwise, or the Labs pair (Dexter and Buzz).
Why this page: Why this page: it separates agents by role boundary, not by whichever one you happened to hear about last.
Open Workflows when you already know the people involved but need the operating path, handoff sequence, or closeout pattern for a real request.
Why this page: Why this page: it shows how work moves, so you do not mistake a worker for the process they participate in.
Open Infrastructure when your question is about ports, mirrors, gateways, shared services, or which surface is canonical versus preview-oriented.
Why this page: Why this page: it grounds the system map before you chase the wrong endpoint, especially around Bridge, Kokoro, and Meg's mirrored previews.
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.
Question-first shortcut when the reader starts with confusion instead of a route plan.
Change pace: Usually current for a while, but revisit when routes, ownership, or workflows shift.
Use the FAQ to sort the question, then move to the page that actually owns the answer.
Open CapabilitiesUse these pages when you are still orienting and need the safest first click before you pick an owner or system.
Use these pages when your real question is who should handle the work, how it moves, or which charter owns the surface.
Use these pages when you need the map, structure, services, and interfaces behind the network instead of the people or routing rules.
Use these pages when something feels broken, you need a concrete next check, or you need the live-status companion surface.
This October 6 re-audit keeps the FAQ's agent roster in sync with the rest of Atlas. The agent picker now includes Samwise (intake and delivery), Dexter (Labs leader), and Buzz (Labs distribution) alongside the existing six agents. Owner, Workflow, and System still route to Capabilities, Workflows, and Infrastructure; Grafton remains the lifecycle steward, Kokoro stays anchored to its internal 8787 TTS surface, Meg's preview-oriented Atlas and Watchtower mirrors remain on 18803 and 5181, and live-status questions still route to the OpenObserve-first observability lane. This pass also re-proved Scout's charter-cycle bullet against the live gateway-cron roster: Watchtower, Atlas, and Podcast Platform run every 4 hours, Forge runs twice daily, and the bullet no longer teaches a running 4-hour cycle for charters whose crons are not currently enabled.
The route rows above are the actual routing layer. They help you pick the right page, worker, or workflow without reading the entire FAQ top to bottom. Use the long-form sections below only when the short path did not settle your question and you need the reference answer library.
The full directory is still below, but this chooser gives you one current-focus recommendation first so you can jump straight to the right family.
If you are unsure, pick the lane that sounds most like your starting question, open that family, and only come back to the full directory if the answer still branches.
Use General Concepts when the blocker is not detail but orientation. It gives you the smallest shared model that makes the later answers readable.
Best for first-time readers, stale five-agent mental models, and “what is this network?” questions.
Stop after General Concepts once you understand the core terms and which surface explains versus operates the network.
The long-form library now lives behind one sticky local table of contents instead of another full wall of cards.
Use the sticky rail below to jump directly to the question family that matches your blocker.
The rail keeps the active family and its best related route visible while you move through the long answer stack.
Atlas should point you to the owning page, not trap you in every FAQ category in sequence.
If you only remember one thing: Atlas explains the network, while the network's live tools operate it. These quick comparisons help you tell documentation apart from monitoring, roles apart from operating units, shared memory apart from current status, and message routing apart from direct tool use.
Open Watchtower first. That is a live-state question about whether a cron fired, whether Scout is healthy, or whether alerts were raised.
Use Atlas afterward if you need the architectural explanation for how Scout cycles are supposed to work.
Open Watchtower observability →Atlas is the charter; Scout is the agent working that charter. The charter owns the ongoing body of work, while the agent carries out the cycle.
Use the projects view when the question is about ownership boundaries, then the agent page when you want the operator profile.
Open Projects ownership →Start with memory if you need the history: prior decisions, routing notes, and progress evidence. Start with live state if you need to know whether a job is currently running or blocked right now.
That is the quickest way to avoid mixing historical explanation with runtime truth.
Open Knowledge memory →If Scout needs Meg’s judgment, it bridges the question to Meg. If Scout already has the needed authority and tools, it acts directly with its own control-plane tools.
This is the cleanest example of bridge versus direct action: ownership and judgment route outward; execution with your own tools stays local.
Open Bridge patterns →The comparisons above tell you what each layer is for. This cheat sheet turns that into a practical next move when you are deciding which page, tool, or system to open first.
If you are new to Atlas, the most confusing part is usually not the network itself — it is choosing the right page depth. Start with the entry page that matches how oriented you already are, then use the deeper district pages once you know what kind of answer you need.
Start here if: I want the fastest possible overview before I click anywhere else.
Use this for the one-screen map: what Atlas covers, how the network is organized, and what main paths exist.
Start here if: I am new here and want a guided first pass instead of a reference page.
Use this when you want the start-here walkthrough: mental model first, then the right next pages by task.
Start here if: I already have a concrete question and want a quick answer or chooser.
Use this when your starting point is confusion: which tool, which agent, which page, or what a term means.
Start here if: I want the actual map of agents, systems, and relationships.
Use this when you are ready to move from orientation into the network structure itself.
Answers: How is the network designed, and why are the pieces shaped this way?
Use this when you want the big-picture structure, design tradeoffs, and core system boundaries.
Answers: Where does this run, and what services, ports, and deployment layers support it?
Use this when your question is about hosting, containers, shared services, environments, or access paths.
Answers: How do agents send work, questions, or context to one another?
Use this when you are tracing agent-to-agent communication, handoffs, sessions, or routing patterns.
Answers: How do agents decide who should do what, and how do advisory loops work?
Use this when the real question is operating pattern: delegation, advisory, ownership, or workflow shape.
Answers: Which agent can actually do this kind of work?
Use this when your question is about tool access, authority, model tier, or choosing the right worker.
Answers: Something feels broken — where do I start and what exact symptoms matter?
Use this when you need named failure modes, step-by-step checks, and practical fixes.
If your question is really "who owns this kind of work?", use this quick chooser before you dive into the longer FAQ items. Each card names the best first stop, the kind of request that fits, and where to read more.
Ask this when: Need a high-trust generalist with Jake-facing context?
Start here for cross-cutting questions, high-context assistance, or tasks that need full-access judgment and orchestration.
Ask this when: Need a builder to explore, implement, or ship bounded work?
Use Scout for autonomous cycles, repo changes, documentation improvement, and scoped delivery loops that end in concrete output.
Ask this when: Need a policy, approval, or governance decision?
Route here when the action has real-world impact, needs a proposal review, or depends on explicit decision framing instead of raw implementation.
Ask this when: Need design direction or a visual quality check?
Bring Meg in when the question is about look, feel, component consistency, screenshot review, or whether a UI matches the intended design language.
Ask this when: Need an idea tracked, promoted, or harvested into follow-up work?
Start with Grafton for Seeds, Work Items, stale initiative handling, or lifecycle questions about how work moves from idea to active ownership.
Ask this when: Need intake routing, triage, or end-to-end task ownership?
Use Samwise when a request needs routing into the right work item, a task is stuck in the queue, or you want autonomous delivery from plan through completion.
Ask this when: Need experiment design, validation, or honest assessment of an idea?
Dexter is the Labs leader who guides structured experiments so the founding team can test opportunities without pretending every idea deserves to become a product.
Ask this when: Need audience discovery, distribution design, or market-signal validation?
Buzz is Dexter's distribution counterpart — finds audiences, designs approved distribution experiments, and turns learnings into playbooks.
Ask this when: Need a team-facing helper for review, summaries, or LC coordination?
Use Currybot when the work is centered on Lambda Curry team support, communication loops, delegated reviews, or lightweight collaboration tasks.
A lot of first-time confusion comes from not knowing whether an agent will answer immediately, hand the work off, ask another agent, or disappear into an async cycle. This is the usual shape of work in the network.
The receiving agent decides whether this is an explanation, a direct tool action, a governance question, or a handoff to a better owner.
If the current agent already has the right tools and scope, it acts directly. If another agent is the better owner, it bridges the work over.
Some work adds an advisory loop or Atticus review before action. That changes understanding or approval, not necessarily ownership.
Short answers may happen inline. Larger changes often run as bounded cycles, delegated coding sessions, or asynchronous follow-up work.
The responsible agent posts the answer, summary, review, or shipped change back to the requesting surface so the handoff closes visibly.
Important work usually leaves memory, observability, PR, or progress-log evidence so the network can explain what happened later.
The easiest way to understand request flow is to compare similar asks that branch for different reasons: same network, different first move.
“Please improve the Atlas docs so a new teammate can tell Atlas from Watchtower.”
Why it branches: No other owner is required. The request needs Scout’s own charter workflow, not a cross-agent handoff.
“This new page works, but does it actually match the design system?”
Why it branches: Execution can stay local while judgment routes outward. Ownership of the build and ownership of the review are not always the same.
“Can we publish this externally or make a higher-impact system change?”
Why it branches: This is not just “how do we do it?” but “are we allowed to do it?” That changes the route before execution starts.
“Please update Atlas so a teammate can follow how work moves through the network.”
Why it branches: The first listener is not always the final executor. Intake and ownership can be different without the request getting lost.
If the routing cards above already answered where to go next, you can stop here. The rest of this page is the long-form answer bank for readers who want definitions, examples, edge cases, and troubleshooting detail without leaving the FAQ.
Each question now opens on demand, so you can scan the list first and expand only the answer family you actually need.
Expand this answer when you need the long-form detail.
The Saffron Network is Lambda Curry's multi-agent AI system built on GLM and OpenAI models. It consists of specialized agents working together to handle development, automation, research, and coordination tasks.
The network includes nine agents: Clawdy (Jake's personal assistant),Currybot (LC team assistant), Scout (autonomous explorer/builder),Atticus (decision & governance), Meg (design engineer & visual authority),Grafton (seed & initiative lifecycle manager), Samwise (autonomous delivery agent for triage and execution ownership),Dexter (Labs leader for experiment design and validation), and Buzz (Labs distribution and market-signal agent). These agents communicate via the Bridge protocol and share infrastructure like Recall (knowledge base), Observability (telemetry), and various supporting services.
Expand this answer when you need the long-form detail.
Specialization: Different agents use different models (GPT-5.4 for high-level reasoning, GLM-5.2 for routine tasks) and have different access levels, optimizing for cost and capability.
Context management: Each agent maintains its own conversation history and working memory, preventing context pollution and keeping token costs manageable.
Isolation: Bounded permissions reduce risk. Scout can't access production secrets; Currybot focuses on LC team tasks; Clawdy has full Jake-level access.
Expand this answer when you need the long-form detail.
They are Atlas's three reading depths. The labels tell you how zoomed in a page is, so you do not have to guess whether you are looking at a big-picture map, one subsystem, or a detailed implementation walkthrough.
Use Sky pages for orientation: what exists, how major pieces connect, and why the overall network is shaped this way. Start here when you need the shortest explanation before diving deeper.
Use District pages when you want one agent or one shared system explained in context — responsibilities, boundaries, important connections, and the main internal parts.
Use Street pages for the close-up view: policies, workflows, API details, troubleshooting steps, and other implementation-level specifics.
Fast rule: start at Sky when you are orienting, move to a District when you have picked a part of the network, and use a Street page when you need operational detail.
Expand this answer when you need the long-form detail.
Expand this answer when you need the long-form detail.
Atlas (this site) is the educational documentation of the agent network. It explains what agents exist, how they communicate, architecture decisions, and troubleshooting guides. Static content designed to help anyone understand the system.
Watchtower is the live observability dashboard. It shows real-time metrics, event streams, agent activity, and system health. Live monitoring for operational awareness.
If you are trying to understand the current charter map, keep your first stop simple: Atlas for the explained picture, Watchtower for live status. Older workflow examples may still mention Forge as a workspace-generation effort, but that is not the main day-to-day orientation surface readers should start with.
Fast rule: open Atlas when you need explanation, open Watchtower when you need current status, and open Projects when you want the current charter roster.
Think of it as: Atlas = "How does this work?" / Watchtower = "What's happening right now?" / Projects = "What exists right now?"
Expand this answer when you need the long-form detail.
Coordination explains how the network decides and routes work. Open that page when your question is about ownership, delegation, advisory loops, escalation, or why one agent consulted or handed off to another.
Workflows explains how a specific kind of work usually unfolds over time. Open that page when you want a step-by-step story such as a charter cycle, code review loop, reminder flow, or request lifecycle from intake to visible closeout.
In plain language: Coordination is the decision-and-routing layer, while Workflows is the execution storyline. One tells you who decides and hands off; the other tells you what sequence usually happens next.
Fast rule: if you are asking “who owns this or why did it move?”, start with Coordination. If you are asking “what are the usual steps from start to finish?”, start with Workflows.
Expand this answer when you need the long-form detail.
Every Atlas page carries a Validated · date chip beside a one-line proof. The date is the last day Scout re-checked that page against the live network — the charter registry, the real cron roster, and the page's own claims — not the day the page was written.
The re-check is the freshness gate that opens every Scout cycle: before new work ships, current reality is compared with what the map teaches. When a page's teaching changes, its date moves the same day — a Validated date never trails the content above it, and the proof line names what was actually verified, so “current” is auditable rather than asserted.
To catch up on the newest verified changes across the map, the home page keeps a current-snapshot strip, newest first. The refresh panel near the top of this page applies the same discipline to the FAQ itself.
Boundary: a Validated date proves the explanation is current, not that the system is healthy right now. For live runtime truth — what is running, what is failing — Watchtower is the lane; start at Observability & Monitoring.
Fast rule: “Validated · date” = how fresh this explanation is. Watchtower = what is happening right now. Projects = what exists right now.
Expand this answer when you need the long-form detail.
Clawdy is Jake's primary AI assistant, powered by GPT-6. Clawdy handles:
Clawdy has full access to Jake's workspace, secrets, and can execute arbitrary commands. Available via WhatsApp, Slack, and CLI.
Expand this answer when you need the long-form detail.
Scout is the autonomous explorer and builder, powered by GLM-5.3. Scout:
Scout works in bounded cycles: orient → work → log → report. Each cycle is 1-2 hours, with clear start/end and concrete deliverables. Scout has sandboxed access and cannot touch production systems.
Expand this answer when you need the long-form detail.
Clawdy (GPT-6) is Jake's primary assistant with full access and execution capabilities.
Clawdy Advisor (GLM-5.2) is a read-only management layer that Scout bridges to for guidance. The Advisor:
Think of the Advisor as a consultant: Scout comes with questions, gets feedback, then goes back to work. The Advisor doesn't do the work itself.
This is the same pattern as advisory vs delegation: advice changes the worker's understanding, while delegation changes who owns execution.
Expand this answer when you need the long-form detail.
Currybot is the LC team assistant (GLM-5.2, hosted on Railway), focused on:
Currybot receives delegated work from Clawdy (e.g., "review this PR") and posts results back. Available in LC team Slack channels and can interact with GitHub via CLI.
Expand this answer when you need the long-form detail.
Atticus is the decision & governance agent, added to the network in February 2026. Instead of baking policy rules into every agent's prompt, Atticus is a dedicated agent that other agents consult before taking significant actions.
When an agent wants to take an action that could have real-world impact, it sends a proposal to Atticus via Bridge:
Every Atticus decision is logged as an observability event, creating a full governance audit trail. This means you can always query what decisions were made, by whom, and why.
Why a separate agent? Policies change. With Atticus, you update governance rules in one place rather than patching every agent's system prompt. It also keeps individual agents focused on their core task rather than second-guessing every action.
Expand this answer when you need the long-form detail.
Meg is the design engineer and visual authority of the Saffron Network, added in February 2026. She's named for Meg Murry from A Wrinkle in Time — stubborn, principled, deeply technical.
Meg's core job: make sure UI built by coding agents actually looks right, and stays consistent as the network grows. She owns the visual layer end-to-end:
Why this matters: Coding agents can't see what they build. Meg closes that gap — not by giving agents eyes, but by building a structured review loop that catches visual drift before it ships.
Runs on port 18802. Model: GLM-5.2.
Expand this answer when you need the long-form detail.
Grafton is the seed and initiative lifecycle manager — the gardener of the Saffron Network. Grafton doesn't decide what to build; Grafton makes sure ideas that are ready get tracked, stale work gets flagged, and completed work gets harvested back into new opportunities.
The lifecycle has two stages:
When a Work Item finishes, Grafton runs a harvest loop: verify the result summary is filled, check if dormant Seeds are now unblocked, and create linked Draft Seeds from new opportunities the result reveals. Harvest plants the next crop.
Trust tier: Operator. Grafton can read/write Seeds and Work Items and send bridge messages, but cannot approve promotions, make strategic recommendations, or override sponsor decisions.
In other words: Grafton is an agent, while the lifecycle rules and ongoing work it manages belong to a charter-level system.
Expand this answer when you need the long-form detail.
Response depth depends on the kind of request you sent.
Fast rule: phrase it as a question → expect an answer. Phrase it as "please build, change, or ship" → expect a cycle. If you are not sure whether Scout is in a cycle or has already finished, check the progress log or Watchtower for the most recent activity.
Expand this answer when you need the long-form detail.
Three patterns work well for incomplete answers:
Expand this answer when you need the long-form detail.
The network has a clear escalation ladder. Work through it in order:
Expand this answer when you need the long-form detail.
Agents use the Bridge protocol for inter-agent communication. The current Bridge v1 wrapper is verb-first: use call for a bounded answer, add --detach when work should continue independently, then use watch or result to follow up. interject adds a focused turn to an existing session, cancel stops a stale or unsafe turn, and list recovers local turn history.
Example: when Scout needs Atticus's governance judgment, it can call Atticus for a bounded answer. If the work should continue independently, Scout detaches the call and later watches the turn or reads its result instead of treating the handoff as a synchronous-only exchange.
Bridge is for agent-to-agent routing. If an agent can solve something with its own tools or gateway directly, that is not a Bridge hop — that is direct control-plane work by the current agent.
Open Bridge Layer for the current route split, or Bridge Communication for the detailed transport patterns.
Expand this answer when you need the long-form detail.
Use Bridge when the work needs another agent's ownership, judgment, or authority. Use the current agent's direct control-plane tools when it already has the right access and the work stays inside its own lane.
Clawdy needs a PR review. It does not review code with its own local tools; it bridges to Currybot because Currybot owns that execution lane and returns the review.
Scout wants to look up prior context or schedule a reminder. It uses memory_search or cron directly because no other agent is needed to own that action.
Fast rule: if you are asking "who should own this?" or "whose judgment do I need?" bridge it. If you are asking "can I do this with the tools I already have?" use the control plane directly.
Expand this answer when you need the long-form detail.
Advisory loops are multi-turn conversations between Scout and Clawdy's Advisor. Scout uses these for:
Pattern: Scout completes a work cycle → bridges to Advisor with "Here's what I did, what's next?" → Advisor searches knowledge base and provides guidance → Scout continues with new direction.
Loops are kept to 3-5 turns maximum to avoid context drift.
Expand this answer when you need the long-form detail.
Delegation: One agent hands off a complete task to another agent who executes it independently.
Example: Clawdy → Currybot: "Review PR #123 and post feedback"
Advisory: One agent consults another for guidance but continues doing the work itself.
Example: Scout → Advisor: "I built feature X, should I add Y next or focus on Z?"
Delegation transfers responsibility; advisory transfers knowledge.
Expand this answer when you need the long-form detail.
No. Each agent has its own conversation history and working memory. Agents are isolated by default.
However, agents can share information explicitly via:
This isolation prevents context pollution and keeps token costs manageable.
Expand this answer when you need the long-form detail.
The entire network runs on Jake's Mac mini at his home office in Austin, TX. The Mac mini is connected to a Tailscale mesh VPN for secure remote access.
Deployment architecture:
Expand this answer when you need the long-form detail.
Currykit is Lambda Curry's infrastructure monorepo — shared services that power the agent network:
All agents use these services. They're maintained in the lambda-curry/saffron monorepo under packages/, published as @lambda-curry/currykit-* to GitHub Packages.
Expand this answer when you need the long-form detail.
Dev servers (like Atlas and Watchtower) run inside Scout's Docker container, and some are additionally mirrored through Meg's preview range. Key details:
0.0.0.0 (not localhost) to be reachable from outside the containerallowedHosts: true to accept Tailscale hostname requestsExample Vite config for any Scout sub-project:
host: '0.0.0.0', allowedHosts: trueExpand this answer when you need the long-form detail.
Secrets are managed via environment variables in docker-compose.yml:
Secrets are never committed to git. Jake manages the docker-compose.yml file on the host.
Agents have different secret access levels based on their role and isolation requirements.
Expand this answer when you need the long-form detail.
The Saffron Network uses Recall as its RAG search engine:
Example: Jake asks "What did we decide about caching?" → Clawdy searches Recall → finds meeting notes from 2 months ago → uses that context to answer accurately.
Expand this answer when you need the long-form detail.
QMD (Quantized Memory Database) is the vector database powering Recall. It's optimized for:
Recall (HTTP service, port 8790) wraps QMD and provides the search API used by agents.
Expand this answer when you need the long-form detail.
The RAG Sync service pulls content from:
Content is synced every 15 minutes. Agents always have access to the latest team knowledge.
Collections: lc-notes (meeting notes), lc-team (team info)
Expand this answer when you need the long-form detail.
Yes. Agents write to MEMORY.md and memory/*.md files in their workspace. These files are:
Pattern: Scout completes a cycle → appends summary to memory/progress-log.md → Recall indexes it → Clawdy can later search "What did Scout work on last week?"
That memory is excellent for what happened or what was decided; it is not a guarantee of what is true right now. For current runtime status, use live observability tools instead.
Expand this answer when you need the long-form detail.
Atlas now treats observability as a layered system instead of a single SQLite-first collector:
If the question is what is true right now, start with Watchtower or the observability district. Do not treat the old SQLite collector examples as the live source-of-truth model.
Best route: Observability
Expand this answer when you need the long-form detail.
Follow the 5-step debugging process:
docker logs <agent> for container outputFull guide: Troubleshooting
Expand this answer when you need the long-form detail.
All Currykit services automatically emit telemetry that Atlas now treats as OpenObserve-first live evidence:
Agents can also emit custom events (e.g., Scout logs cycle start/end).
Expand this answer when you need the long-form detail.
Atlas does not publish a single fixed retention promise for live telemetry anymore.
If retention matters operationally, verify the current Watchtower/OpenObserve configuration with the owning observability docs and operators instead of relying on a hard-coded FAQ number.
Expand this answer when you need the long-form detail.
Skills are specialized instruction sets that agents can load dynamically based on task type. Each skill is a directory containing:
SKILL.md — Instructions and context for the agentExample skills: coding-agent (Codex integration), github (gh CLI usage),weather (forecast API), session-logs (log analysis)
Skills are automatically discovered and matched to tasks. Agents read the relevant SKILL.md at runtime.
Expand this answer when you need the long-form detail.
Codex CLI is a coding agent (gpt-5.3-codex) that Scout delegates implementation work to. Workflow:
codex exec "prompt" in the project directorygit diff and commits if approvedThis keeps Scout focused on planning/coordination while Codex handles implementation details.
Expand this answer when you need the long-form detail.
AI rules are project-specific instructions for coding agents. Stored in ai-rules/ directories:
/app/ai-rules/ (apply to all projects globally)projects/atlas/ai-rules/ (specific to that project)Example rules: coding style, testing requirements, build verification, architecture constraints.
Codex CLI automatically discovers and includes relevant rules in its context before making changes.
Expand this answer when you need the long-form detail.
To create a new skill:
skills/my-skill/SKILL.md with clear instructions, examples, and constraintsSkills are automatically discovered based on their <description> tag in the skill registry. Agents scan available skills and load the most relevant one for each task.
For complex skills, use the skill-creator skill to help structure the new skill properly.
Expand this answer when you need the long-form detail.
Agents have different permission levels based on their role:
projects/ subdirectoriesExpand this answer when you need the long-form detail.
Atlas and Watchtower are still tailnet-first internal apps. The network now has a selective Tailscale Funnel ingress layer for services like Bridge, hooks, Oracle, Linear Agent, Samwise, and QMD, but those public paths do not make Atlas or Watchtower general-public sites.
http://main-mini:18797/ for Atlas and http://main-mini:5175/ for Watchtower)18803 and 5181Team access is managed at the network layer (Tailscale ACL + device auth), with optional app-level guards where needed.
This keeps Atlas discoverable for collaborators while avoiding public exposure.
Expand this answer when you need the long-form detail.
Yes, but access varies by agent:
All outbound requests are logged into the observability stream for audit trails.
Docker networking allows agents to reach host.docker.internal for services running on the Mac mini.
Expand this answer when you need the long-form detail.
The network is designed with isolation layers to limit blast radius:
Mitigation: Stop the container → review logs → rotate secrets → redeploy from known-good image
Current risk is low: agents run on a private Mac mini (not public cloud), with no external write access.
Expand this answer when you need the long-form detail.
The network uses a tiered model strategy to balance capability and cost:
Cost optimization: Use GLM-5.2 for routine work, GPT-5.4 for complex reasoning. Delegate coding to Codex to reduce token burn on the primary agents.
Expand this answer when you need the long-form detail.
Token usage is tracked in multiple layers:
/status command shows cumulative token usageWatchtower displays live token usage and cost projections.
Expand this answer when you need the long-form detail.
Several strategies reduce token costs:
memory_search to fetch only relevant snippets (not entire files)Scout checks Codex usage before heavy coding sessions to avoid hitting rate limits.
Expand this answer when you need the long-form detail.
The network runs on self-hosted hardware, so infrastructure costs are minimal:
No cloud hosting costs (AWS, GCP, etc.). Total infrastructure cost is effectively nothing beyond electricity.
The bulk of operating cost is API usage (GLM, OpenAI), not infrastructure.
Expand this answer when you need the long-form detail.
Trust the surface that matches the kind of truth you need. Atlas is the educational map — it explains what a system is, what it is supposed to do, and how it fits into the network. Watchtower is the live operational view — it shows what is happening right now.
Fast rule: when explanation and live status appear to conflict, treat Atlas as the model and Watchtower as the present-state check.
Expand this answer when you need the long-form detail.
docker ps | grep <agent> — Is it running?docker logs --tail 100 <agent> — Any errors?curl http://localhost:<port>/health — Is it reachable?Full guide: Troubleshooting
Expand this answer when you need the long-form detail.
docker ps)curl http://host.docker.internal:<port>/healthservice=bridge to see if call was attemptedCommon causes: Target agent hung on a long task, network partition, or timeout too short for complex operations.
Expand this answer when you need the long-form detail.
Atlas pages live at canonical “street” addresses organized by owner and system — for example /system/knowledge/network instead of the old short address /network. Short addresses from earlier versions of the map still work: twelve legacy short addresses are kept as part of the page map and server-redirect to their canonical street, so an old bookmark or a link from an older page still arrives at the right content.
If an address does not match any page at all, Atlas serves a real “Page Not Found” response — not a blank error and not a silent redirect to the home page. The not-found page is a small wayfinding surface in its own right: it points back to the Atlas home, the network map, and the capabilities directory, so a stale link is a signpost rather than a dead end.
Start again from: Network map · Capabilities directory
Expand this answer when you need the long-form detail.
Common causes:
lc-notes vs lc-team)Debug: Check Recall logs (docker logs recall), verify QMD has vectors (GET /health)
Expand this answer when you need the long-form detail.
Checklist:
allowedHosts: true in vite.config.tsdocker ps to verifycurl http://localhost:<port>/ — If this fails, it's a server config issue (not Tailscale)Expand this answer when you need the long-form detail.
Resources:
/app/docs or docs.openclaw.aiFor emergencies: Slack Jake directly or restart the relevant Docker container.