How Do Small Teams Share AI Context? Start With Decisions

Someone on the team proposes an approach. It is a good approach. It is also the one you spent two days evaluating in August and rejected for a reason that has not changed.

Nobody did anything wrong. The work shipped, the ticket closed, the summary was written. What did not survive was the part that took the longest: the options that were considered, the one that was chosen, and why the others were not.

This has always happened in small teams. What is new is where that reasoning now lives. It used to be in a meeting, a thread, or someone’s head. Increasingly it happens inside one person’s conversation with an AI assistant, and that conversation belongs to that person’s account. When the work is done, the reasoning goes quiet with it.

What actually disappears

Three things, and they are not the same thing.

The decision. What was chosen, stated plainly enough that someone can act on it without reconstructing the discussion.

The alternatives that lost. The approach that looked obvious and was rejected, with the reason. This is the single most valuable item and the one nobody writes down, because at the time it feels like something everyone knows.

The conditions. What would have to change for the decision to be revisited. Without this, a decision either gets treated as permanent long after it stopped making sense, or gets reopened every few weeks by whoever joined most recently.

Knowledge survives reasonably well in small teams. Code is in the repository, notes are in the tracker, the product exists. It is the reasoning layer that evaporates, and it is the expensive one, because rebuilding it means redoing the thinking.

Why the usual artifacts do not catch it

Commit messages describe what changed. Pull requests describe what the change does. Tickets describe what was asked for. All three record outcomes, which is exactly what they are for.

None of them have a natural place for the thing you tried and abandoned, because by the time the work is merged, the abandoned path is not part of the story any more. The rejected option leaves no artifact at all, unless someone deliberately makes one.

Standups have the opposite problem. The reasoning is spoken, so it exists for a day and lives afterwards only in the memory of whoever was listening.

What a decision record needs

Five lines is usually enough, and more than five tends not to get written.

What we decided. One sentence, in plain language.

What we rejected, and why. The reason matters more than the option. Too slow, too expensive, breaks something else, we tried it and here is what happened.

What we assumed. The facts that made this the right call, since these are what change.

When to revisit. A condition, not a date. When traffic doubles, when this client renews, when the tool ships the feature we need.

Where the detail lives. A link to the thread, the document, or the conversation, so somebody can go deeper without you having to write everything down now.

The whole thing takes three minutes at the end of a piece of work, and only if it is written while the reasoning is still fresh. Written a week later, it is already a reconstruction.

Where to keep it

Start with a file in the repository, or a single shared document if your team is not writing code. One file, appended to, in the place people already look. This costs nothing, needs no tool, and solves most of the problem for a team of two or three.

It also has a real advantage in the current moment: coding assistants and agents read files in the repository. A short decisions file gets picked up as context, which means the reasoning reaches not just the next person but the next agent.

Be honest about the cost. Someone has to write the entry, and someone has to keep the file from turning into an archive nobody reads. Teams that succeed at this keep it short and delete entries that stop mattering.

When a file stops being enough

Four signs, and they tend to arrive in this order.

The work crosses tools. Some of it happens in a coding assistant, some in browser chats, some in a document. A file in one repository is only visible to the people and agents in that repository, and carrying the rest across by hand, as in moving context between assistants, works for one person occasionally and never for a team weekly.

The people are not all technical. An account manager, a designer or a client cannot reasonably be asked to read a markdown file in a repository, so the decisions that involve them end up somewhere else, and now you have two sources of truth.

The volume outgrows one person’s head. A file works while somebody still knows roughly what is in it. Past that point, people stop reading it and start asking each other, which is where you were before.

You need to know the current state, not the history. A log tells you what was decided in March. It does not tell you what is true now, and reading the whole file to work that out is a cost that grows every month.

When several of those are true, what you need is not a bigger file. It is somewhere that keeps the decision layer visible to everyone and to the tools, organised by project rather than by where the conversation happened, with a clear line between what is current and what is history. Which form solves which problem covers what those options look like.

Two things are worth checking before you adopt anything for this. Whether you can see where a given answer came from, because a shared memory that cannot be traced becomes a rumour with a search box, and whether a source was actually used is a question teams hit as soon as agents read the same material. And what happens to the material if you leave the tool, since where those conversations live applies to team memory as much as to personal memory.

Until then, write the five lines. Most teams do not have a tooling problem yet. They have a habit that nobody has started.