Research

When does a shared AI capability beat every team doing it alone?

Companies are introducing, adopting and using AI team by team. Each team picks a tool, tests it, learns where it fails and trains its people. Often several teams pay for the same lesson. This research asks, with small models we can solve exactly, when it pays to learn that lesson once.

The scarce resource is not only GPUs. It is specialist time, compute or vendor budget: whatever the next block of AI work would use. Model training is one important case. Choosing a service, testing it on your own documents, teaching people to use it and keeping it working when the vendor changes it are others, and in most companies the larger ones.

The bottom line

A shared route loses through three doors: its cost, compulsion and incentives.

For a single planner, a shared route that teams may ignore, that costs nothing to use and that knows at least what each team knows cannot lower value. A team can always ignore it. So when a shared route loses, it loses because it costs something, because teams are forced through it, or because of how people respond to its rules.

That last door is the surprising one. Once people respond to the rules, the comfort of "an extra option cannot hurt" disappears. In lesson 6, adding a genuinely better future option lowers total value, because teams see it coming and stop sharing what they know.

And a shared route wins only through something specific: one expert serving many teams, practice that compounds, a memory of failures, a fairer way to award scarce blocks, or paying for a backup everyone needs and no one buys alone. Each lesson names one such way and shows the case where it fails.

One design rule behind every model

Every model gives a capable local team the same information, people and rules as the shared route. So the two tie by construction, and a shared route earns no premium for being called "ACM". Any win must come from something the local teams cannot or will not do alone. This is a rule we chose for building the models, not a finding.

The spine

One inequality, and every lesson opens one of its terms.

With $n$ teams that share a need, each paying $d$ to do the work alone or $a$ to adapt shared work, the shared route is cheaper exactly when the saving per team, times the number of teams, beats the one-off costs of sharing: the shared work itself $f$ , coordination $q$ , waiting $w$ and the expected loss from shared failures $l$ .

Checked in Lean · sharing_threshold

n\,(d-a)\;>\;f+q+w+l

In words: what each team saves, times the number of teams, must beat what sharing costs once.

Lesson 1 sets out this sum. It is accounting, and it hides almost everything interesting inside its letters. The other nine lessons each open one of them and look at the choices people make there.

Lesson map

Ten questions, in order.

Lesson 1 · When does doing it once beat doing it n times?
$n(d-a)>f+q+w+l$ · Counts both routes: the saving per team times the number of teams, against the one-off costs of sharing.
Lesson 2 · Better expertise, worse fit
$d-a$ · Where the saving per team comes from: expertise widens it, mismatch narrows it.
Lesson 3 · How much shared work to fund, and where expertise should sit
$f$ · How large the shared investment should be, and whether depth in one person beats breadth in two.
Lesson 4 · When everything is P1
$q$ · Coordination becomes a game once teams compete for scarce blocks and can claim any priority.
Lesson 5 · What a record of failures is worth
$l$ · Failures learned once instead of once per team, and when a wrong record does harm.
Lesson 6 · Making the truth worth telling
$q\text{ and }l$ · What teams choose to report depends on what reporting earns them tomorrow.
Lesson 7 · Teaching people, then stepping back
$a$ · Support lowers the cost of adapting shared work, until teams can do it alone.
Lesson 8 · Generalists, specialists, queues and lulls
$w$ · Waiting: who is free when the work arrives, and what an idle expert costs.
Lesson 9 · Train, hire or contract
$f$ · The people part of the shared investment, against delivery today.
Lesson 10 · Who pays for the backup nobody needs today
$l$ · The loss when expertise leaves, and why nobody buys the insurance alone.

Notation

One letter, one meaning, across all ten lessons.

Every symbol on this site is defined once, here, and keeps its meaning everywhere. When a Lean file uses a different letter, the lesson says so beside the theorem.

