Many minds.One memory.
Use agents that learn together and share a perfect recall memory complete with reasoning flows.
Use agents together. Share knowledge.
Work with perfect recall, track your organization’s decisions.
Understand the past and build reasoning flows to grasp what it’s built now.
Have better guard rails and tools, get better results.
Install deciduous and have a better time programming with agents.
The interesting part happens
between the terminals.
Ten agents built ten versions of Tetris. They read each other’s decisions, borrowed better ideas, and left a trail. Here’s one moment inside that run.
Scroll into the workThe idea travelled
before the code did.
Agent-8 spotted a lock-delay bug and wrote down the fix. Agent-7 read the reasoning and built it. Agent-8 hadn’t even committed yet.
Source excerpts, original timestamps. The observation landed at 04:47:15; agent-8’s commit followed 20 seconds later. In 1.0, took_from can make that credit a queryable edge.
“Why is it
built like this?”
A codebase you inherited has no graph. /decision-graph writes one from what the repository already says: the goals, the options, what was chosen, and every point where a choice was reconsidered. Then the question has an answer with a commit on it.
> /decision-graph ~/code/deciduous Reads every commit, not the first hundred, then the PR threads behind them, then the code. Writes what it finds to the shared graph as it goes. query_nodes(workspace: "deciduous", branch: "archaeology/storage") goal pending Several people and agents share one decision graph option pending Append-only event log, replayed on every clone decision superseded Sync through an event log committed with the code observation pending The log, a checkpoint and a patch export were three sync mechanisms, and replay left updates and deletes pending revisit pending Reconsidering: sync through an event log decision superseded One JSON file per node and edge in .deciduous/sync/, merged by a git driver observation pending A real graph was 2,781 files and 11MB on disk for 1.1MB of JSON; git status after a sync was a wall of paths revisit pending Reconsidering: one file per record decision superseded One graph.json, merged record by record on every git merge observation pending Two writable stores and nothing linking them: a CLI write never reached the server, an MCP write never came back revisit pending Reconsidering: the graph lives in the repository decision active One shared server holds the graph; agents write to it over MCP ask_graph("why is the graph one file and not a directory of records") observation A real graph was 2,781 files and 11MB on disk for 1.1MB of JSON; git status after a sync was a wall of paths 003f6f3: a PR touching the graph was hundreds of files in the diff.
commits read
pivots found
“A real graph was 2,781 files and 11MB on disk for 1.1MB of JSON.” That line is from 003f6f3, the commit that undid the per-record store. It is the answer to “why is the graph one file?”, and now it sits one hop from the decision it caused, instead of in a commit nobody will scroll back to.
Read what the command does
What it does not do
- infers
- It only knows what the history records. A commit that says what changed but not why leaves a guess in the graph; each node carries its commit so you can check.
- misses
- Reasoning that lived in a meeting or a chat never reached the repository, so it never reaches the graph.
- costs
- It reads the whole log and the PR threads. On a large repository, scope it to a path or a date range.
Five of deciduous’s own commits (0cbe88a, 58c46f7, a021aa1, 003f6f3, fe72239), written to the shared graph over MCP with add_node and parent_id, the calls /decision-graph makes. The listing is the real reply, condensed to type, status and title.
You can rewind
the reasoning.
A goal. Two possible loops. One choice, the work it led to, and the proof. Drag the playhead. The terminal and the graph move together.
These are agent-6’s graph writes. Each node and edge appears at the same replay moment as its terminal command. Rejected options stay attached to the decision.
56aa10e7 → 2cbc7ff1“Wait. Why did
we build it this way?”
A new session has none of the old context. The graph still has the decisions, the dead ends, and where the good ideas came from.
Pick a question. Trace the answer back to the agents who made the call.
Illustrative recovery session, grounded in the graph records from the original run.
A compacted context, a teammate’s bot, a repository nobody has touched in weeks: the graph can answer from what was recorded.
How the shared graph worksLooking is the point.
The collaboration started before the first line of code. Every agent inherited the same repository rules: read, borrow, improve, and leave credit.
# Tetris Arena Ten agents, one repo, one shared decision graph. Each of you builds a playable Tetris from nothing, in your own worktree, on your own branch. Looking is not cheating here. It is the point. Take what is better than yours, say where it came from, then make it better than that. ## Peeking: do it, on a schedule After every milestone, and before any real design decision: 1. check_activity: who is writing, on which branch. 2. query_nodes: decisions, no branch filter. 3. Read the code in the sibling worktrees. When you take something, log an observation: “Took X from agent-M because Y; changed Z.” Link it to the action. Say it in the commit.
playable games
graph nodes
borrowed ideas, credited
branch lock conflicts
Twenty-eight minutes. One finding about hidden rows reached eight other branches.
The experiment includes what broke, too.
What was actually in each agent’s environment?
- worktree
- Its own checkout and branch. Locks are per branch, so sessions do not interleave writes on the same branch.
- MCP
- Shared graph tools inside the session: add_node, add_edge, query_nodes, check_activity. Each call carried workspace: “tetris-arena” and branch: “agent-N”.
- ../agent-M
- Every sibling worktree was readable. Agents could inspect each other’s code before and after commits.
- opening prompt
- “You are agent 7 of 10 in the tetris arena. This directory is your worktree, on branch agent-7. Read CLAUDE.md here and follow it exactly. Begin.”
- permissions
- The experiment ran with permission prompts off. This describes the run, not a prerequisite for using Deciduous.
Condensed excerpt of the original repository rules. The numbers describe this experiment, not a promised result for every run.
Connect over MCPGive the next
agent a head start.
Set up shared Postgres memory, then connect your agents to one workspace. Start on your laptop and move the service to a remote host when you need it. The Rust CLI keeps a local cache; the HTTP MCP service handles shared writes.
$ brew tap notactuallytreyanastasio/tap $ brew install deciduous # Next: start Postgres and connect your agents # https://deciduous.dev/tutorial/local-postgres.html # Existing graphs? Back up before migrating # https://deciduous.dev/tutorial/upgrading.html