Objective

When you run several specialized agents — a researcher, a planner, a critic — they need a way to share what each has learned. The classic pattern is a blackboard: one shared memory every agent writes to and reads from. Most teams reach for a message bus plus a vector store plus locking. Here you'll build a blackboard in one table: agents post findings with their identity and confidence, and any agent recalls the most relevant contributions by meaning. The same store works from any framework or a voice agent — see Use it from your agent at the end.

Step 1: Create the shared blackboard

One row per contribution, tagged with the posting agent, a confidence, and an embedding for recall.

CREATE TABLE IF NOT EXISTS recipe_blackboard (
  entry_id    INTEGER PRIMARY KEY,
  task_id     TEXT,                                  -- the shared task all agents work on
  agent_role  TEXT,                                  -- 'researcher' | 'planner' | 'critic' | ...
  finding     TEXT,
  confidence  DOUBLE,                                 -- 0..1: how sure the posting agent is
  created_at  TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  embedding   VECTOR(384)
);

Step 2: Agents post their findings to the blackboard

Several specialized agents contribute what they've learned about a shared task.

INSERT INTO recipe_blackboard (entry_id, task_id, agent_role, finding, confidence) VALUES
 (1,'launch','researcher','The target market is small businesses in EMEA with under 50 staff.',0.85),
 (2,'launch','researcher','Competitor X launched a similar feature last quarter at $19/mo.',0.80),
 (3,'launch','planner','We can ship an MVP in 6 weeks if we cut the analytics dashboard.',0.70),
 (4,'launch','critic','Pricing below $25 risks signaling low quality to enterprise buyers.',0.75),
 (5,'launch','researcher','EMEA buyers strongly prefer monthly billing over annual contracts.',0.82),
 (6,'launch','planner','A phased rollout starting in Germany reduces support load.',0.68);

Step 3: Embed the findings

The embedding model runs in-database, making every contribution recallable by meaning.

UPDATE recipe_blackboard SET embedding = EMBED(finding);

Step 4: One agent reads what's relevant to its subtask

The planner pulls everything the others have posted that bears on pricing — across agent roles, by meaning.

SELECT agent_role, finding, confidence,
       COSINE_SIMILARITY(embedding, EMBED('how should we price this and how do customers want to pay?')) AS relevance
FROM recipe_blackboard
WHERE task_id = 'launch'
ORDER BY relevance DESC
LIMIT 4;

Step 5: Weight contributions by confidence

Blend semantic relevance with each agent's confidence so a sure finding outranks a hedged one on the same topic.

SELECT agent_role, finding,
       COSINE_SIMILARITY(embedding, EMBED('what is the market and the competition?')) * 0.7
       + confidence * 0.3 AS weighted_score
FROM recipe_blackboard
WHERE task_id = 'launch'
ORDER BY weighted_score DESC
LIMIT 3;

Step 6: A coordinator synthesizes the blackboard into a decision

Feed the top contributions to GENERATE() so a coordinator agent produces a unified recommendation.

SELECT GENERATE(
  'You are a coordinator. Given these findings from your team, give a one-paragraph launch recommendation:\n' ||
  (SELECT GROUP_CONCAT(agent_role || ' (conf ' || confidence || '): ' || finding, '\n')
     FROM recipe_blackboard WHERE task_id = 'launch')) AS recommendation;

Cleanup (Optional)

DROP TABLE IF EXISTS recipe_blackboard;

Expected Outcomes

Step 4 surfaces the pricing and billing-preference findings for the planner — contributions from other agents, retrieved by meaning.
Step 5 promotes the higher-confidence market findings above hedged ones on the same topic.
Step 6 produces one coherent launch recommendation synthesized from every agent's blackboard entries.

You now have a working blackboard: independent agents collaborate through one shared, semantic memory — no message bus, no second store.

Use it from your agent (framework-agnostic — this is the whole point)

A blackboard is just one shared table + post and recall, so any set of agents uses it with no framework lock-in:

REST / SDK — POST /v1/query/execute (any language), or @synapcores/sdk client.executeQuery(...). Each agent posts findings with the Step-2 INSERT and reads relevant peer contributions with the Step-4/5 SELECT. Different agents can be different processes, languages, or even different frameworks.
MCP (native, on by default) — point any MCP client (Claude Code, Cursor, a custom loop, a voice runtime) at ws://<your-instance>/mcp?token=<jwt> (JWT from one POST /v1/auth/login → access_token). The execute tool posts to the blackboard; the query tool recalls peer findings — agent collaboration as tool calls.
Any framework — OpenClaw agents, a LangGraph multi-agent crew, an AutoGen team, or a voice agent in the loop all share the same blackboard. The database is the brain; the framework is swappable.

Key Concepts Learned

A blackboard — one shared, semantic memory — lets independent agents collaborate without a message bus.
Tagging each entry with agent_role + confidence lets readers weigh who said it and how sure they were.
A coordinator can synthesize the whole board with one GENERATE() call.
Because it's plain data ops (SQL / REST / MCP), shared memory works for any mix of agents and frameworks — the agent-agnostic backend pattern this cluster builds on.

Multi-Agent Shared Memory (blackboard)