Michael Boiman of BKS-Lab keeps his coding agent’s memory in a plain git repo, open-bridge, that Claude Code, Codex or Copilot CLI reads at the start of every session. In a post on DEV Community on September 30, 2026, he describes three months of running his four-person consultancy’s daily work on it, and what the team had to change.

On this page

What the setup is

The author describes open-bridge as “a git repo of markdown and YAML”, with no database and no service to host. The agent reads which repos and clients exist, which tasks are open and what happened yesterday, so a “good morning” prompt is answered from those files (post). The repository README names four pieces:

  • Registry: ecosystem.yaml, listing repos, clients and workspaces, read as a table of contents with one entry fetched on demand.
  • Task management: work/, with one folder per task holding a STATUS.md, a generated board and an append-only daily log.
  • Skills: one skills/ tree of commands such as /briefing, /debrief and /archive that every supported tool loads.
  • Standing orders: always-on rules in protocols/standing-orders/.

The repository is MIT-licensed (LICENSE).

What the author says held up

  • The daily log is the memory. Each unit of work gets one row with date and time, a glyph, the project and what happened. His rule: a row is written the moment the work lands, never batched at the end of the day. The morning briefing reads the last few days of it.
  • One folder per task beats one big notes file. Each task’s STATUS.md has a small YAML header (status, priority, origin), and the board is generated from those folders, never edited by hand.
  • Private data and the shared template never touch. His data lives on a private user branch and the template on main, on disjoint paths, so template updates are a plain merge. A pre-push hook refuses to push the private branch to a public remote.
  • The agent proposes, a person confirms. Mails are drafts, merges are his, deletes need a yes.

For his own instance, measured on September 24, he reports 4,072 work-log rows since July 4, 164 closed tasks and 2,426 commits since June 20 (post).

What the team had to fix

The author writes that the files an agent reads before its first answer “had quietly grown far past what anyone had decided to load”. The team now keeps a byte budget for that always-loaded part and CI fails when it is exceeded; everything else is an index, one line per repo or client, with the full entry fetched only when a name comes up. The README links the budget rules in docs/context-index.md.

A second fix: “Where does this live?” became the most common question, so the repo now has a table mapping everyday questions to the file that answers them (docs/where-things-live.md), with a check that every link resolves.

For teams, each client or company gets its own instance, and shared company skills, accounts and rules live in a separate overlay repo that every instance subscribes to (org overlays).

The demo, as the README gives it

The README ships a demo workspace, a fictional two-client agency, and gives these commands to open it with an agent CLI (README):

git clone https://github.com/bks-lab/open-bridge.git
cd open-bridge/examples/agency && claude    # or: codex, copilot

The README warns not to git push from this clone, because it points at the public repo. For a real instance, it recommends your own private repo as origin, with open-bridge kept as a read-only upstream; the full steps are in docs/install.md.

Where it fits, by the author’s account

The README says that for one repo and one person, a CLAUDE.md “is probably enough”, and that open-bridge pays off once you juggle several repos, clients or roles. It also states that the log and task status are “a convention it follows rather than a guarantee”, that its safety rules are conventions rather than an OS sandbox, and that the project “publishes no measured benefit numbers yet” (README).