In a team
Everything so far is written for one person. With eight, the problem changes: covering the six disciplines yourself is not enough if nobody else does, because the code they merge is your code too.
The unit of adoption is the repository, not the person.
Three layers, one rule each
Before picking tools, decide where each thing lives. Most adoption problems are problems of location, not of product: something that belonged in the repo ended up on somebody's laptop. The tools filed under each layer are filed by where their configuration and state default to living, not by where the software runs — a protocol runs on your machine and its configuration still belongs in the repository.
- 01Personal
Your machine
Your shortcuts, your style preferences, your session history, the harness you like using.
- The rule
- If someone else needs it to do their job, it cannot live here.
- How it rots
- It turns into tribal knowledge. "Works on mine" stops being a phrase and becomes the team's architecture.
Configured per machine. Nobody inherits it.
- 02Repository
The repository
The instruction file, the skills, the hooks, the types, the tests, the specs. Everything versioned alongside the code.
- The rule
- If you want it to apply to everyone without telling anyone, it goes here. It is inherited on clone.
- How it rots
- Configuration nobody maintains, which people quietly disable because it gets in the way more than it helps.
Its configuration travels with the code. Whoever clones it, inherits it.
- 03Team
The team
Architecture decisions with their reasons, agreed conventions, shared memory, spending budgets.
- The rule
- Only what will still be true in six months, and only if someone owns retiring it when it stops being true.
- How it rots
- Noise. A hundred saved observations none of which can be contradicted, and two that contradict each other unnoticed.
What scales and what does not
What follows is not an opinion about products. It is a test: what scales is inherited without anyone having to be told, and what fails depends on each person remembering.
Scales
Hooks and deterministic gates
They run the same on everyone's machine and in CI. They do not depend on anyone remembering, and they cannot be talked round.
Skills versioned in the repo
A procedure written once that every agent on the team loads identically. Reviewed in the pull request like any other file.
Specs as an artefact of the change
It gives review something to compare against other than the reviewer's opinion of what was probably wanted.
An installable configuration preset
A new joiner reaches the same environment with one command. If setup takes half a day, half the team skips it.
Strict types and a suite that runs in CI
The verification that does not require a human to be paying attention at the right moment.
Does not scale
The master prompt circulating on Slack
It is born stale, gets copied wrong, and nobody knows which version is current. It is a skill without version control.
A different MCP stack per person
Each developer gives their agent different capabilities, so the same request produces different results. Reviews stop resembling each other and nobody knows why.
Shared memory with no curator
It fills with session history and expired decisions. It ends up a place where the agent can find confirmation for anything.
Measuring AI-generated lines
It rises exactly as the problem gets worse. It is the metric that rewards the behaviour you are trying to correct.
Expecting adoption because it is better
With no owner and no time allocated, configuration ages. Nobody wakes up on a Tuesday wanting to maintain someone else's hooks.
Who holds it
You do not need new job titles. You need owners. All three of these can be split among people you already have, but if none of them has a name, all three decay — slowly, which is the worst way.
Configuration owner
- What they own
- The team preset: hooks, skills, instruction file, what gets installed and at which version.
- Sign nobody holds it
- Every developer has a different setup and reviews do not resemble each other.
Memory curator
- What they own
- What enters shared memory, what gets retired, and what to do when two decisions contradict each other.
- Sign nobody holds it
- Two opposing decisions about the same thing are saved and nobody knows which one holds.
Budget owner
- What they own
- Which model is used for what, how much a review may cost, and what gets cut when it is exceeded.
- Sign nobody holds it
- The monthly bill surprises somebody.
The hard case: shared memory
Of the six disciplines, memory is the only one whose team version is a genuinely different product from its personal version. That makes it worth working through with a concrete example.
Engram, the memory tool in the catalogue, stores on your machine by default. It also has a shared mode — `engram cloud` — which is opt-in, enrolled project by project, and can run on your own infrastructure against your own Postgres. That last part is not a detail: if team memory holds why a vendor was rejected, that database is business information.
The most common mistake is treating shared memory as a backup of personal history. It is not. Your session history is noise to everyone else: it holds your false starts, your reversals and your style preferences. Dumping it into team memory gives nobody context — it gives everybody eight versions of the same argument with no way to tell which one won.
And there is a failure that only shows up once several people are writing: memory contradicts itself. Two people save opposing decisions about the same thing, weeks apart, and both entries stay. The agent reads both and picks one. Engram ships a `conflicts` subcommand precisely to surface those relations, which confirms the problem is real and does not resolve itself.
The underlying rule: a stale decision is worse than no memory at all. Absence forces you to ask. Out-of-date memory answers confidently and is wrong. Retiring entries is as much of the work as saving them.
Who owns all this
The question nobody asks until it is too late. It is not about software licences: it is about what you produce by working this way, where it ends up, and what happens the day you change provider — or the day the provider changes without asking you.
Start with the part your provider already settles: the code that comes out is yours. Serious providers assign whatever rights they hold in the output, and in practice generated code resembles what anyone would produce solving the same problem with the same libraries. If your lawyer needs the detail, it is in the terms of service of whichever provider you use; do not go looking for it in a blog post.
What is in dispute is everything else. Working this way produces assets that are not code: the decisions and their reasoning, an index of your repository, the rules the team has accumulated, the procedures that already work. That is capital, and almost nobody treats it as such.
The test is simple, and it is the same one applied to every tool in the catalogue: if you switch agents tomorrow, what survives? What lives in a file in the repository survives. What lives behind an open protocol survives. What lives inside a product that only speaks to one agent does not — and on the day you migrate you will find you were not building an asset, you were renting a convenience.
Then there is what leaves your machine, which is a different question from ownership and is worth not mixing in. With a hosted model, the context assembled for each request goes to the provider — the files it read, what you pasted, what your rules say. Not the whole repository at once, but over a working day, a good part of it. That is not optional, it is how this works: the only way out is running the model yourself, and you pay for that in hardware. What is optional is how much more goes, and where. Every tool you connect is another destination. Every memory service is a copy of your decisions on somebody else's infrastructure.
None of this is an argument for using nothing. It is an argument for knowing what you chose. A team that can answer these four columns from memory made a decision; a team that cannot accepted whatever was the default.
The generated code
Where it lives
Your repository, like any other commit.
What leaves your machine
Every time you ask for something: that task's context travels to the model provider. That is not optional, it is how this works.
You control it if
It lands in your repository and nothing the provider controls is needed to build or run it. The rights question is a separate one, settled in your provider's terms — verify it there, not in a blog post.
The decisions and their reasoning
Where it lives
Up to you. A file in the repository, a memory service, or the heads of three people.
What leaves your machine
A hosted memory service keeps them on somebody else's infrastructure — that is what you are paying it to do. It is a copy of how your team thinks, sitting somewhere you do not administer.
You control it if
You can export them and read them with another agent. If only the product that stored them can read them, they are not an asset: they are a subscription.
The code index
Where it lives
A folder in the project, generated from your own code.
What leaves your machine
Nothing, if the index is built locally. Everything, if you hand indexing to a remote service.
You control it if
It can be rebuilt from scratch out of the repository. An index that cannot be regenerated is a dependency dressed as a convenience.
The rules and procedures
Where it lives
Versioned files, reviewed in the pull request like any other change.
What leaves your machine
They enter the window every session, so they travel exactly as the code does. If they hold secrets, the secrets travel.
You control it if
They are written in plain text and live in the repository. The most portable asset of the four, and the cheapest to build.
What to measure
Almost everyone gets this wrong, and wrong in the same direction: they measure production when the bottleneck is verification. Generating code got cheap; reviewing it did not. Measuring the first makes you optimise the part that was already cheap.
Measure this
- Time from a pull request opening to somebody understanding it.
- Rework: what share of merged code is touched again within two weeks.
- Defects reaching production, compared against before.
- How long a new joiner takes to merge their first change unaided.
Do not measure this
- Lines generated by AI. It is a number that rises as the problem gets worse.
- Share of code written by the agent. It cannot tell good code from code you are about to delete.
- Prompt or session counts. That measures activity, not outcome.
- Suggestion acceptance rate. It rewards exactly the reflex you are trying to remove.