Octopus Blackboard
A shared memory and coordination layer for AI coding agents.
Agents do not need another boss. They need a shared blackboard.
Part of Octopus Core — the open infrastructure stack for governed AI. One job per repo, along the agent lifecycle: Scout · Observe · Experience · Blackboard · Workstate · Runtime · Replay — with Inspect governing every stage. The whole stack rides one root primitive — Evidence, the canonical, tamper-evident atom that is the root category everything is built on.
This repo — Blackboard · Coordinate: Shared cognition for coding agents.
Claude Code, Codex, Gemini CLI, Cursor, and your local agents all work on the same repo — but they are blind to each other. One refactors auth while another rewrites the same file. Context is scattered across CLIs. Nobody can replay what happened.
Octopus Blackboard is not an orchestrator. It does not schedule agents, trigger them, or decide anything on their behalf. It is a passive, local-first shared memory that answers six questions:
Every agent only needs to be able to read the board, write the board, leave messages, and attach evidence. That's the whole contract.
Why
Enterprises are not primarily afraid that agents aren't smart enough. They are afraid that:
- Multiple AI tools edit the same code simultaneously
- Context is scattered across different CLIs
- There is no shared memory, no audit, no handoff
- There is no conflict awareness and no way to replay
The blackboard cuts straight through this. Every write appends a
tamper-evident, hash-chained entry to an append-only timeline, so the
entire history is auditable and replayable — and any after-the-fact edit to an
earlier entry breaks verification.
Get Started in 2 Minutes
Blackboard is the easiest way into the Octopus stack — pure coordination memory that works today with just Claude Code and Cursor, no orchestrator required. One command sets everything up:
That single command: creates the local board (.octoboard/) if it isn't there,
auto-detects your MCP client (.claude/ → Claude Code, .cursor/ → Cursor,
… otherwise a generic snippet), prints the exact paste-ready config for it,
and proves the board works with one write + one read.
Then just:
- Paste the printed config block into the file it names.
- Reload your MCP client (restart it, or reopen the project).
- You're done. Ask your agent to call
board_status, thenboard_note "hello"— that's your first board action, on a shared, tamper-evident timeline.
Re-running quickstart is always safe: it never clobbers an existing board or
its history. New to the idea of adopting a coordination layer first? See
Why adopt Blackboard first.
Install
Requires Node ≥ 22. The board is a single SQLite file under .octoboard/,
discovered by walking up from your working directory (like .git).
See it in action
examples/two-agents.sh plays out the flagship
scenario — Claude Code and Codex sharing one board on the same repo: a claim
conflict, a live same-file collision, a decision, attribution, a handoff that
lands in the other agent's inbox, an AI review, the human-approval CI gate
(blocked → passes), the accountability scorecard, blame→narrative, and a
verified hash chain with session signatures. Run it in an empty directory:
CLI
Identity is set with --as <agent> or the OCTOBOARD_AGENT environment
variable. Point at a specific board with --board <dir> or OCTOBOARD_DIR.
Conflict awareness
The board never blocks — it surfaces. If two agents claim the same key, or touch the same task's files, both writes are recorded and the second agent is warned:
AI attribution & shared development memory
Git records who pushed a commit. It does not record which AI agent produced the code, in which session, on which machine, whether another AI reviewed it, or whether a human approved it. As AI-native development becomes common, accountability must move beyond Git authorship.
The blackboard adds an attribution layer on top of Git — it never rewrites history. Git stays the source of code; the blackboard becomes the source of attribution.
Sessions
A session is one continuous execution of an agent, and the unit attribution hangs off. Starting one makes every subsequent write attribute to it (the active session is remembered across CLI invocations, per agent):
Identity is fully provider-independent — --provider, --model, --cli, or
the matching OCTOBOARD_* env vars. Any AI CLI (local or cloud) can register
itself with no assumptions about a specific vendor.
Linking commits
blackboard link <rev> reads the files a commit touched (via Git) and records
one attribution per file for the active session. Optionally it writes an
additive git notes entry under refs/notes/blackboard:
Reviews
Querying the shared memory
Example explain:
Every attribution, review, session, and decision is also recorded in the
hash-chained timeline, so the full accountability history is tamper-evident
and replayable. blackboard and octoboard are the same command.
Governance & accountability chain
The point of attribution is to enforce something. The chain from work to a merge gate:
CI gate (check)
Turn queries into an enforceable gate. Read-only — it reports pass/fail and exits non-zero; the CI system decides what to do. The blackboard never blocks.
Portability (export / import / trailers)
Attribution is local-first; these make it survive git push into a team board
or CI:
import is idempotent (keyed by row id). The bundle carries attributions,
reviews, sessions, and related decisions.
Subscribe (watch)
Complete the read/write/subscribe/message contract. Passive: it polls and reports; it never pushes work.
Signed sessions (sign / verify)
Minimal identity (v0): each session gets an Ed25519 keypair (private key stays
local under .octoboard/keys/, gitignored). Signing the timeline head lets
verify distinguish trusted state from merely asserted:
A session auto-signs its head on session stop. A signature over a head becomes
stale the moment any earlier history is altered — so tampering is visible
even though the signature itself stays cryptographically valid. This is not yet
a full PKI (no key distribution or revocation).
Ingesting CLI transcripts
Populate the board from a CLI's session transcript instead of calling the API by hand — file edits, decisions, and notes flow onto the active session:
claude-code/codex/gemini/grok use a conservative tool-use JSONL
heuristic (it finds file edits from file_path/notebook_path and
patch/write tool calls). generic reads a normalized schema — the stable
integration path for any CLI:
Team backend
Boards stay local-first; sync shares the portable attribution records (never a board's private hash chain) into a team store — a shared file or Postgres.
export signs the bundle with your active session key; import verifies it and
import --require-signed refuses unsigned or tampered bundles — so imported
attribution has origin authenticity, not just id-dedup.
Tamper-evidence goes further than the in-DB chain if you anchor the head externally:
Liveness and compliance:
prune never touches the append-only timeline (the audit trail). redact
blanks the content across every read path — the timeline overlay and the
underlying source row (a message body, evidence note, etc.) so inbox/status/
the dashboard can't leak it — while keeping the hash chain valid. It is not
cryptographic erasure: the original summary stays in the timeline row so the
chain still verifies, so don't store secrets you must be able to destroy. For
tamper-evidence against an attacker with database write access, anchor the head
hash externally (a commit, a log, a second machine) — verify shows an
unanchored warning when it can't confirm the tail.
Tasks & kanban
Tasks are kanban cards — number, content, owner (which agent / CLI), project, blast radius, risk, and live progress. "Notifying an agent" is passive: assigning a task drops a "please look at task #N" message in that agent's inbox; the agent reads it and decides to act — the board never launches anyone.
The live blackboard serve dashboard — read-only, auto-refreshing. Each card
shows the task number, progress bar, assignees, active-agent count (⚡), project,
and a risk-coloured border.
The read-only serve dashboard renders these as a live kanban (columns by
status; each card shows number, title, a progress bar, assignees, active-agent
count, project, and a risk-coloured left border). Agents drive it via the MCP
tools board_task_define, board_assign, board_progress, board_tasks — an
agent calls board_progress as it works so the bar moves in real time.
Visibility
The dashboard is dependency-free (node:http), strictly read-only (non-GET is
refused), and auto-refreshes: live timeline, sessions, conflict/attribution
state, and the accountability scorecard.
MCP server — connect any CLI
The blackboard speaks standard MCP over stdio, so any MCP-capable client (Claude Code, Cursor, Codex, Gemini CLI, VS Code, Windsurf, …) can read and write the board. Generate the exact config for your client in one step:
Each prints where to paste it and the ready-to-use snippet, e.g.:
The agent identity defaults to the client name (so Cursor writes as cursor,
Codex as codex); override with --agent. The board is auto-discovered from
.octoboard/ in the working directory, or pin it with --dir. Two CLIs
pointed at the same .octoboard/ now share one board — that's the whole point.
Tools exposed — coordination: board_status, board_timeline, board_note,
board_claim, board_task_define, board_task, board_tasks, board_assign,
board_progress, board_message, board_inbox, board_handoffs,
board_decision, board_evidence, board_file_changed, board_risk,
board_handoff, board_heartbeat, board_since; attribution: session_start,
session_stop, board_link, board_attribute, board_review, board_who,
board_explain, board_blame, board_unreviewed, board_report; governance &
portability: board_check, board_export, board_import, board_trailers,
board_sign, board_trust, board_prune, board_redact, board_ingest. Each
accepts an optional agent argument to override the acting identity per call.
The recommended pattern: an agent calls board_status before starting work
to see what everyone else is doing, and writes as it goes.
Data model
| Layer | Tables | Purpose |
|---|---|---|
| Who is present | agents, sessions | provider-independent identity, session context |
| What's happening | tasks, messages, handoffs | coordination — claim, message, hand off |
| Who produced what | attributions, reviews | AI/human attribution & review, keyed by commit |
| Settled facts | decisions, evidence, files_changed, risks, timeline | auditable shared memory |
timeline is the append-only hash chain every other write also records into, so
the board and its audit log can never diverge.
Architecture
Status
Public beta (v0.3). Working today: local SQLite board, CLI (octoboard /
blackboard), MCP server, a verifiable hash-chained timeline, first-class
sessions, provider-independent AI/human attribution keyed to Git commits,
reviews, the query layer (who, explain, commits, unreviewed, joint),
the read-only serve dashboard, signed import/export bundles, retention,
redaction, quickstart, and MCP registry metadata/publishing workflow. Git
integration is read-only plus additive git notes — history is never rewritten.
Team sync supports a shared JSON file and a Postgres target for portable
attribution records; the board's private hash chain remains local by design.
Change subscriptions and deeper Octopus cross-repo bridges are still roadmap
work.
License
Apache-2.0 © Octoryn. See LICENSE.