🔒 Protected via Cloudflare Access

Mindset Coordination — Design Analysis

Current State

Each mindset has:

Cross-mindset communication today:


The Three Problems

1. Routing Intelligence

Current: Main routes based on static IDENTITY.md descriptions. Each mindset's capabilities are defined at creation time and rarely updated.

Problem: Mindsets learn. Infra now knows about CF Pages, session-scoped browsers, wacli quirks. PA knows Dom's contact graph. These capabilities aren't visible to main when routing.

Recommendation: Capability Manifests

Each workspace gets a CAPABILITIES.md — a living document that each mindset maintains:

# CAPABILITIES.md — Infra

## I Can Do
- Cloudflare Pages deployment (6 projects managed)
- Session-scoped browser isolation
- OpenClaw gateway management, plugin development
- Git-crypt encrypted backups
- Tailscale networking, SSH recovery
- 1Password credential management
- LaunchAgent service management

## I've Learned
- Browser automation = openclaw browser, never Peekaboo
- Config writes can crash gateway (reload.mode=hot)
- wacli session conflicts cause auth wipe

## I Need From Others
- Design-engineer: static site builds (I deploy, they build)
- PA: credential requests from Dom, account invitations

How main uses it: Before routing, main reads ~/.openclaw/workspace-*/CAPABILITIES.md — lightweight, always current, maintained by the mindset that knows best.

Update trigger: Each mindset updates CAPABILITIES.md during heartbeat memory maintenance (already scheduled).


2. Information Surfacing (The Notification Problem)

Current: Threads share state via workspace files, but there's no push mechanism. PA could discover Dom owes a payment that infra needs to act on — but infra won't know until someone looks.

Options evaluated:

Approach Pros Cons
Shared dropbox file Simple, no new infra Polling-based, easy to miss
sessions_send direct Real-time, uses existing tool Need session key, couples mindsets
open() cross-thread Creates visible thread, tracked Heavy for small notifications
Shared bulletin board Async, scannable, lightweight Needs periodic check
Discord channel as bus Visible, persistent, searchable Another channel to monitor

Recommendation: Bulletin Board + Heartbeat Scan

Create ~/.openclaw/shared/bulletin.md — a shared file that any mindset can append to:

# Bulletin Board

## 2026-04-06

### [PA → Infra] Dom's Cloudflare billing renewal April 15
Dom mentioned CF bill is coming up. May need payment method update.
Posted: 2026-04-06 14:30 PDT

### [Design-Engineer → Socials] New blog post ready for distribution
blog.justin.vin updated with "Session-Scoped Browsers" post. Ready to share.
Posted: 2026-04-06 15:00 PDT

Rules:

Why not sessions_send? Requires knowing the exact session key (changes per thread), synchronous (blocks), couples mindsets. Bulletin is async, discoverable, no session dependencies.

Why not Discord channel? Another session, more token burn, cross-channel routing complexity. Files are simpler.


3. Cross-Mindset Queries

Recommendation: Layered approach

Layer Mechanism Use Case
1 CAPABILITIES.md "What does this mindset know about?"
2 Direct workspace reads "What's in infra's MEMORY.md about Tailscale?"
3 open() a thread Complex queries needing reasoning
4 Future: cross-workspace memory_search Semantic search across all mindsets

Any mindset CAN read ~/.openclaw/workspace-<other>/MEMORY.md. The convention just needs documenting:


Architecture Decision: Hub vs. Mesh

Recommendation: Hub for orchestration, mesh for data

Communication Type Pattern Mechanism
Routing decisions Hub (main) Reads CAPABILITIES.md, decides who
Notifications Mesh (bulletin) Async, any-to-any, heartbeat-scanned
Data queries Mesh (direct reads) Any mindset reads another's MEMORY.md
Complex queries Hub (open thread) Creates audit trail, uses existing routing

Main stays the strategic router without bottlenecking every cross-mindset interaction.


Concrete Next Steps

  1. Create CAPABILITIES.md template — add to each workspace
  2. Create ~/.openclaw/shared/ directory — bulletin board and cross-mindset files
  3. Create bulletin.md convention — document format + heartbeat scan
  4. Update HEARTBEAT.md per mindset — add bulletin scan step
  5. Update AGENTS.md — document cross-mindset read conventions
  6. Update main's routing logic — read CAPABILITIES.md before delegating

What this does NOT require: No new plugins, tools, APIs, databases, message queues, or Discord channels. Everything builds on existing primitives: files, heartbeats, open(), and direct reads.


How Other Systems Solve This

Our approach mirrors LangGraph's shared state but on the filesystem — more durable (survives crashes, restarts, session resets), negligible latency tradeoff.


Risk Assessment