Coding agents across several repos

2026-11-025 min read

Three databases, two of them shared

You probably have more than one repo: the API, the web app, the mobile app, a shared library, an infrastructure repo. The interesting changes touch two of them at once. The pieces split like this:

• A project board per repo. Tasks and memory (decisions, conventions, findings, questions, handoffs) belong to one codebase, so each repo gets its own database from the project template.
• One sessions database for the account. Every session, in every repo, registers in it with a scope that names its repo.
• One learnings database for the account. A fix for a flaky wrangler or npm error helps in every repo, so it's shared.

How an agent knows which board is this repo's

By the line in the repo's CLAUDE.md or AGENTS.md. Each repo names its own board:

Shared memory: databasedmcp database `acme-api` (project template). Run get_database on it at the start of every session and follow its guide.

That's a convention, not something the server checks. A project database doesn't know which repo it belongs to, so name boards so they can't collide. The project prompt defaults to the repo's directory name, and two repos both checked out as web would end up sharing one board. Name it after the owner and repo instead, acme-web and acme-api. Put the remote in its description, so list_databases tells an agent what each one is.

Sessions are scoped by the git remote

The sessions guide has each session register with a scope: the repo as host/owner/name from git remote get-url origin, like github.com/acme/api, with no protocol, user or .git. A repo without a remote gets a short slug. Two checkouts of the same repo, on two machines, share a scope; two repos never do.

A new session's Start read lists only open and recent sessions in its own scope, so an agent in the web app isn't distracted by the API. To see every repo at once, the guide has a read across scopes:

SELECT scope, count(*) AS sessions, max(started_at) AS latest, group_concat(DISTINCT job) AS jobs FROM sessions GROUP BY scope ORDER BY latest DESC LIMIT 20

Reaching across: a change that spans two repos

The web app needs a new API field. The agent in acme-web can read acme-api's board like any other database on your account. Before relying on the API, it looks up what's been decided about the area:

SELECT id, kind, title FROM current_memory WHERE paths LIKE ?1 OR title LIKE ?1

If the field doesn't exist yet, it can add a task to the API's board, with land paths in the API repo, for whichever agent works there next. If an agent is working on the API right now, it finds that session across scopes and sends it a message addressed to its topic:

SELECT id, status, scope, topic, goal, next FROM session_status WHERE status IN ('active', 'waiting', 'idle') AND (scope LIKE ?1 OR topic LIKE ?1 OR goal LIKE ?1) ORDER BY seen_at DESC

The messages article covers sending, priorities and receipts.

Learnings stay general

A learning records where it applies (an OS, a version, a repo) and is empty when it applies everywhere. Before using a fiddly tool in any repo, an agent checks what's known about it:

SELECT id, status, problem FROM current_learnings WHERE tool = ? ORDER BY hits DESC, id DESC LIMIT 20

The learnings article covers searching by error text and recording fixes.

Copy this prompt to set it up

Run this once in each repo. The sessions and learnings databases are created the first time and reused after that.

Set up databasedmcp for this repo, in one go.

1. Project board: name it <owner>-<repo> from git remote get-url origin (lowercase, hyphens), so it can't collide with another repo's board. If list_databases doesn't show it, create it from the project template with the remote URL (no credentials) in its description. Read its guide and follow it.
2. Sessions: if there's no "sessions" database, create it from the sessions template. Read its guide, run its Start read for this repo's scope and register this session.
3. Learnings: if there's no "learnings" database, create it from the learnings template and read its guide.
4. Add these lines to CLAUDE.md (and AGENTS.md if there is one), with the board's real name:
   "Shared memory: databasedmcp database `<board>` (project template). Run get_database on it at the start of every session and follow its guide."
   "Sessions: register in databasedmcp database `sessions` at the start of every session, checkpoint as you go and end before you stop, following its guide."
   "Learnings: when a tool or command fails, search databasedmcp database `learnings` by the error text before retrying."
5. Show me every repo's board and the scopes in the sessions database.

What it doesn't do

databasedmcp doesn't look at your repos, so it can't tell which board belongs where. The CLAUDE.md line and the board's name do that, and the scope is whatever the agent reads from git. Repos aren't walled off from each other either. Every agent on your account can read and write every database. That's what lets the web app's agent read the API's decisions. It's also why work you need kept apart, like a client's repo, belongs on a separate account.

Create an account