DEV Community: Michael Boiman

Three months of running a consultancy out of a git repo our coding agents read

Michael Boiman — Wed, 30 Sep 2026 19:41:20 +0000

In June I wrote about the repo that stops my coding agent from forgetting everything overnight. Three months later the four of us at BKS-Lab run our daily work on it, and we run closed instances of it for other companies. This is what held up and what did not.

Some numbers from my own instance, measured on 24 September: 4,072 work-log rows since 4 July, 164 closed tasks, 2,426 commits since 20 June.

## What it is, in one paragraph

open-bridge is a git repo of markdown and YAML. Claude Code, Codex or Copilot CLI read it at the start of every session: which repos and clients exist, which tasks are open, what happened yesterday. There is no database and no service to host. When I say "good morning", the agent answers from those files: which client is mid-incident, what the next step is, what waits for review.

I run my whole working day from it: client projects, repos, my machines, mail, even the paperwork at home. From a meeting recording it writes minutes, tasks and a draft mail. It wakes my home server, checks that the backups are fresh, and tells me in the morning what matters today. It knows which client I am working for and which signature I write with, because all of that is a file in the repo.

## What held up

The daily log is the real memory. Every unit of work gets one row: date and time, a glyph, the project, what happened. Nothing clever. The morning briefing reads the last few days of it, and that removes most of the "where was I" friction. The rule that made it work: a row is written the moment the work lands, never batched at the end of the day.

One folder per task beats one big notes file. Each task has a STATUS.md with a small YAML header (status, priority, where it came from) and free text below. The board is generated from those folders and never edited by hand, so it cannot drift from the truth.

Private data and the shared template never touch. My data lives on a private user branch, the template lives on main. They use disjoint paths, so pulling template updates is a plain merge. A pre-push hook refuses to push the private branch to a public remote.

The agent proposes, I press the button. Mails are drafts, merges are mine, deletes need a yes. This sounds slow. In practice it is what lets me hand the agent real work.

## The part a notes vault does not cover

There are good projects that wire an Obsidian-style notes vault to a coding agent. They remember well for one person. Our problem was different: several clients, several roles, and a team.

One instance per company. Client data never sits in the same repo as another client's. The agent is the same, the instance it reads decides what it knows.

A shared layer for the team. Our company skills, accounts, projects and rules live in a separate overlay repo that every instance subscribes to. When someone new joins, they get a Bridge on day one that already knows our clients and our routines. Their own data stays on their own branch.

What we had to fix

Context grows until it hurts. After a few months, the files an agent reads before its first answer had quietly grown far past what anyone had decided to load. We now keep 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, the full entry fetched only when a name comes up.

"Where does this live?" became the most common question. So there is now a plain table that maps questions in everyday words to the file that answers them, and a check that every link in it resolves.

One size did not fit. Our first worked example was a two-client agency. The instance that got the most use belongs to one person wearing several hats: consultancy partner, freelancer, household, home server. That shape now ships as a second example.

Try it

You do not need to clone anything by hand. Copy the setup prompt from https://bks-lab.github.io/open-bridge/#get-started and paste it into Claude Code, Codex or Copilot CLI. The agent checks your tools, shows you its plan and waits for your go, creates your own private repo, and then walks you through onboarding: who you are, which repos and clients you work with, and a first briefing built from your own setup.

Want to look around first? The first option onboarding offers is a two-minute live demo: a fictional two-client agency with a P1 incident in flight. Say "good morning" there, and everything it answers comes from markdown files next to you.

The repo is MIT: https://github.com/bks-lab/open-bridge. The first outside contributions landed in the last two weeks: a GitLab tracker playbook, a French locale theme, and a tested Cursor setup on Windows. More good first issues are open if you want to help, for example a Spanish locale theme, a Jira or Linear tracker playbook, and testing the demo in Gemini CLI: https://github.com/bks-lab/open-bridge/labels/good%20first%20issue

The longer story of why we opened it: https://bks-lab.com/en/blog/open-bridge-open-source/

How do you keep a coding agent oriented across several projects or clients? What broke for you?

Your AI coding agent forgets everything every session. I fixed it with markdown and YAML.

Michael Boiman — Tue, 23 Jun 2026 12:53:04 +0000

Every time I opened a fresh session with my coding agent, it started from zero. Which repos am I working across? Which client is this for? Where did we leave off yesterday? I'd re-explain the same context, the agent would occasionally load the wrong project, and nothing I decided last week survived into this one. A "re-explain myself" tax on every single session.

I tried the obvious fix first — a better prompt, a longer system message. It didn't hold. Context that has to persist can't live inside the chat; the chat is the thing that resets.

What actually worked: give the agent a place outside the chat to read and write — and make it the most boring, durable thing I could. Plain files in a git repo.

The substrate: markdown + YAML the agent reads at session start

open-bridge is a plain git repo of markdown and YAML. At the start of every session the agent reads it, so it begins already knowing my world. No database, no SaaS, no daemon, nothing to host — the substrate itself runs nothing. It's just files the agent reads.

That "just files" choice is the whole point:

Agents can read a file but can't hold an API key. What I write today, the agent still reads in six months — no migration, no second app, no vendor lock-in.
It's auditable. Clone it and cat anything the agent reads. No black box.
It's model- and tool-agnostic. Plain text is something every agent runtime can read.

A tiny slice of what that looks like (from the repo's examples/agency setup — fictional "Acme Dev"):

# ecosystem.yaml — the repos/clients the agent should know about
projects:
  bigcorp:    { display_name: "BigCorp E-Commerce", repos: [bigcorp-api, bigcorp-frontend] }
  startupxyz: { display_name: "StartupXYZ MVP",     repos: [startupxyz-app] }

# work/board.md — generated from the task dirs, read every session
## Doing
| bigcorp-api-payment-retry | incident | P1 | Stripe webhook retries failing |
| startupxyz-onboarding     | feature  | P2 | guided signup flow             |

So when I say "good morning, briefing", the agent doesn't ask "GitHub or Jira?" or load the wrong client. It already knows.

Two things this gives you

I lean on two ideas — both honestly just names for behaviours the files enable:

Context that's always there. The agent reads a persistent, structured layer every session: your repos, your clients, your conventions, what you did yesterday. A third side beside the model and the tool. It stops asking, stops guessing, stops reloading the wrong thing.

Structure instead of a pile. Most of my AI work used to be a bare My-Documents folder — every conversation a fresh heap. open-bridge ships a plain-text work system: a board, a daily log, and per-task status (backlog → doing → review → done). Decisions and findings get filed as you go, in text the agent reads back later. Unstructured sessions become a filed, compounding record.

One convention, several agents

Because it's plain text, it isn't tied to one tool. A single skills/ tree is discovered by Claude Code, Codex, and Copilot CLI through the standard skill symlinks. The substrate stays the same; the agent on top is swappable.

Honest about where this is

The part I want to be straight about: it's one self-hosted instance — mine (built at BKS-Lab), with no external users yet. I'm sharing the method and the substrate, not an adoption story. The README is upfront about what's proven, what's a bet, and what isn't built yet. If you try it, I genuinely want to hear where it breaks.

Try it

20-second walkthrough (a real session, replayed): https://bks-lab.github.io/open-bridge/demo.html
Repo (MIT): https://github.com/bks-lab/open-bridge
There's a complete worked setup in examples/agency/. Clone it, open it in your agent, and ask it — without pasting any context — to summarize the repos, the clients, and how the task board is organized. That's the whole pitch in one prompt.

It's markdown and YAML. That's the entire trick — and kind of the point.