Something quietly happened inside most teams over the last year. Everybody picked an AI assistant, and they did not all pick the same one. Ops uses one. Sales uses another. The engineer who helps out occasionally uses a third, inside their editor.
This is usually described as a standardisation problem, as though the fix is to pick one and mandate it. In practice nobody switches, because the assistant someone uses all day is bound up with how they think. The more useful question is what it takes for three people on three different assistants to produce one working tool instead of three disconnected drafts.
What goes wrong today
Watch how a small internal tool actually gets built across a team and the failure is always the same shape.
Someone asks their assistant for a dashboard and gets code back. They paste it into a message. A colleague opens it in their own assistant, asks for a change, and gets a modified version back. Now two versions exist and neither is running anywhere. A third person suggests a tweak in a thread, which nobody applies, because applying it means someone volunteering to be the person who holds the file.
Nothing here is a limitation of any assistant. Each one did its job. The problem is that the output of a chat is text, and text does not accumulate. Every handoff starts from a paste, so changes do not compose. The team ends up with a conversation about a tool rather than a tool.
The thing that has to be shared
The fix is not a shared assistant. It is a shared destination.
If the project lives in one place that all three assistants can reach, then each person keeps the assistant they like and the work lands in the same project. Person A adds a chart. Person B adds an alert to the same page. Person C changes the export. Three assistants, one artifact, one address.
That reframes what each person is doing. They are not producing a draft to hand over. They are making a change to something that already exists and is already running.
For that to hold, the shared destination has to provide four things:
- One live address. Not a file, not a snippet. A URL that shows the current state of the tool to anyone who opens it.
- Changes that compose. A second request has to build on the first, not replace it.
- A record of who asked for what. Three people changing one thing needs an audit trail or it becomes unmanageable.
- One budget, not three. A single ceiling for the project rather than per-person spend nobody is tracking.
Why history matters more than it sounds
The third item is the one teams underestimate, so it is worth dwelling on.
When one person builds something alone, they carry the context. They remember why the threshold is 40 and not 50. When three people build the same thing across three assistants, nobody carries it. The assistant has the conversation, but only its half, and only its own.
So the project itself has to remember. Every change wants to be stored with the request that caused it, in plain language, attributed to a person. Not a commit message written after the fact, the actual sentence somebody typed.
This is a familiar idea. Version control solved it for code decades ago, and the reasoning in the Git book's chapter on version control applies directly: the value is not the ability to store versions, it is the ability to understand and undo them. The difference is that here the meaningful unit is a request in English rather than a diff, because the person who made the change may not read code.
The practical test is simple. Someone should be able to look at the tool, see that the alert threshold changed on Tuesday because Sales asked for it, and put it back in one step without finding the person who asked.
What this looks like in practice
A concrete version, using a dashboard three people care about.
Ops asks for the page: signups by week, updated nightly, private to the team. It goes live at its own address. That URL is now the thing, and it is the only thing anybody needs to open.
Sales opens it, sees the chart, and asks their own assistant to split it by region. Not by describing the original request again, but by changing the project that exists. The page updates at the same address. Nobody shipped a new version of anything.
Finance asks for a Friday export. Same project, same URL, third assistant. The export appears.
At no point did anyone switch tools, paste code, or own the file. What made that possible was not coordination, it was that all three requests landed in the same place. The coordination problem dissolved rather than being solved.
The parts that still need a human
Two things do not get easier, and pretending otherwise would be dishonest.
Deciding what the tool is for. Three people can easily pull a tool in three directions until it does everything badly. Somebody still has to say no. Shared editing makes it easier to add things, which makes saying no more important, not less.
Reviewing before it matters. A tool several people have edited is a tool nobody has fully read. If it is going to inform a real decision, somebody should look at it properly first. We wrote about that habit in reviewing agent-built software before you ship it.
There is also a boundary worth naming. This works for internal tools with a clear owner and a tolerable failure mode. It is not how you build something customers depend on, where you want review, tests, and an engineer on call.
Settings worth getting right at the start
Two decisions are much cheaper to make up front.
Decide who can see it before it exists. Private to the team and public are different tools, and the moment to choose is before the link is shared. The tradeoff is covered in sharing an internal tool with your team without putting it on the internet.
Set one ceiling for the project. Shared editing means more requests from more people, which is exactly when an unbounded spend becomes plausible. One cap on the project, which no assistant can raise, is what makes it reasonable to let three people work without supervising each other. There is more on how to size that in AI agent pricing and budget caps.
Keeping configuration in the environment rather than hard-coded, as the twelve-factor guidelines recommend, also pays off here for an ordinary reason: when three people are changing one project, the settings should not be buried in whichever file somebody edited last.
The shift worth noticing
For two years the interesting question about AI assistants has been what one person can produce alone. That question is mostly answered.
The more interesting one now is what a group can keep. A tool that three people maintain together, each through the assistant they already prefer, is a different thing from three people each having a clever conversation. The first one is still there in six months.