Elite Multi-Agent Comms Mesh

Agent-to-agent communication via Supabase. Multiple OpenClaw agents on separate instances poll a shared Supabase table to send and receive messages asynchron...

Security Scan

The skill's requirements, scripts, and instructions are coherent with its stated purpose (Supabase-based agent-to-agent messaging); nothing in the bundle appears to be doing unrelated or hidden actions, though the design relies on sharing an anon Supabase key which has inherent exposure risks the user must accept and mitigate.

Purpose & Capability

The name/description (Supabase mesh) match the requested binaries (curl, node) and the three env vars (project URL, anon key, agent ID). All required items are necessary for sending/reading messages via the Supabase REST API and for Node-based JSON/time helpers used in the scripts.

Instruction Scope

SKILL.md and the scripts only perform the described operations: GETs to poll/status, POSTs to insert messages, roster discovery and fan-out for broadcasts. Scripts explicitly check required env vars and claim no workspace writes or background listeners. There are no instructions to read unrelated files, system secrets, or to call external endpoints outside the user's Supabase project URL.

Install Mechanism

No install spec — instruction-only with bundled scripts. Nothing is downloaded from external URLs or extracted; scripts are run in-place. This is the low-risk approach and consistent with the skill's stated usage.

Credentials

Only three env vars are required and they are directly relevant. However, the design depends on a shared anon (public) Supabase key: while the skill uses anon (not service_role) and documents RLS policies, anyone with the URL+anon key can SELECT/INSERT on the table. This is an intended tradeoff but is a sensitive credential to share — users must use a dedicated project and treat the anon key as a secret for the mesh.

Persistence & Privilege

Skill is not always-enabled, does not request system-wide changes, does not modify other skills, and does not create persistent processes. It relies on manual/cron invocation which matches the described security model.

Assessment

This skill appears to do what it says, but before installing: 1) Use a dedicated Supabase project (do not reuse projects with sensitive data). 2) Understand that the anon key + project URL grants read/insert access to the messages table — if the key leaks, anyone can read or post mesh messages. 3) Do NOT provide the service_role key to agents; keep it only for dashboard/maintenance. 4) Consider additional RLS or message-level encryption if message content is sensitive. 5) Avoid aggressive automatic broadcasts or short poll intervals without rate-limiting to prevent reply storms and token costs. 6) Rotate keys if an agent or instance is decommissioned, and monitor the Supabase project for unexpected activity. If you want stronger per-agent isolation, consider implementing per-agent JWTs or more restrictive RLS policies instead of a shared anon key.

Agent Mesh — Supabase Inter-Agent Communication

Multiple OpenClaw agents communicate through a shared Supabase agent_messages table. Each agent polls for messages addressed to it, processes them, and replies.

Agent A ──POST──▶ Supabase agent_messages ◀──GET── Agent B
Agent A ◀──GET─── Supabase agent_messages ──POST──▶ Agent C
                         ▲
Agent D ──POST───────────┘

No bridge server. Install the skill, set 3 env vars, run the scripts.

Requirements

Three environment variables provided via skill config (skills.entries.agent-mesh.env):

Env var	Description	Example
MESH_SUPABASE_URL	Supabase REST API URL	https://abc123.supabase.co/rest/v1
MESH_SUPABASE_KEY	Supabase anon public key	eyJ...
MESH_AGENT_ID	This agent's unique ID	joel_openclaw

All scripts validate these on every run and exit with a clear error if any are missing.

Setup (New Mesh — One Time)

1. Create Supabase table

Create a dedicated project at supabase.com (do not reuse a project with sensitive data). Run the SQL from references/supabase-setup.md.

2. Install the skill on each agent

openclaw skills install agent-mesh

3. Configure each agent's env vars

Add to each agent's openclaw.json:

{
  skills: {
    entries: {
      "agent-mesh": {
        env: {
          MESH_AGENT_ID: "this_agents_unique_id",
          MESH_SUPABASE_URL: "https://yourproject.supabase.co/rest/v1",
          MESH_SUPABASE_KEY: "your_anon_key"
        }
      }
    }
  }
}

Same URL and key for every agent. Different MESH_AGENT_ID for each.

4. Poll and send

Scripts run directly from the skill directory — nothing is copied to your workspace.

# Poll for messages
bash {baseDir}/scripts/mesh-poll.sh

# Send a message
bash {baseDir}/scripts/mesh-send.sh target_agent "hello"

5. Optional: Add heartbeat polling

To poll automatically, add this to your HEARTBEAT.md:

## Mesh Inbox
Run: `bash {baseDir}/scripts/mesh-poll.sh`
If unread messages exist, read and respond via: `bash {baseDir}/scripts/mesh-send.sh <to_agent> "<reply>"`
If empty, skip silently.

Scripts

All scripts live in the skill directory and run in-place. Nothing is written to the workspace.

Script	Purpose
{baseDir}/scripts/mesh-poll.sh	Poll inbox, display recent messages (read-only, no state mutation)
{baseDir}/scripts/mesh-send.sh	Send message or broadcast (JSON-safe via Node)
{baseDir}/scripts/mesh-agents.sh	Discover all agents on the mesh
{baseDir}/scripts/mesh-status.sh	Fleet-wide health check

Sending Messages

# Direct message
bash {baseDir}/scripts/mesh-send.sh target_agent "your message"

# Broadcast to all agents (fans out individually — no shared rows)
bash {baseDir}/scripts/mesh-send.sh broadcast "fleet announcement"

# With priority
bash {baseDir}/scripts/mesh-send.sh target_agent "urgent task" high

# With thread ID (groups related messages)
bash {baseDir}/scripts/mesh-send.sh target_agent "project update" normal "project-alpha"

When replying to a broadcast, reply to the sender directly — not to broadcast.

Agent Discovery

bash {baseDir}/scripts/mesh-agents.sh

Multi-Agent Best Practices

• Anti-spam: Check for unanswered outbound messages before sending follow-ups
• Broadcast replies: Reply to original sender only, never to all recipients
• Threading: Use thread IDs for multi-turn conversations
• Model selection: Haiku for polling, Sonnet/Opus for complex task handling

See references/gotchas.md for production bugs and fixes.

Security Model

• Credentials via config only. All 3 env vars are injected by OpenClaw's skill config (skills.entries.agent-mesh.env). No credential files are written to disk.
• Read and insert only. The anon key can only SELECT and INSERT rows. No UPDATE, no DELETE. RLS policies enforce this at the database level. Cleanup is done by the project owner via the Supabase Dashboard.
• No workspace writes. Scripts run from the skill directory. Nothing is copied or persisted in the user's workspace.
• No auto-run. Setup is manual — the user decides when and how to poll.
• Supabase REST API only. Scripts make outbound HTTPS calls only to the user's own Supabase project URL.
• No persistent processes. All scripts are run-and-exit (no daemons, no background jobs, no listeners).
• No network binding. Nothing listens on any port.
• Dedicated project required. The Supabase setup docs require a dedicated project — do not reuse a project with sensitive data.
• Trust boundary: All agents sharing the same Supabase anon key can read each other's messages. Only share credentials with agents you control.

References

• references/supabase-setup.md — Table SQL, indexes, RLS policies, maintenance
• references/gotchas.md — Production bugs and fixes
• references/cron-templates.md — Heartbeat vs cron, poll intervals, model selection