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:

Who is working on what      →  agents, tasks, claims
What changed                →  files_changed
What was decided            →  decisions
What evidence exists        →  evidence
What risks are open         →  risks
What was left for whom       →  messages, handoffs

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:

npx octopus-blackboard quickstart

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:

1. Paste the printed config block into the file it names.
2. Reload your MCP client (restart it, or reopen the project).
3. You're done. Ask your agent to call board_status, then board_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

npm install
npm run build      # compiles to dist/

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:

bash examples/two-agents.sh          # needs `octoboard` on PATH

CLI

octoboard init                                   # create .octoboard/ here
octoboard status                                 # who's on the board, right now

octoboard note "Codex is refactoring auth middleware"
octoboard claim trust-layer-policy-schema        # claim work; warns on conflict
octoboard message claude "Review policy edge cases before merge"
octoboard decision "Use hash-chain audit log" --why "tamper-evidence"
octoboard risk "Migration may break audit replay" --severity high
octoboard file src/auth.ts --change modified --task trust-layer-policy-schema
octoboard handoff claude "Tests pass except policy replay" --task trust-layer-policy-schema

octoboard timeline                               # the full hash-chained history
octoboard verify                                 # confirm the chain is intact

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:

⚠ CONFLICT: "trust-layer-policy-schema" is also held by codex. Both claims recorded.

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):

export OCTOBOARD_AGENT=claude OCTOBOARD_PROVIDER=anthropic \
       OCTOBOARD_MODEL=claude-opus-4-8 OCTOBOARD_CLI=claude-code

blackboard session start --label "auth work"   # captures machine, branch, repo
blackboard claim policy-engine
blackboard file src/policy.ts --change modified
# ... make a git commit ...
blackboard link HEAD                            # attribute the commit's files
blackboard session stop

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:

blackboard link HEAD --note
blackboard attribute <sha> --file src/x.ts --actor human --name Ran  # manual

Reviews

blackboard review HEAD --by ai   --name codex --outcome approved --note "tests pass"
blackboard review HEAD --by human --name Ran   --outcome approved

Querying the shared memory

blackboard who src/auth.ts             # git authors + AI sessions that touched it
blackboard who src/auth.ts --line 42   # which session introduced this line
blackboard explain HEAD                # attribution + reviews + related decisions
blackboard commits claude-code         # which commits came from an AI / CLI
blackboard unreviewed                  # AI commits never reviewed by a human
blackboard joint claude codex          # files modified by BOTH agents
blackboard timeline --session <id>     # per-session HH:MM timeline

Example explain:

commit 5fa3095…  Human Dev <a@b.c>  add auth
  produced by:
    ai claude [claude-opus-4-8] — src/auth.ts
  reviews:
    human Ran: approved
  git note: blackboard: produced by claude-code (claude-opus-4-8), session 75b2b7e7…

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:

agent work → commit attribution → export/import → CI check → human-review 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.