Standing up an AI Builders team
You have been asked to stand up a small, deep group that builds AI capability for everyone else. The danger is quiet and common: an expert core that pulls away from a workforce that never changed how it thinks, shipping tools nobody adopts. Here is how to make the builders multipliers of the wider rollout, not a priesthood beside it.
An AI Builders team is a small, deep group that builds AI capability for the rest of the organisation: assistants, workflows, and the shared context everyone else reasons from. Stood up badly, it becomes a second AI culture, a technical lab whose output the workforce never adopts because it was built for a way of working that did not change. The fix is one reasoning discipline underneath both the builders and the broad rollout. The Havruta Methodology (formerly the Think Partner Methodology) gives the builders the same starting question as everyone else, whose bottleneck, not what can we build, so they build from real constraints and the things they ship get used.
The situation
Alongside the broad rollout, you have a second mandate: a small group of AI Builders, the people who go deeper than the rest, building the assistants, the automations, and the shared brains the organisation will reason from. It is the right instinct. Breadth alone leaves real capability on the table, and a handful of people who can build well multiplies what everyone else can do. The trap is structural. A deep technical squad, set loose to build, naturally optimises for what is interesting to build, drifts from the daily reality of the functions it serves, and ends up shipping clever tools into a workforce that still works the old way. Now you have two AI cultures: an expert core and everyone else, and the gap between them widens every sprint. The builders are not the problem. The absence of a shared discipline underneath them is.
The default move, and where it breaks
The default is to hire for depth and brief for output: assemble strong technical builders, give them a backlog of use cases, and measure them on what they ship. It feels like progress because things get built quickly. It breaks because the backlog is the wrong unit. A list of use cases answers "what could we build", which is almost always a long list, and skips "where is the human constraint actually throttling the business, and will solving it change how anyone works". So the team builds the buildable rather than the valuable, optimises for demos over adoption, and produces an estate of tools that look impressive and sit unused. The deeper failure is cultural: builders who reason one way and a workforce that reasons another cannot meet in the middle, and the capability stays trapped in the lab.
The Flip: build from the bottleneck, not the backlog
The move that changes the team is to give the builders the same first question as everyone else in the rollout, and make them answer it before they build. Not "what can we build with this", but "whose bottleneck is this, what does freeing it return against what it costs, and will the people on the other end actually reason with what we ship". That is the Flip applied to building: the machine, and the builder, interrogate the problem before producing the solution. It is the Bottleneck Principle turned into an engineering discipline, the unit of value is the human constraint, not the use case. A team that starts there builds fewer things and ships things that get used, because each one was aimed at a real constraint and designed for how the function actually works.
What a builders team must be built on
A builders team that multiplies the rollout rather than splitting off from it rests on a few non-negotiables. They are what keep the depth connected to the breadth.
-
One shared reasoning discipline: the builders run the same 4-Lines as the workforce, so depth is an extension of the common habit, not a separate language.
-
Bottleneck-first scoping: every build starts from a named human constraint and the return on freeing it, not from a backlog of buildable use cases.
-
Brains as the shared substrate: the team builds the persistent, verified context the whole organisation reasons from, not one-off bespoke tools.
-
Builders as multipliers: the team is measured on capability raised across functions, not on the count of tools shipped from the lab.
-
Ground Truth and guardrails: what the team builds is anchored in verified internal reality and governed, so trust scales with capability.
The distinction between what the team produces and how it is wrapped matters here. An agent is a wrapper; a brain is the substance. A builders team that ships agents leaves behind tooling that dates; a team that builds brains, the shared verified context functions reason from, leaves behind capability that compounds and that the broad workforce can actually use.
Operations wants an assistant that drafts their supplier emails. Let us build it.
Before we build, is drafting emails the bottleneck, or a symptom of one? Where is work actually piling up in that team?
Now you ask, the real delay is reconciling supplier data across three systems before anyone can write anything. The emails are the easy last step.
Then an email drafter solves the part that was never slow. The build that frees the constraint is a shared, verified view of supplier data the team can reason from. What is the cost of that reconciliation delay today?
Significant, and it touches three other teams with the same problem. One brain, not one bespoke tool.
Then scope the shared supplier-data brain, designed so those teams reason from it directly. It frees a real bottleneck and it is reusable, rather than a clever assistant for a step that was never the problem.
The builder arrived with a use case and left with a bottleneck. Same skills, same tools, a different first question, and the result is a reusable brain three teams will use instead of a bespoke tool one team might. That is the discipline that keeps the depth connected to the breadth.
What you are actually building
Not a lab that ships tools. A capability engine wired into the rest of the organisation. The difference is visible in what the team leaves behind and in whether the workforce can take it up.
- The goal
Shared brains aimed at real bottlenecks, on the common discipline
Adopted across functions Reusable Compounds - Built, not used
An estate of bespoke tools
Impressive demos Low adoption - The failure mode
An expert core that drifted from the workforce
Two AI cultures Capability trapped
The 4-Lines a builder runs before building
This is the discipline that keeps a builder aimed at the constraint instead of the buildable. It is the same four lines the rest of the workforce learns, pointed at the question of what to build.
-
Act as a sceptical head of the function this is for, then as a senior solutions architect. Hold both seats.
-
Goal: identify the real human bottleneck behind this request and the highest-return, most reusable thing to build for it, not the most interesting thing to build.
-
Ask me detailed questions before proposing anything: where work actually piles up, what it costs unsolved, who else shares the constraint, and whether the function will reason with what we ship.
-
One question at a time, step by step.
Frequently asked questions
What is an AI Builders team?
A small, deep group that builds AI capability for the rest of the organisation: assistants, automations, and the shared, verified context, the brains, that other teams reason from. It sits alongside broad workforce enablement and goes further, turning a handful of strong builders into a multiplier for everyone else. The risk is that it drifts into a separate technical culture, which is why it needs the same reasoning discipline underneath it as the wider rollout.
How do you avoid creating two AI cultures?
Put one reasoning discipline underneath both groups. When the builders and the workforce start from the same question, whose bottleneck and what does freeing it return, depth becomes an extension of the common habit rather than a separate language. The builders then build for how functions actually work, and what they ship gets adopted instead of admired. The gap opens when the core reasons one way and everyone else reasons another.
What should an AI Builders team actually build?
Build from bottlenecks, not a backlog of use cases. Each build should start from a named human constraint and the return on freeing it, and should favour reusable shared brains over bespoke single-team tools. An agent is a wrapper; a brain is the substance: the durable output of a builders team is the verified context functions reason from, which compounds, rather than tooling that dates with the model.
How big should an AI Builders team be?
Small and deep. The value is not headcount; it is a few people who can build well, aimed at real constraints and connected to the broad rollout so their work multiplies. A larger team scoped from a use-case backlog tends to ship more and change less. What matters is the discipline they share and the bottlenecks they choose, not the size of the group.
How does the builders team relate to upskilling the whole workforce?
They are two halves of one mandate. Broad upskilling that changes behaviour raises the floor; the builders raise the ceiling. They only compound when they share a reasoning discipline, so the brains the builders ship are ones the upskilled workforce already knows how to reason with. Built separately, each undercuts the other.
Where do we start?
Develop the builders through the Executive 1-1 Coaching Programme so they internalise the discipline, and run the broad cohorts through the Eye-Opener Workshop so the two halves share one language. A Strategic Briefing maps how depth and breadth fit together for your organisation.