Symbol	Meaning	Unit	First used
$n$	Number of teams with the same need	teams	Lesson 1
$d$	Cost for one team to do the work alone	illustrative units per team	Lesson 1
$a$	Cost to adapt the shared work to one team	illustrative units per team	Lesson 1
$f$	One-off cost of the shared work: building it and keeping it up	illustrative units	Lesson 1
$q$	Cost of coordinating: meetings, reviews, agreeing priorities	illustrative units	Lesson 1
$w$	Cost of waiting for the shared route	illustrative units	Lesson 1
$l$	Expected loss from failures on the shared route	illustrative units	Lesson 1
$x$	Expertise: the chance a job is done without a slip	between 0 and 1	Lesson 2
$x_0$	Expertise before any shared practice	between 0 and 1	Lesson 2
$b$	Mismatch: how far a method aims from what this job needs, after local tuning	error units	Lesson 2
$\sigma$	Size of a slip	error units	Lesson 2
$E$	Expected error of a route on a job	squared error units	Lesson 2
$\eta$	Learning speed in the alternative, exponential learning curve	per block	Lesson 2
${}_S,\ {}_L$	Labels for the shared route and the local route	labels	Lesson 2
$h$	Blocks of shared practice funded	whole blocks	Lesson 3
$H$	Blocks still available after committed work is protected	whole blocks	Lesson 3
$g$	The most shared practice could ever be worth, over the future work it can serve	illustrative units	Lesson 3
$c$	Useful work pushed out by one block of practice	illustrative units per block	Lesson 3
$G$	Learning gained minus work pushed out, before setup	illustrative units	Lesson 3
$j_1,\ j_2$	Future work each of two people will actually serve, weighted by what an error there costs	illustrative units	Lesson 3
$V_C,\ V_S$	Learning value when practice is concentrated in one person or split between two	illustrative units	Lesson 3
$B$	What the scarce slot is worth to the team that wins it	team’s illustrative units	Lesson 4
$\kappa$	Effort a pitch or claim costs the team, paid win or lose	team’s illustrative units	Lesson 4
$\rho$	Share of ideas that are strong	probability	Lesson 4
$p_{\text{strong}},\ p_{\text{weak}}$	Chance the test passes a strong idea, a weak idea	probability	Lesson 4
$V_{\text{strong}}$	What a funded strong project is worth to the company	illustrative units	Lesson 4
$\gamma$	What one test or check costs the company	illustrative units	Lesson 4
$s_{\text{strong}},\ s_{\text{weak}}$	Chance a strong team’s claim, a weak team’s claim, survives the check	probability	Lesson 4
$\varphi_{\text{strong}},\ \varphi_{\text{weak}}$	Expected penalty a strong team, a weak team, faces for claiming	team’s illustrative units	Lesson 4
$R_{\text{file}}$	Net credit a team earns for filing a record instead of claiming	team’s illustrative units	Lesson 4
$\beta$	Chance the test passes a case that no record covers	probability	Lesson 5
$\mu_{\text{strong}},\ \mu_{\text{weak}}$	Share of strong cases, of weak cases, covered by a correct record	share of future cases	Lesson 5
$\bar p$	Chance the other team both pitches and passes	probability	Lesson 5
$u$	Upkeep: the extra cost of keeping shared records correct and getting them to the next decision	illustrative units	Lesson 5
$\alpha_{\text{useful}},\ \alpha_{\text{useless}}$	Chance review accepts a useful diagnosis, a useless one	probability	Lesson 6
$p_{\text{new}}$	Chance a team’s new project passes its own gate	probability	Lesson 6
$\bar r$	Chance the rival also holds a usable credit	probability	Lesson 6
$V_{\text{new}},\ V_{\text{out}}$	What a passing new project is worth on average; what the ready outside work is worth	illustrative units	Lesson 6
$z$	What breaking a promise costs the sponsor	illustrative units	Lesson 6
$\Delta_{\text{today}}$	What filing rather than claiming gains the team now	team’s illustrative units	Lesson 6
$V_{\text{expert}},\ V_{\text{start}}$	What the expert state, the starting state, is worth to the team next round	team’s illustrative units	Lesson 6
$\pi_{\text{file}},\ \pi_{\text{claim}}$	Chance the shared memory becomes expert if the team files, if it claims	probability	Lesson 6
$\tau$	Chance a filed diagnosis transfers to the next decision	probability	Lesson 6
$p_{\text{learn}}$	Chance teaching or training makes a person able to do the work alone (also lessons 9 and 10)	probability	Lesson 7
$p_{\text{keep}}$	Chance the skill is still there when the next job arrives	probability	Lesson 7
$V_{\text{teach}},\ V_{\text{stay}}$	Value of teaching then letting the learner work alone; of leaving the expert on the work	illustrative units	Lesson 7
$V_{\text{alone}},\ V_{\text{advise}}$	Company value of a round where the ready team works alone; where support advises it	illustrative units	Lesson 7
$\theta$	What staying involved is worth to the support team itself, each round	illustrative units per round	Lesson 7
$v$	Value of one job done, over the local route	illustrative units	Lesson 8
$C_{\text{handoff}}$	Extra cost of handing a job from one person to another	illustrative units	Lesson 8
$C_{\text{broad}},\ C_{\text{spec}}$	Cost of reserving a generalist, a specialist, for the window	illustrative units	Lesson 8
$p_{\text{busy}}$	Chance the busy spell continues	probability	Lesson 8
$C_{\text{borrow}}$	Fee for borrowing a specialist for one date	illustrative units per date	Lesson 8
$V_{\text{plan}}$	Value of the plan named in the subscript: wait, hire, train, contract, record, teach, both, none, package (also lessons 9 and 10)	illustrative units	Lesson 8
$v_A$	Value of the learner’s own job today, over the local route	illustrative units	Lesson 9
$p_{\text{stay}}$	Chance the trained person stays, each date	probability	Lesson 9
$C_{\text{record}},\ C_{\text{teach}}$	Cost of one record, of one apprenticeship attempt	illustrative units	Lesson 10
$p_{\text{leave}}$	Chance the expert leaves	probability	Lesson 10
$C_{\text{admin}}$	Running cost of a compulsory shared route	illustrative units	Lesson 10

