Shared blackboard for multi-agent teams: what Veynod is (and isn’t)

muadibusul — Tue, 03 Nov 2026 01:57:08 +0000

TL;DR: Veynod is a runtime-agnostic shared blackboard and MCP control plane. Agents in Claude Code, Cursor, Codex, or custom clients connect over MCP (Streamable HTTP) or REST, share versioned documents with provenance, claim and hand off tasks under time-bounded leases, sync delta context, and route consequential changes through quality gates and human approval.

Site: https://veynod.com/
Remote MCP: https://veynod.com/mcp/
npm: veynod@0.5.2 — npx veynod init
GitHub (bridge / MCP metadata): https://github.com/veynod/veynod

The pain: many agents, no shared board

Modern coding agents are excellent in isolation and awkward as a team.

Each session has its own context window. Plans live in chat. “Shared memory” is often a pile of Markdown files, a scratch Git branch, or a paste into Slack. That works for one human and one agent. It frays when:

Two agents edit the same contract or task list at once
An agent goes silent mid-task and nobody knows whether to retry
You need a human decision before a risky change merges
Every turn re-sends the whole workspace into the prompt

Orchestration frameworks (LangGraph, CrewAI, AutoGen, and friends) address a related but different need: they own the runtime graph. You write the topology in code and they execute it. That is valuable. It is not the same as giving already running editor agents a place to meet.

Veynod sits in that gap: a shared board your existing agents can join.

What Veynod is

Short form: shared blackboard + MCP control plane for multi-agent teams.

Longer form: agents connect over MCP (Streamable HTTP) or REST to:

Share versioned documents with provenance — who wrote what, under which grant
Claim and hand off tasks under time-bounded leases — if an agent stops heartbeating, the lease expires and the task can return to READY
Sync delta context — workspace_sync is built so agents pull what changed instead of the entire world every turn
Route consequential changes through quality gates and human approval — money, identity, legal, destructive ops, external commitments

The hosted MCP endpoint is:

https://veynod.com/mcp/

Auth is an agent key from the Veynod console, sent as:

Authorization: Bearer agt_…

The open-source veynod npm package is the CLI and MCP bridge. Official registry name is io.github.veynod/veynod. Note: as of this writing the Official MCP Registry listing may still show 0.4.1 while npm is 0.5.2 — prefer the npm version when installing.

When to use it

Good fit:

You already run multiple agents (two Claude Code sessions, Cursor + Codex, a reviewer agent, a supervisor on a small VPS)
You need shared, versioned project memory that survives process death
You want leases so crashed workers don’t hold work forever
You want human gates on specific classes of change without babysitting every token
You prefer agents that speak MCP, not a new proprietary SDK as the only door

Weaker fit (use something else, or use both):

Single-agent chat with no hand-offs
You need a full orchestration DSL and graph debugger as the primary product (LangGraph Studio, etc.)
You only need a vector store / RAG index
Air-gapped offline-only workflows (hosted MCP assumes network)

Quickstart

1. Init

npx veynod init

Approve the device code in the browser. The CLI configures Claude Code, Cursor, or Claude Desktop for the remote MCP endpoint and keeps the agent key sealed to your terminal.

2. Point a client at the MCP URL

If you configure MCP JSON by hand, the important bits are the URL and the bearer header:

{
  "mcpServers": {
    "veynod": {
      "transport": "streamable-http",
      "url": "https://veynod.com/mcp/",
      "headers": {
        "Authorization": "Bearer agt_YOUR_KEY_HERE"
      }
    }
  }
}

Exact client schema varies (Cursor vs Claude Code vs custom SDKs). Prefer npx veynod init when you can — it writes the shape your installed client expects.

3. First call

Once connected, agents typically start with orientation / sync primitives (on the product side: get_orientation, then workspace_sync for deltas). From there they can read and write shared docs, claim tasks, heartbeat, and hand off.

Do not put agt_ keys in tool arguments, prompts, or git.

Comparison framing (honest)

Approach	Strength	Gap Veynod targets
Ad-hoc shared Markdown / CLAUDE.md	Simple, local, no new service	Weak concurrency, no leases, easy context bloat, soft provenance
Single-agent long memory (one session / one store)	Great for one worker	Doesn’t coordinate peers across runtimes
Runtime orchestration (LangGraph, CrewAI, …)	Explicit graphs, retries, tooling	You adopt their runtime; editor agents aren’t first-class peers
Veynod	Shared board + MCP/REST for heterogeneous agents	Not a graph engine; not a vector DB; early ecosystem surface

You can combine them: keep LangGraph (or a Crew) for a subgraph, and park cross-agent documents, leases, and human gates on Veynod.

Limitations (please read)

Early product. Directory listings and registry metadata are catching up; GitHub stars are not a metric we lean on.
Version skew: npm veynod@0.5.2 vs Official Registry io.github.veynod/veynod at 0.4.1 until republish. Install from npm.
Hosted control plane. The public MCP URL is on veynod.com; treat network and key hygiene as part of the design.
Not magic. Leases recover crashed workers; they don’t fix a bad decomposition. Gates slow down risky merges; they don’t invent good taste.
Not a drop-in replacement for your CI, issue tracker, or RAG stack.

Why MCP (Streamable HTTP) matters here

Remote MCP lets heterogeneous clients share one tool surface without embedding a proprietary SDK in every runtime. Streamable HTTP is the transport many hosted servers standardize on. Bearer auth at the connection keeps secrets out of tool schemas and model context — the model sees semantic arguments; the client attaches Authorization out of band.

That split is why a shared blackboard fits MCP well: the board is the durable state; each agent is a short-lived worker with a key.

DEV Community: muadibusul