Architecture Decisions
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.
Rationale layer for why the network is shaped this way and what tradeoffs drove it.
Change pace: Changes slowly. The model matters more than day-to-day churn on these pages.
After the rationale is clear, switch to the system page or route owner that applies it in practice.
Open InfrastructureEntry
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.
Use this page to answer why the network is shaped this way
Go straight to the decisions and ADR layer
This lane is the shortest path from βI see the current systemβ to βwhich decisions created it?β It keeps the ADR layer foregrounded instead of making you scroll through history first.
- Best for
- Best for rationale audits, implementation follow-ups, and readers who need named decisions more than broad philosophy.
- Jump target
- Key decisions
- Stop after
- Stop after the relevant ADRs once you can point to the decision that explains the current shape; the history and philosophy sections are optional depth.
Core Design Principles
Agent Autonomy
Each agent is a full OpenClaw gateway with independent state, tools, and memory. No shared runtime. Agents coordinate through explicit messaging, not shared state.
Why: Isolation prevents cascading failures. One agent crashing doesnβt affect others. Clear boundaries make debugging and reasoning easier.
Explicit Over Implicit
All agent-to-agent communication goes through the Bridge. No hidden channels. All coordination patterns are documented and observable.
Why: Makes the system understandable and debuggable. You can trace every interaction through observability events.
Delegation Over Monoliths
Complex tasks are broken into sub-tasks handled by specialized agents or tools (Codex for code, Recall for search, advisor for planning).
Why: Right tool for the job. Smaller, focused contexts perform better than one giant agent trying to do everything.
Observe Everything
Every service automatically emits telemetry into the OpenObserve-backed stream, with Watchtower layering operator-facing expected-state context on top.
Why: You canβt improve what you canβt measure. Observability is built-in, not bolted-on.
Agent Trust Tiers
Not all agents operate at the same autonomy level. The Saffron Network uses three tiers to define how much unsupervised action each agent class is permitted. Tier assignment reflects the type of work, not importance β all tiers are necessary.
Domain
Task specialists that build, design, advise, and automate within their domain. They act on instructions and their own backlog, but significant decisions get routed through Atticus before shipping.
Operator
Pipeline stewards that maintain system health with high autonomy for bounded, bookkeeping tasks. Higher autonomy than Domain agents β but strictly scoped to pipeline mechanics, not decisions.
Governance
Policy authority and institutional memory. Atticus is the only agent that can approve or reject proposals from other agents β including Domain and Operator tiers. The ledger is permanent.
Labs Agents β Direct Surface
Dexter (Labs Leader) operates on direct surfaces β Slack, Notion, CurryChat β and Buzz (Distribution & Market-Signal) on Bridge and CurryChat, the pair's shared direct surface β rather than through dedicated OpenClaw gateway ports. They don't fit neatly into the three gateway tiers because their trust boundary is defined by the surface they operate on, not by a gateway isolation layer. Humans approve all public/outbound actions, with one carve-out: Buzz manages Reddit Ads with trusted read/write.
Key Architectural Decisions
π³Docker-Based Isolation
Decision:
Each agent runs in its own Docker container with isolated filesystem, network namespace, and resource limits.
Rationale:
- Prevents agents from accidentally interfering with each other
- Clear security boundaries (each agent has explicit volume mounts)
- Easy to restart or recreate individual agents
- Reproducible environments (Dockerfile defines the runtime)
Tradeoffs:
- Con: More resource overhead than bare processes
- Con: Requires Docker knowledge to debug
- Pro: Isolation worth the cost for reliability
π’Centralized Deployment (Mac mini)
Decision:
All agents run on a single Mac mini (Jake's local machine) rather than distributed cloud infrastructure.
Rationale:
- Simplicity: single machine to manage, no orchestration complexity
- Cost: no cloud compute bills for always-on agents
- Speed: low-latency inter-agent communication (all localhost)
- Privacy: sensitive data stays on local hardware
Tradeoffs:
- Con: Single point of failure (Mac mini down = all agents down)
- Con: Limited by single machine resources
- Pro: Acceptable for team scale (currently 2-3 active users)
- Future: Can distribute later if needed (Docker Swarm or K8s)
πBridge for Inter-Agent Communication
Decision:
Agent-to-agent messaging uses the Bridge CLI tool, not direct HTTP calls or message queues.
Rationale:
- Simple interface: agents call
bridge.ts target "message" - Built-in observability: every bridge call emits telemetry
- Handles retries, timeouts, and error formatting automatically
- Works from any environment (agent containers, local scripts)
Tradeoffs:
- Con: Not pub/sub (no fan-out broadcasts)
- Con: Synchronous (caller waits for response)
- Pro: Request-response pattern is clear and debuggable
- Pro: Can add async patterns later if needed
πObservability as Core Infrastructure
Decision:
Shared live telemetry infrastructure that all services instrument automatically. OpenObserve carries the stream, and Watchtower applies the operator-facing interpretation.
Rationale:
- Can't debug what you canβt see
- Automatic instrumentation means coverage is complete
- OpenObserve keeps live telemetry queryable without teaching Atlas a collector-first model
- Powers Watchtower dashboards and debugging flows with expected-state context
Tradeoffs:
- Con: Extra service to run and maintain
- Con: Storage grows over time (mitigated by retention policies)
- Pro: Invaluable for understanding system behavior
- Pro: Makes onboarding new team members easier
β°Cron-Based Autonomous Agents
Decision:
Scout and other autonomous agents run on scheduled cron cycles (every 4 hours for project charters), not continuous loops or event triggers.
Rationale:
- Bounded execution: each cycle has clear start/end
- Cost control: LLM usage limited to scheduled intervals
- Easier debugging: can inspect state between cycles
- Predictable resource usage (no runaway loops)
Tradeoffs:
- Con: Not real-time (up to 4-hour latency for autonomous work)
- Con: Agents canβt react immediately to events
- Pro: Human-initiated tasks still happen immediately (via Bridge)
- Pro: Batch processing is more efficient than constant polling
π―Skills as Procedural Knowledge
Decision:
Reusable agent capabilities are packaged as "skills" (markdown docs + scripts) rather than fine-tuning or prompt injection.
Rationale:
- Portable: skills work across any agent
- Versioned: can be tracked in git, reviewed, and improved
- Composable: agents load only the skills they need
- Human-readable: anyone can read SKILL.md and understand what it does
Tradeoffs:
- Con: Requires agent to read and follow instructions (not always perfect)
- Con: Context length cost for loading skill docs
- Pro: Much faster iteration than fine-tuning
- Pro: Can be improved by anyone who can write markdown
π¦Monorepo for Shared Infrastructure (Currykit)
Decision:
All shared services (Recall, Observability, Bridge, etc.) live in the Saffron monorepo (lambda-curry/saffron) under packages/, published as @lambda-curry/currykit-* to GitHub Packages.
Rationale:
- Shared types and config (@lambda-curry/currykit-shared) used by all services
- Atomic changes: update API and client in same commit
- Easier dependency management (single package.json root)
- Consistent tooling (Biome, TypeScript, Bun) across all services
Tradeoffs:
- Con: Larger repo to clone (includes all services)
- Con: Changes to shared types require testing all dependents
- Pro: Refactoring is easier (find-all-references works)
- Pro: Single CI pipeline for the entire stack
βοΈGovernance as a Dedicated Agent (Atticus)
Decision:
Policy enforcement and decision governance live in a dedicated agent (Atticus), not embedded in every agent's prompt. Agents consult Atticus before taking significant actions.
Rationale:
- Single source of truth: policies are defined once, enforced everywhere
- Auditable: every governance decision is logged to observability
- Evolvable: update Atticus's policies without touching every agent
- Human-in-the-loop: Atticus can escalate to Jake for edge cases
How it works:
- Agent sends a proposal to Atticus via Bridge with action + context
- Atticus classifies:
auto-approve,needs-human, ordeny - Approved actions proceed; denials include guidance for alternatives
- All decisions logged as
service: "atticus"events
Tradeoffs:
- Con: Extra bridge round-trip latency for governed actions
- Con: Adds a dependency that agents must be online to check
- Pro: Prevents runaway agent behavior without heavy sandboxing
- Pro: Creates a governance audit trail for accountability
π¨Visual Quality as a System Concern (Meg + Visual Verification)
Decision:
Visual quality is a first-class architectural concern, not an afterthought. A dedicated design agent (Meg) owns the design system, and a two-level visual verification loop (Storybook + Playwright at component level, vision model at app level) gates every UI merge.
Origin:
Observed directly: agent-built backends are often one-shot perfect (APIs tested, everything working), but frontends arrive "completely unusable" β cut-off content, horizontal scrolling, wrong CSS framework despite explicit instructions. Agents write correct code without producing usable software, because they donβt experience UIs. The same pattern was seen independently across multiple LC projects (Watchtower, Atlas, client rebuilds).
How it works:
- Meg generates a PDLP (Project Design Language Package) before any component work starts β tokens, components, layout, content style, and accessibility targets
- Coding agents load the PDLP as a constraint reference during build loops; the Shared Design Skill refuses to build without one
- Components are built and tested in Storybook isolation first: Playwright interaction tests validate behavior; screenshot tests capture visual baselines
- Full-app screenshots are reviewed by a vision-capable model (GLM-5.2 β fast and cheap) against the PDLP; failures are blockers, not suggestions
- Meg can be consulted directly via Bridge for design reviews at any point
Tradeoffs:
- Con: Adds a gate before UI merges β slower iteration when PDLP is missing or vision review flags issues
- Con: PDLP creation is upfront cost on every greenfield project
- Pro: Closes the fundamental gap between "agent writes correct code" and "humans can use the result"
- Pro: Storybook-first means component bugs surface early (in isolation) rather than late (in full-app integration)
- Pro: Design consistency compounds β reusing Meg's components is cheaper than each agent inventing its own
π±Lifecycle Operator as a Distinct Agent Class (Grafton)
Decision:
The initiative pipeline (Seeds β Work Items β harvest) is owned by a dedicated lifecycle operator agent (Grafton), separate from the domain agents (Clawdy, Scout, Currybot, Meg) that do the actual work and the governance agent (Atticus) that enforces policy. Grafton does not build, design, or decide β it tends the garden: checking readiness gates, promoting initiatives, and closing the harvest loop.
Rationale:
- Domain agents (Scout, Currybot, Meg) are consumed by their current work β they canβt reliably triage the broader initiative backlog
- Atticus governs decisions, not momentum β it doesnβt track whether a Seed is stuck or a harvest is overdue
- Pipeline health requires persistent attention that humans shouldn't have to provide manually
- Grafton's hourly sweep creates a clock: Seeds get reviewed on a cadence, not whenever someone remembers to look
Trust tier:
Grafton operates at Operator tier β higher autonomy than domain agents for pipeline bookkeeping (promotes Seeds, creates Draft Seeds, updates Notion fields), but strictly bounded: it never approves its own promotions, never assigns work without human confirmation, and escalates all gate decisions to sponsors or Jake. It is the enforcer of criteria, not the setter of them.
Tradeoffs:
- Con: Another always-on container with its own cron cost
- Con: Harvest loop logic is nontrivial to maintain (gate criteria evolve)
- Pro: Removes "initiative rot" β no Seed silently stalls for weeks without surfacing
- Pro: "Every harvest plants the next seed" becomes a literal system behavior, not just a principle
- Pro: Domain agents can focus on building; pipeline overhead moves out of their context
πCharter Registry as Machine-Readable Source of Truth
Decision:
All Saffron charters (product tools and process pipelines) are centrally declared in registry/projects.json with a typed schema. This becomes the authoritative source for charter name, owner agent, domain, workspace path, trigger type, and status β eliminating drift between documentation, routing logic, and what actually exists.
Rationale:
- Grafton's routing skill resolves unknown owners against this registry before flagging a gap β reducing false routing alerts
- New charters (Crucible, Foundry, Shears, Ledger, Almanac) needed a single place to declare existence
- Typed schema catches errors (missing required fields) before runtime
- Product charters vs. process charters have meaningfully different shapes (port vs. trigger) β the schema enforces this distinction
Tradeoffs:
- Con: Another file to keep in sync β stale registry entries create false confidence
- Pro: Grafton, Atlas, and other agents can query one file instead of reading every agent's workspace
- Pro: Makes the charter inventory visible at a glance β 9 charters at time of ADR, growing
π³Docker Container Naming: Agent-Aligned Names
Decision:
Docker containers are named after the agent they run, not the original experiment or service name. lc-openclaw β lc-currybot and lc-experiment β lc-scout (Mar 6, 2026).
Rationale:
- Early names reflected the generic container role; agent identities are now stable
lc-openclawreferred to the OpenClaw framework, not what was running inside β misleading to new team members- Consistent naming: every container is
lc-{agent}across Compose and Dockerfiles - Aligns with the broader Saffron principle that agents are first-class entities, not experiments
π¦Docker Build Infra Centralized in Saffron Monorepo
Decision:
All agent Dockerfiles, docker-compose.yml files, and entrypoint.sh scripts live in saffron/services/docker/<agent>/ β not in the agent workspace repos or scattered across the host. A shared tooling snippet (_shared/tooling.layer.snippet.Dockerfile) provides the common tool layer (bun, gh, Playwright, Codex CLI) to any agent that needs it. The Atticus Dockerfile was the final migration to complete this pattern (Mar 7, 2026). Since the 2026-06-28 launch-dir migration, the live edit point is the saffron root itself β edit and recreate from each agent's services/docker/ directory (live-verified 2026-07-10); the earlier Atticus-clone lane is retired.
Structure:
Rationale:
- Build configs previously lived in per-agent repos or legacy
~/lc-*dirs β hard to diff, review, or coordinate changes - Naming the one live checkout prevents operators from fixing the wrong copy when a container or port mapping drifts β since 2026-07 that checkout is the saffron root, and old compose copies in agent clones are historical drift
- Shared tooling layer keeps Dockerfiles DRY: one place to update bun version or add a system package for all coding agents
- Saffron becomes the canonical source of truth for both agent workspaces (
agents/) and their containers (services/docker/) - Enables future CI to build and push all agent images from a single repo trigger
- Grafton was the first agent launched from this path; the pattern proved itself before rolling out to others
Image policy:
All agents build FROM openclaw:local. The legacy lc-base:local image is retired.
π§ QMD Remote HTTP for Dockerized Agents
Decision:
The five dockerized agents (Scout, Atticus, Meg, Grafton, Samwise) route their memory_search calls to the host QMD server via remote HTTP rather than relying on a local QMD instance inside each container. Host-level surfaces such as Clawdy and Currybot query that same host QMD directly rather than through a separate container. Each containerized agent is assigned a unique auth token (QMD_AUTH_TOKEN=qmd-<agent>-<token>) and an agent identifier (QMD_AGENT=scout, etc.). The QMD server runs on the host at port 8790 and is reached via host.docker.internal:8790.
Configuration:
Rationale:
- A single host QMD keeps the vector index in one place β no per-container index drift or duplication
- Containerized agents canβt write their own QMD indexes; centralizing reads (and writes) on the host makes the memory layer consistent
- Per-agent tokens allow request attribution and future per-agent access control at the QMD level
- Paired with a custom OpenClaw fork patch that implements the remote HTTP search path in
qmd-manager.ts
Network effect:
The dockerized agents now share the same QMD view as the host-level assistant surfaces. A Notion page indexed once by RAG Sync is immediately queryable by any agent, whether it runs in a container or through a host-level gateway. The Knowledge Layer is truly network-wide, not per-process.
π¦Bake Agent Toolbelt into openclaw:local Base
Decision:
The standard LC Docker agent toolbelt (bun, uv, Codex CLI, agent-browser, Playwright, gh, jq, ripgrep, ffmpeg, imagemagick, python3, qmd shim, git/SSH bootstrap) is now baked directly into the openclaw:local base image. The shared tooling.layer.snippet.Dockerfile is deprecated and no longer pasted into individual agent Dockerfiles.
New agent Dockerfile pattern:
Rationale:
- Eliminates ~400 lines of duplicated tooling setup across 5 agent Dockerfiles
- New agent images stay thin β they inherit the toolbelt automatically from the base
- OpenClaw/pi-ai toolbelt updates propagate to all agents in a single base image rebuild
- Removes the risk of silent runtime misses (e.g.,
bun: not found) when creating new agents from minimal templates - Pairs naturally with ADR #14 β the qmd shim for remote HTTP is included in the base, so containerized memory search just works
Toolbelt included in base:
bun / bunx, uv, agent-browser, @openai/codex, Playwright + Chromium, gh, jq, ripgrep, ffmpeg, imagemagick, python3, curl, unzip, qmd shim (remote HTTP), standard git safe.directory + SSH known_hosts + cache dirs.
πEnrich Delegate Completion Notifications with Branch & Preview Links
Decision:
The packages/delegate completion notification now includes the working branch, GitHub repo/branch links, and Cloudflare Pages preview URLs (or production URL for main). These fields are forwarded from the CLI through to notify-completion.ts as part of the CompletionPayload.
Enriched Slack message format:
Rationale:
- Reduces friction: one-click from Slack notification to live preview or PR branch β no copy-pasting repo names
- Preview URL resolved via
wrangler pages deployment listat notification time β always points to the current branch's deployment - Falls back gracefully: production URL shown for main/master; branch link shown if preview lookup fails; bare repo name if GitHub URL not parseable
- Extends the existing
packages/delegatecanonical source pattern (ADR #15) β no changes needed to agent-specific code - Pairs with the CF Pages deploy pipeline (Anvil ADR) β agents that push feature branches get instant preview links in their completion Slack DM
Registered CF Pages projects:
lambda-curry/saffron-starter β saffron-storybook.pages.dev Β |Β lambda-curry/lc-classic-starter β lc-classic-storybook.pages.dev
Four Distinctions That Make the Network Easier to Navigate
Charter vs Agent
Bridge vs Direct Control-Plane
Memory vs Live State
Three Trust Gaps
βEvery project needs its own design language. It might not be a dedicated design agent β it might be an agent that helps projects find their design language.β β Jake Ruesink
What We Avoid (Anti-Patterns)
π± How the Network Grew
The Saffron Network wasn't designed all at once β it grew agent by agent, each one filling a gap the previous generation exposed. This timeline shows the order in which each agent was added and the reasoning behind it.
Jake needed a capable personal assistant β not a chatbot, but a proper agent with shell access, memory, and messaging.
Clawdy launched as Jake's primary assistant. Full tool access, Signal/WhatsApp/Telegram integration, persistent memory via QMD.
Proved the model: an agent with real tools and real memory is categorically more useful than a stateless chatbot. Established the pattern every future agent would follow.
Clawdy handled Jake's personal context well, but the LC team needed their own agent β for PR reviews, team queries, and shared workflows.
Currybot launched on the LC team Slack. Automated PR reviews, standup summaries, GitHub webhook responses. Separate identity from Clawdy β team-facing, not founder-facing.
Demonstrated that agents scale horizontally: same platform, different identity and access scope. One agent per concern, not one agent for everything.
Clawdy and Currybot were reactive β they responded to messages. No agent was proactively exploring, building, or improving the system without being asked.
Scout launched as the first cron-driven autonomous agent. Self-directed work cycles: research β build β log β report. Sandboxed in Docker. Launched with four standing charter loops (Watchtower, Atlas, Forge, Anvil) plus a direct-product-charter lane β the standing family has since grown to five, with Podcast Platform now a recurring Scout charter.
Demonstrated autonomous compound value: each Scout cycle builds on the last. Established the charter-family pattern, where one agent can keep recurring loops healthy without giving up room for newer product work under the same identity.
As autonomous agents accumulated more capability, there was no systematic way to verify that proposed actions aligned with LC's goals and values. Human review didn't scale.
Atticus launched as the network's governance authority. Agents route significant proposals through Atticus before acting. Permanent decision ledger. Escalation to Jake when human input is required.
Closed the trust gap between capable agents and appropriate authority. Made the system auditable. Established the Atticus Gate pattern β a forcing function for alignment before action.
Agents building UIs independently produced technically correct but visually inconsistent output. No shared design language meant every project reinvented spacing, tokens, and components.
Meg launched as LC's design engineer and design authority. Generates PDLPs (Per-Project Design Language Profiles) before build work begins. Runs visual audits via Playwright + vision model. Leads Storybook component reviews.
Closed the design language gap. Now all agent-built UIs share the same token set and component patterns. Visual quality is enforced mechanically, not by human review.
The Seeds-to-Work-Items pipeline existed, but no agent was responsible for keeping it moving. Seeds stalled, harvest loops were missed, and pipeline health required manual attention.
Grafton launched as the network's sixth agent and first Operator-tier agent. Hourly sweeps, nightly observation, Sunday weekly reflection. Promotes Seeds through gates, runs harvest loops when Work Items complete, reactivates Dormant Seeds.
Operationalized the 'every harvest plants the next seed' principle. The initiative pipeline now runs itself. Grafton established a new trust tier β Operator β for high-autonomy pipeline stewardship that doesn't require Atticus gating.
As Scout delegated more implementation work to Codex and other coding agents, the handoff layer between 'Jake asks' and 'code ships' grew thin. No agent owned the advisory space β intake triage, execution reporting, and the bridge between operator intent and delegated delivery.
Samwise launched as a Domain-tier advisory and delivery agent. Manages intake triage, runs execution reporting, and serves as a delegation target for Clawdy's implementation tasks. Multi-tenant reporting app proves Domain agents can ship reader-facing product software, not just run cycles.
Closed the advisory gap between operator intent and delegated execution. Established that Domain-tier agents can own both process and product surfaces simultaneously.
The network could build, govern, and operate β but it couldn't honestly test new product ideas or reach audiences. Every idea felt equally worth pursuing because nothing validated or killed them. And once something was built, no agent owned the path to users.
Dexter launched as Labs Leader to guide experiment design, validation, and honest assessment of ideas. Buzz launched as Dexter's distribution counterpart β finds audiences, designs approved distribution experiments, and manages Reddit Ads with trusted read/write. Dexter operates on direct surfaces (Slack, Notion, CurryChat); Buzz on Bridge and CurryChat β the pair's shared direct surface β rather than gateway ports.
Introduced the Labs agent pattern: chartered agents on direct surfaces with trust scoped to the platform rather than the gateway. Humans approve all public/outbound actions. Brought the network to nine agents and completed the build-govern-operate-test-distribute loop.
Future Considerations
- Forge β Workspace Generator (active): Scout sub-project that automates new agent workspace creation. Given a project description, Forge produces a complete OpenClaw workspace β AGENTS.md, TOOLS.md, skills, bridge config. Phase 2A active; Phase 2B blocked on port/secrets decisions. Goal: dramatically reduce the manual setup cost of onboarding new agents.
- Anvil β AI Rules Auditor (product launch mode): Scout sub-project that improves the quality of AI rules across the network β and is now being packaged as an external product. Anvil audits AGENTS.md, CLAUDE.md, and TOOLS.md files for gaps, conflicts, and stale references; scores rule quality against an 11-dimension rubric; and produces actionable improvement reports. CLI-first (
npx anvil audit), fully proprietary. Where Forge builds the workspace, Anvil refines the rules inside it. - Saffron Starter + LC Classic Starter (active): Two turborepo project templates β one TanStack Router-based for Saffron/Scout greenfield projects, one React Router 7-based for LC client projects. Both bake in the PDLP, Storybook, and visual verification pipeline from day one. Meg leads design tokens; Scout provides app-layer engineering. LC Classic Starter has PDLP v1.0.0-draft merged; Saffron Starter's design-tokens-v2 PR (#4) is in review.
- Grafton β Lifecycle Operator (active): The sixth Saffron agent, launched Feb 28 2026. Grafton manages the Seeds-to-Work-Items lifecycle β the structured idea pipeline that tracks every initiative from rough hypothesis (Draft Seed) through gate-based promotion to active Work Item and finally harvest. Grafton runs an hourly sweep, a nightly observer, and a Sunday weekly reflector, posting to
#saffron-updatesonly when something needs attention. Critically, Grafton enforces gates without being the decision-maker: sponsors and Jake approve promotions; Grafton ensures the criteria were actually met. - Multi-agent project collaboration (active): As projects grow beyond 2β3 agents, per-agent charters (AGENTS.md, GOALS.md) need a coordination layer. The Saffron Charter Standard keeps Layer 1 lifecycle state in the mounted charter workspace, Layer 2 product code and durable delivery evidence in the repo, and Layer 3 handoffs in Bridge.
- Multi-host deployment: If the Mac mini becomes a bottleneck, agents can be distributed across multiple machines using Docker Swarm or Kubernetes.
- Async messaging patterns: Currently all bridge calls are synchronous request-response. Could add pub/sub for fan-out scenarios (e.g., "notify all agents that config changed").
- Persistent workflows: Cron works for bounded cycles, but for long-running tasks (multi-day projects, continuous monitoring) workflow orchestration (Temporal, Inngest) would be more appropriate.
- Security hardening: Currently trust-based (all agents run as same user). External exposure would require proper auth/authz between services.
The key principle: start simple, add complexity only when needed, and always have a clear reason for the tradeoff.