Institutional memory in the model era

For most of my career, institutional memory meant insurance against people leaving: you captured what someone knew before the door closed and hoped somebody would read it later. The model era moves the load somewhere else. Agents are now doing real engineering work, and the quality of every next output is bounded by the context they can reach in the moment. The ceiling is now the input.

What counts as memory has changed too. A language model digests meeting transcripts and ticket histories without anyone structuring them up front, which used to be the whole problem and is now the easy part. A team's memory is no longer the wiki built five years ago and abandoned by year three; it is whatever a model can reach at the moment an agent (or the person on its other end) needs to make the next decision.

The thing that convinced me to act on this was small. We took the component library every engineer was already using and made it directly accessible inside their coding agent, one source wired to one consumer, and the quality of agent-generated UI lifted quickly enough to measure. Before the change, the agent invented components that did not exist or cheerfully rewrote ones we had already styled; after it, the agent reached for the right building blocks because they were sitting where it could see them. The library itself had not changed at all. We had only moved it into the agent's line of sight, and that was when I stopped treating institutional memory as a documentation problem and started treating it as an input layer.

The same shape repeats wherever an agent does meaningful work on a real ticket. With the right context, the agent ships what I have started calling a stable feature: code that follows the architecture and references the existing test cases. Without it, the agent ships plausible code that compiles and looks reasonable, which a senior engineer then has to wire into reality. The model is identical in both runs, so the entire difference is the substrate it was given.

So this year I am leading an organization-level program to build a single memory layer for the team that the agent reads from:

• Feature artifacts (specs and design files).
• Code and architecture.
• Test cases.
• Realtime signals (team chat, meeting transcripts).
• The project tracker.

I am holding the program to two targets:

• Coverage above ninety percent of active surfaces. Below that, the agent hits gaps and falls back to plausible code.
• Retrieval under five seconds. Slower than that and the developer reaches around the system instead of through it.

You will have work in progress here, and it is harder than it sounds.

Build order falls out of staleness, the rate at which each source goes wrong on its own. Cheap sources stay fresh as a byproduct of the work itself, while expensive sources start decaying the day someone stops maintaining them by hand.

• V1 (auto-maintained pair): the code repository and the project tracker. Every commit and every ticket update refreshes the substrate without anyone having to remember to do it. Start here, because the maintenance bill has already been paid by engineers doing their jobs.
• V2 (maintained-but-not-automatic pair): the documented surfaces and the realtime conversation layer. This is where staleness becomes the central design problem rather than a free win.

Every spec decays the moment the real decision moves. The spec gets written once, the actual decision lands in a chat thread, and nobody goes back to update the spec, because the person who made the call is already carrying it in their head and the only people the edit would help are future readers who are not in the room to ask for it. Downstream work, human or agent, goes sideways on the stale version. That is why realtime ingestion ships with V2 rather than after it; without the conversation layer, the documented surfaces are a collection of claims that were true at writing time.

Tool-side gaps shape the sequence further. Agents can sit on scheduled video meetings today, but not yet on the ad-hoc voice calls that happen inside team chat. So the lightest, fastest conversations, often the ones carrying the decision, still outrun your capture, and you compensate with team discipline (a one-line summary back into chat after the call) until the tooling closes the gap. At our scale, the problem is how fast volume goes stale, and how expensive it is to re-plug a source once it has.

Three things stay true no matter how cheap tokens get or how good the off-the-shelf connectors turn out to be:

• Selectivity. Do not ingest everything. Noise poisons retrieval, and the cost of context per query stays a real constraint because what you store grows at least as fast as per-token cost falls. The aggregator's job is to extract signal and decide which slice goes in for a given question, and most of that job is deciding what to leave out.
• Org-specific stitching. Your architecture and your coding guidelines encode judgment a general-purpose connector will not figure out by reading your tools; whether your database is read-optimized or write-optimized for the user base you serve is one example. Vendors will commoditize the plumbing in the next year or two, but the stitching stays the engineering manager's job, because no outsider can know how to weight a design artifact against a runbook for your team's particular question.
• The model is the shared interface. Engineers will increasingly read this substrate through a language model the same way agents do, because that is the cheapest way to read anything, so designing for the model as the reader covers everyone who will ever consume it.

You do not need an organization-level program to start. Pick one source that stays fresh on its own and one downstream consumer (the IDE agent, onboarding lookups, runbook search, code review) that will use it tomorrow, and wire that one path this quarter. The cheapest version is a small bridge from one source to one agent, and even that returns measurable lift, the same way the component-library bridge did for us. By the time the off-the-shelf tools land, you will have spent months learning what context your team needs them to deliver.