Words

The words we use, and only in these senses.

ACM: AI capability management: whoever runs the shared route. It can be one person, a small network of people or a team.
Shared route: Doing the common part of the work once, for several teams.
Local route: Each team doing the work alone.
Product team: A team that uses AI in its own work, such as Warranty Claims or Field Repair Dispatch.
Sponsor: Whoever holds the budget for scarce specialist time, compute or vendor spend, and decides who gets it.
AI Capability Manager: The person accountable for the shared route. Other ACM jobs (Portfolio Manager, Technical Owner, Prototype Owner) appear as it grows.
Model: A small piece of mathematics we can solve exactly. Never an AI model unless we say so.
Test: A real-world trial in a company. No test has been run for this research.
Value: Benefit minus cost, in illustrative units: numbers chosen to show a shape, not measured anywhere.
Payoff: What one team gains from a choice, counted in the same units.
Best reply: The choice that gives a team its highest payoff, given what the others do.
Stable outcome (equilibrium): A set of choices where no one can gain by changing only their own choice. Game theorists call it an equilibrium.
Strictly dominant: Better for a team whatever the others do. If a choice is strictly dominant for everyone, the stable outcome is forced.
Updating a belief: Reweighting what might be true after seeing a result: likely-under-this-story results raise that story’s weight.
Outside option: What a team or sponsor can get by walking away from the shared route.

What Lean is

A checked proof says the conclusion follows. It does not say the assumptions are true.

Lean is a program that checks every step of a proof. We write definitions, such as the cost of each route, and a claim about them. Lean accepts the claim only if every step follows from the definitions and the rules of logic. It does not accept "clearly" or "it is easy to see". If one step is missing, the file does not pass.

"Checked in Lean" therefore means one precise thing: the conclusion follows from the stated assumptions. It does not mean the assumptions describe your company. No model here has been fitted to data, and no number in a lesson is a measurement.

All the models use exact fractions, never rounded decimals, so a checked threshold is exact. The files use no unproved shortcuts and no outside mathematics library; each file asks Lean to list the axioms its main results depend on. They are checked with Lean 4.24.0, pinned to one release. Today the 14 files hold 556 theorems, counted from the source when this page is built. Many are small helper steps or concrete worked cases; they are not 556 findings about companies.

The interactive figures are drawn by separately tested JavaScript, not by Lean. The tests check that the figures reproduce the thresholds and worked cases that Lean checks. In each lesson, the theorem's exact statement sits behind a disclosure, with a link to the full source on GitHub.

How each claim is labelled

Definition: How we choose to measure something. Not true or false, only useful or not.
Assumption: A statement about the world we take as given, such as the shape of a learning curve.
Derived by hand: Follows from the definitions by algebra we did ourselves, without Lean.
Checked in Lean: Lean has checked that it follows; the theorem is named beside it.
Computed: Calculated by tested JavaScript for chosen numbers.

What is proved, what is not, what comes next

A proof closes a logical gap. Evidence closes a different one.

What Lean checks, lesson by lesson

Read every Lean file behind the lessons

