Dropbox for Agents: a Git-Backed MCP Note Bus

The problem in detail

Everything an agent produces of lasting value — a debugging conclusion, a schema decision, a handoff note for the next agent — dies in the vendor's conversation log. Developers scroll back through chat history to copy snippets by hand, paste findings into human-oriented notes apps that agents can't read back, or hack shared state into whatever store both tools happen to touch (a package cache, a scratch file, a pinned issue). The knowledge belongs to the tool, not the person, and the second agent starts from zero.

Proposed product

A single-binary MCP server that gives every agent the same four verbs — write, read, list, subscribe — against a plain Markdown store in a Git repo the developer already owns. Each entry is a file with YAML frontmatter (author agent, project, tags, optional to: recipient) and a stable slug URL. Any MCP-speaking agent can drop a note; any other agent, or the developer via `drop read` in the terminal, picks it up. Because the backing store is Markdown in Git, the knowledge survives switching agents, is diffable, greppable, and reviewable in a pull request, and needs no hosted service or account.

Why now

Two separate issue-tracker reports establish the core pain from a non-community source: Claude Code's memory is described as individual-only with context that does not transfer at the agent level, forcing humans to manually reconstruct or relay it, and a second report describes context built up in Claude Code being invisible to Claude Desktop and vice versa, with no supported way to share persistent context across surfaces and machines. Practitioner write-ups describe the same loop — debug in one tool, switch to another, context gone — and one documents a subtler trap: two clients can both show a connected memory server and still share nothing, because of scoping and keying differences. So the problem is real and the naive fix is not reliably working. The caution is that the field is already crowded: an established Markdown/Git-backed MCP memory server with a hosted paid tier sits in nearly the same position, and several free OSS projects advertise cross-agent handoffs using nothing but markdown files. The opening, if there is one, is correctness of cross-client project scoping plus radical simplicity — not the basic idea of storing notes as Markdown.

Smallest useful version

Ship the MCP server plus CLI with two namespaces only: `notes/` (durable knowledge, append-and-edit) and `inbox/` (agent-to-agent messages, read-once then archived). Install is one command, config is one path to a Git repo. Success signal: developers add it to more than one agent's MCP config and it accumulates entries written by one agent and read by another within the first week — the cross-agent read is the whole test.

Potential ways to charge

• Free open-source core with a paid hosted sync/backup tier for developers who do not want to manage a Git remote themselves (mirroring the model the established competitor already uses)
• Team licence: per-seat monthly fee for shared team stores, access control over who can write to which namespace, and audit of agent-written notes in pull requests
• Paid self-hosted enterprise binary with SSO and policy controls for firms that cannot let agent knowledge leave their infrastructure
• Sponsorship/support contracts from teams depending on it, given the category is largely free and direct licence sales may be hard

Routes to early customers

• Comment on and link the existing vendor issue-tracker threads about shared team memory and cross-surface context, where people with the exact problem are already gathered
• Publish a write-up specifically on the documented failure mode — two clients connected to the same memory server sharing nothing — with the fix, aimed at the practitioners already blogging this scenario
• List in MCP server directories and the curated agent-memory lists where the competing OSS projects are already discovered
• Approach small teams running mixed Claude Code / Cursor / Codex CLI setups directly, offering to set up cross-client scoping for free in exchange for a week of usage data

Main risks

• Direct competition: an established Markdown-and-Git MCP memory server already occupies nearly this exact position, with Obsidian compatibility and a hosted tier, so a new entrant must win on something narrower than 'notes in Git'.
• Commoditisation: the evidence lists several free OSS projects doing markdown-based cross-agent memory and handoffs, making paid conversion doubtful.
• The riskiest assumption is untested — agents may not call write unprompted at useful moments, leaving the store either empty or full of chatter; if the human must say 'save this', it is a slower notes app.
• No demand signal was found in paid-work or search-volume sources, so willingness to pay anything is unevidenced.
• Cross-client scoping is itself the hard part; if project/repo keying differs between clients the product fails in exactly the way the evidence says others already fail.

Questions to test first

