How a small organisation gets its AI work to compound, when everyone already uses a different tool.
A working brief · July 2026
The symptom is always the same. Two or three people in the organisation are building genuinely good things. A cost model, a dashboard, a screening tool. Everyone else sits somewhere between curious and wary. Leadership can see the promise and can't see how it adds up to anything.
The cause is rarely skill. Each person builds inside their own account, on their own machine, against their own downloaded copy of the data. Nobody else can find the work, check it, or carry it on. When that person is on leave, the work stops. Two people rebuild the same thing without knowing. A number reaches a board paper and can't be traced back to where it came from.
Policy alone doesn't fix it. Plenty of organisations write an AI policy and find six months later that nothing has converged. A policy tells people what they may not do. It doesn't give them a shared place to work.
Everyone has built their own workshop in their own garage. Good tools, real output, nothing borrowable. The fix is a single shared workshop where people still bring their own hands and their own favourite tools, and the materials, the plans and the finished pieces sit on shelves anyone can reach.
Their preferred assistant, provided it runs on an account the organisation controls. People have trained these and switching carries a real cost, so don't force the brand. Do insist on the account.
One approved route into the systems of record, used by every tool, so nobody works from a stale download.
Written once, versioned, available to everyone whichever assistant they use.
What data may be reached, by whom, and what has to be checked before anyone relies on it.
The consequence worth naming early. Once the shelves are shared, whether the whole organisation should standardise on one assistant matters far less. That question stalls organisations for months. It is usually the wrong argument.
Free choice of assistant is the part everyone hears first, and it needs a qualifier or it becomes the hole in the middle of the design.
The condition is the account, not the brand. Anything that reaches organisational data runs on an account the organisation controls. A personal subscription fails this however good the tool, for four reasons: the organisation cannot see what was reached, cannot revoke access when someone leaves, usually cannot switch off training on the data, and has no contractual position if something goes wrong.
Provisioned by an administrator and revocable by one. Access ends when employment does, without anyone having to remember.
Contractually guaranteed, not a setting someone might toggle. This is usually the dividing line between consumer and business tiers.
The organisation can see what was accessed and by whom. Without this there is no audit trail and no way to investigate anything.
Clear terms on how long data is held and how it gets deleted, checked against whatever the organisation has promised its own partners.
What this means in practice. Someone who prefers a particular assistant keeps it, on the organisation's account rather than their own. Personal and free accounts stay disconnected from organisational data, whatever else people use them for privately. That single rule closes the shadow-tool problem, which in most organisations is a bigger exposure than anything the shared connections introduce.
The cost trade-off, named honestly. Supporting three assistants at business tier costs more than supporting one. The architecture does not force consolidation, but a budget sometimes does. That's a legitimate reason to narrow the list. Decide it on cost with open eyes, rather than on the mistaken belief that the data layer requires everyone to be on the same thing.
The connection standard went cross-vendor. The same connection into a document store or a database can now be called by any of the major assistants. Build the integration once and it serves whoever is using whatever.
Written capability became portable. The open format for packaging a repeatable task now runs across the major assistants and a long list of other products. Someone writes the monthly-report routine once, and a colleague on a different assistant uses it unchanged.
Neither was true two years ago, which is why the honest advice then was to pick one vendor and live with it. That advice is out of date. I'd expect the detail to keep moving, so treat specifics as current rather than settled.
This is the part organisations underestimate. The infrastructure is a few weeks of work. The habits are the engagement. None is difficult, and all six have to be real or the shelves stay empty.
Stop downloading a file and pasting it in. Ask the question against the live record. This habit makes everything else honest, because it removes the private stale copy nobody else can see.
If it took more than an hour and anyone else might want it, it belongs on the shelf. The test is whether a colleague could find it without asking you.
Most people keep their best prompts in a personal note. Moving them to the shared set is the cheapest win available, and it brings the lighter users along without training them.
Anything feeding a decision, a report, or a number someone will quote gets reviewed by one other person first. Not a committee. One person.
People need a written answer to "can I put this in there" that takes ten seconds to check. Without it they either freeze or guess, and both are bad.
Twenty minutes a fortnight. This populates the shelves. Organisations that skip this ritual end up with beautiful empty infrastructure.
Keeps the connections working, the shelves tidy and the rules current. Usually the most technical person available. Must be a named person with protected time. Ownerless setups decay within a quarter.
Holds the budget and unblocks access. Their real job is making the six habits legitimate, because habits change when leadership visibly follows them.
Already building. They populate the shelves early and their work becomes the proof this is worth doing.
Should never have to open the workshop directly. What sits on the shelves reaches them inside the tool they already use. If the answer to "how do I use that" involves technical instructions, the design has failed.
One shared place for prompts and builds. One or two live connections into the systems people actually use. The one-page rule on what data goes where. Move the top two or three existing builds onto the shelf. Start the demo slot.
The shared prompt set grows past a dozen entries. Review becomes normal rather than requested. Add the remaining connections. Revisit licensing once pooled usage and audit become the binding constraint.
Central control over access, cost and audit across all tools. Repeatable routines rather than bespoke builds. Outward-facing work, where the organisation advises others using what it learned internally.
Resist running early. The centralised control layer is built for organisations with many teams. For a group under about thirty people it usually adds administration before it removes any. Add it when the pain is specifically pooled cost, audit, or access control, and not before.
Non-technical staff are told to go and look inside a developer tool. They don't, and it quietly becomes the builders' private space again.
Months lost to a tool debate the architecture makes largely unnecessary, plus the goodwill cost of forcing people off something they have trained.
Connections break, nobody fixes them, people drift back to pasting copies. The most likely way this fails.
Everything is set up correctly and the shelves stay empty, because nothing made publishing normal.
A live connection to a poorly maintained record is worse than a stale copy, because it carries more authority. Data quality problems surface fast here and should be expected.
Someone other than the original author has modified a shared build. A person who called themselves a light user has used something they didn't make. At least one thing on the shelves was published by someone outside the builder group. And people have stopped asking whether they're allowed to put a given document into a tool, because the rule answers it.
Those four tell you more than usage statistics, which mostly measure enthusiasm rather than compounding.
Six questions. None needs a long process, and each of them stalls things if left open: which systems get connected first, what the data rule says, who the named owner is and how much of their time is protected, where the shared place lives, what has to be reviewed before others rely on it, whether individual tool choice stays open, and what an assistant has to meet before it may touch organisational data.
Happy to talk any of this through, or to walk an organisation through the first six weeks of it. aggarwal.shabnam@gmail.com