Lesson 1 (CraftCosts.lean): The sharing threshold, the tie and the reversal for the cost sum, with two concrete cases: sharing that saves, and waiting that turns the saving into a loss.
Lesson 2–3 (ExpertiseScarcity.lean): Expected error splits into mismatch plus slips; the exact expertise-versus-fit threshold and a case where more expertise loses; one learning step stays between 0 and 1; the stopping rule for practice blocks finds the best whole number of blocks; the setup threshold; the exact point where concentrating practice beats splitting it.
Lesson 4 (ExpertiseScarcity.lean, StrategicPitch.lean): When claiming priority is free, claiming the highest priority is strictly dominant, so everyone claims it. With a costly pitch and a test, the exact range of pitch efforts in which strong ideas pitch and weak ones stay home. In a richer reporting game, the conditions under which truthful reporting is strictly dominant, alongside cases where reports pool.
Lesson 5 (AssessmentLearning.lean, AdaptiveExploration.lean): Records improve a later decision only when the lesson applies and is correct; wrong records and overhead can reverse the gain. An adaptive testing plan does at least as well as every feasible plan in its small model, and a plan built on the wrong assumptions about feedback can lose.
Lesson 6 (AccessCommitment.lean, RepeatedGame.lean): When a promise of future access makes truthful reports worth giving, and when the sponsor prefers to keep the promise. A way to check strategies over several rounds by testing one change at a time. A case where adding a genuinely better future option lowers total value.
Lesson 7 (PeopleDevelopment.lean, AdaptiveSupport.lean): A method that certifies the best training plan against every feasible plan; in a worked case, thresholds on how likely teaching is to work and how long the skill lasts. In two three-round support stories, neither side can gain by changing its own plan alone.
Lesson 8 (ACMStaffing.lean, WorkforcePlanning.lean): The best roster and schedule for given jobs, checked against every feasible schedule in a small case; hiring decisions when demand may or may not persist.
Lesson 9 (WorkforceDevelopment.lean): The best choice between training, hiring and contracting, checked against every feasible plan in a small model, including cases where training loses.
Lesson 10 (CapabilityContinuity.lean, PreservationInvestment.lean): The best plan for keeping, closing or reopening a capability, checked against every feasible plan. In the backup game, doing nothing is strictly dominant for each team, even though funding a backup together would gain; shared funding or binding cost sharing recovers it.

What is not proved

That the assumptions describe any real company. Learning speeds, slip sizes, test accuracy, costs and demand are all chosen, not measured.
That a shared route beats local teams in general. The tie between them is built in by the design rule above; each model only shows a specific way one can beat the other, and when it fails.
That the stable outcomes we describe are the only ones. In most games we check that a proposed outcome is stable; we rarely prove it is unique, and we do not study teams that randomize their choices.
Anything about real scheduling. Blocks of practice are assumed identical; real compute comes in shapes, with the right devices needed together, before a deadline.
That the separate models fit together. Each isolates one question; no single model of a whole company joins them yet.
That the JavaScript behind the figures is correct because the Lean files are. They are independent; tests tie them together.

What comes next: simulation, then real tests

A simulation could do what small models cannot: let the questions interact. The plan is to give rival arrangements exactly the same world — the same hidden opportunities, people, starting expertise, AI models, devices and surprises — and change only the rules for deciding. Then any difference in outcome comes from the rules, and we can trace which decision caused it: a lesson learned, a request never made, a queue at one expert, a missed deadline.

The core comparison crosses two choices. Do experts sit with product teams or together? Is scarce compute or budget split into local quotas or scheduled from a shared pool? That gives four arrangements. Product teams keep their own tuning and the final say on accepting results in all four. The local arrangements are allowed to share, to schedule competently and to learn; a comparison against a weakened local team proves nothing.

The simulation would first reproduce the exact cases in these lessons. Then it would vary how scarce resources are, how much future work there is, how far teams' needs differ, how well lessons transfer, how accurate tests are and what teams gain privately, and keep the cases where the shared route loses. The design and the analysis would be frozen before looking at which arrangement ranks first, and three kinds of uncertainty reported separately: the randomness of the simulation, the uncertain numbers fed into it, and the possibility that its structure is wrong.

Companies that buy AI as a service rather than train it need their own version. What is scarce there is calls, rate limits, vendor terms and the hours spent evaluating and migrating. Keeping the current model is always an option; switching to a newer one must earn its evaluation, migration and retraining costs.

The output would be a map of where a shared route helps, ties or loses, and why. It would not be a single number saying it works. After that, only real tests can say whether learning, reporting, costs and transfer behave this way in actual companies. None of this has been run yet.