• Instrument a prototype and measure the unprompted write rate: over a week of real work across two agents, how many durable conclusions get written without the human asking?
• Run the same store against two different MCP clients on one project and verify both resolve identical scope — reproduce the documented failure mode, then prove you fix it.
• Install alongside the incumbent Markdown/Git MCP memory server for five developers and ask which they keep after a fortnight, and why.
• Post the cross-client scoping write-up and count installs and cross-agent reads, not stars.
• Ask ten users of free OSS agent-memory tools what, if anything, would make them pay — before building any hosted tier.

Evidence and sources

The sources this assessment is based on. Evidence level: Indicative, counted from these sources as described in how ideas are assessed. Findings are what a source shows; anything the research only inferred is marked as an inference.

Research findings

• SupportsGitHub issue (anthropics/claude-code #70072) · 23 June 2026

  Shows: issue-tracker report of cross-surface/multi-machine handoff gap

  A user reports that context built up in Claude Code (CLAUDE.md + auto-memory) is invisible to Claude Desktop and vice versa, with no supported way to give both surfaces the same persistent context across machines. Confirms the 'second agent starts from zero' symptom across surfaces and machines, the exact customer described.

• SupportsGitHub issue (anthropics/claude-code #38536) · 25 March 2026

  Shows: issue-tracker feature request on vendor repo confirming the problem from a non-community source

  A 'Feature Request: Shared Team Memory for Claude Code' issue states that Claude Code's memory system is individual-only and that context does not transfer at the agent level, so humans must manually reconstruct or relay it — described as slow, lossy and a major bottleneck for teams. This is direct issue-tracker corroboration of the candidate's core problem (agent knowledge trapped per-tool, copied by hand).

• SupportsDEV Community articles on shared memory over MCP across Claude Code/Cursor/Codex

  Shows: practitioner write-ups showing the cross-tool sharing workflow is actively sought and not solved by naive MCP setups

  Multiple 2026 practitioner posts describe the same scenario (debugging in Claude Code, switching to Cursor, context gone) and the fix of one shared MCP store; one post specifically documents that two clients can both report a connected memory server yet still share nothing because of scoping/keying differences. Suggests demand plus a real implementation pitfall the candidate must handle (consistent project/repo scoping across clients).

• Weakens the caseGitHub repos: daystar7777/agent-work-mem, awrshift/agent-memory-kit, eddmann/obsidian-mcp, YuNaga224/obsidian-memory-mcp; TensorBlock awesome-mcp-servers memory list · 17 August 2026

  Shows: crowded adjacent tooling field (multiple free OSS equivalents)

  A curated list plus several repos show many shipped options for markdown-file agent memory and cross-agent handoffs — e.g. agent-work-mem ('persistent shared memory and handoffs across Claude Code, Codex CLI, Cursor, Aider using nothing but markdown'), agent-memory-kit (plain files, session handoffs, Claude Code/Cursor/OpenCode/Codex), and git-backed Obsidian MCP servers. The category is validated but commoditised and largely free.

• Weakens the caseGitHub repo / MCP registry listing (basicmachines-co/basic-memory)

  Shows: direct competitor: established git/Markdown-backed MCP memory server with hosted upsell

  Basic Memory is an existing MCP server storing agent knowledge as plain Markdown files, described as local-first, Obsidian-compatible and git-versionable, usable from Claude Desktop, Claude Code, Cursor and other MCP clients, with a hosted paid tier for sync across devices. Occupies nearly the same position as the proposed product; differentiation would have to rest on the four-verb simplicity, single binary, recipient routing and subscribe verb.

Where the problem was reported

Public posts in which people described this problem, grouped into one problem before research began.

• Show HN: Open Agent Forum – a signed public square for agents · openagentforum.com · 31 August 2026
• Show HN: MaCcyP – coding agents push text to a clipboard manager's Agents view · github.com · 31 August 2026
• Show HN: OzBrain, a shared brain for knowledge between agents and your team · ozbrain.com · 21 August 2026

Looked for, not found

• Searches surfaced issue-tracker, vendor and blog sources but no job/freelance posting showing people paid to manually shuttle agent notes between tools, and no keyword-volume or app-store-review data quantifying demand for an agent note bus. Willingness to pay (versus using a free OSS markdown memory server) is therefore untested; the narrow four-verb, git-native framing remains a hypothesis about what buyers want.