Stop being the answer to every question

1Shared context

One repository everyone writes to, in plain Markdown, so it survives whichever coding agent you are using this year. Most of the work is structural: a short routing file at the root instead of an encyclopedia, and a two-line index in every folder saying what is in there and when to read it.

Those indexes decide whether an agent answers your question or reads your entire filesystem looking for the answer. Gupta and Stulberg report a customer query resolved on about 3% of the context window, with the analytics and engineering folders never opened. The same arithmetic governs what you store, since a one-hour call transcript runs to roughly ten thousand tokens and a structured summary of it to five hundred. Summaries go first and the raw material sits one folder deeper.

2Shared queries

A repository nobody queries is a filing cabinet. Most teams land first in the arrangement where one person answers on everyone else's behalf, which is the bottleneck the repository was meant to remove.

Getting past that is a habit rather than a feature, and the tactic that works is unglamorous: when someone asks the hub person a question in a group chat, the hub tags the agent in public instead of answering, and everyone watches the answer come back out of the repository. Whether it takes depends on there being a second group of genuinely interested people. Below that, adding more content changes nothing.

3Shared discipline

None of this is memory. The agent starts every session from nothing, so only what somebody wrote down persists, and a repository that has quietly stopped being true is worse than no repository at all because people still act on it.

Three things need agreeing before anyone writes: who owns which area, what rule decides that a piece of work is finished, and what automated check will tell you the documents and the code have drifted apart. The blunt version of the middle one is that a feature is not rolled out until the repository is updated. Agreeing all three afterwards is much harder, because by then people have filled the place with content in whatever shape occurred to them.

The resistance is not technical

Someone whose standing on the team rests on being the only person who knows how a thing works has a real reason to slow a shared knowledge layer down, and no tooling decision touches that. It is handled by who you recruit first, by crediting contributions in public, and by not attempting it alone.

For everyone else the bar turns out to be far lower than it looks. On Stulberg's team, a strategy partner who had never opened GitHub was putting up pull requests daily two months later.

Nothing to install

The structure is public, the templates are open source, and so is most of the tooling. What is not public is the part that decides whether any of it lasts: which conventions your organisation will actually keep, who writes first, and what happens when somebody doesn't.