OpenClaw Second Team & Co‑worker Room for the Hermes Fleet

1. What this is

This brief describes a proof‑phase deployment of a second OpenClaw team that works side‑by‑side with the Hermes fleet. It caps the co‑worker agents at 2 concurrent instances and uses a local SQLite file as the shared brain for message passing. The design avoids costly hardware, external services, and the fatal objections raised by Joker.

2. What would make it work

• Cap the OpenClaw co‑worker team at 2 agents (Shri’s approved proof‑phase size) and queue any additional work with a simple shell‑script scheduler.
• Run the OpenClaw gateway on a custom port 18890 to avoid the Hermes UI port 18789 conflict.
• Store rooms and message queues in a local SQLite file /home/hermes/pantheon-briefs/openclaw-two-team/shared_brain.db with advisory file locks to prevent concurrent‑write corruption.
• Secure the OpenClaw dashboard behind the existing Cloudflare Access policy (no new SSO group required).
• Limit model calls to the provider’s single‑request concurrency (2 simultaneous calls) to stay within the Ollama‑cloud quota.

3. What would kill it

1. GBrain unavailable – repo 404, no binary/Docker – any design that relies on GBrain must be discarded.

2. Multi‑agent *room teams* are marked *experimental* in OpenClaw 2026.9.5; race conditions after ~5 agents can crash the gateway.

3. Clawboo bridge requires native binaries compiled for x86_64; on ARM the install falls back to source and fails ("gcc‑lite" is not a real package).

4. Port conflict: Hermes gateway already occupies 18789. If OpenClaw also uses 18789 the daemon will fail to bind.

5. Model provider allows only a single concurrent request; with 10 agents latency >30 s and throttling errors occur.

Additional annoyances (not fatal but undesirable): ARM‑only Node fallback doubles CPU usage, SQLite concurrent‑write risk without advisory lock, Cloudflare tunnel token leakage risk, and naming clash with existing “Titans” agents.

4. The stack and how it runs

• OS / host: Oracle‑Linux 6.17 on the free‑tier VPS agents-01 (2 OCPU / 12 GB RAM).
• OpenClaw gateway: runs on port 18890, started via openclaw gateway start --port 18890.
• Co‑worker agents: two instances (e.g., TitanCo‑1 and TitanCo‑2) connect to the gateway and communicate through the shared SQLite brain.
• Shared brain: SQLite file shared_brain.db with a simple advisory lock (Batman confirmed this mitigates the race‑condition risk H5).
• Model calls: routed through the existing Ollama‑cloud provider; concurrency limited to 2 simultaneous calls.
• Access control: Cloudflare Access SSO policy (already defined) protects the OpenClaw dashboard; agents authenticate via gateway token, not via Access groups.

5. Questions for Shri

1. When we later expand the OpenClaw co‑worker team beyond the proof‑phase 2 agents, should we provision a second free‑tier VPS (e.g., agents‑02) or request additional Ollama provider quota for local models?
2. Do you approve using the advisory‑lock SQLite file as the shared brain, or would you prefer migrating that store to Cloudflare D1?
3. Should we rename the second‑team agents to avoid the “Titans” naming clash (e.g., TitanCo‑1, TitanCo‑2)?