Where should a stack start?

With one tool against one piece of work that is genuinely painful, rather than with a plan for the whole thing. Stacks assemble from real problems, and a design produced before anybody has used anything tends to specify layers the work never needed. The plan becomes useful once there is something to plan around.

How many tools is too many?

The count matters less than whether anybody can say what each one is for. Five tools with clear jobs is a stack; five where two duplicate each other and nobody remembers why the fifth was bought is a licence problem. The useful test is what each would be missed for, asked once a year.

Should we standardise on one vendor's suite?

It buys administration, one relationship and fewer seams, and it costs you the places a specialist is better. Where the work is ordinary the suite usually wins; where one part of the organisation does something unusual it usually does not. Deciding deliberately is the point, since most organisations end up mixed either way.

What is the commonest gap in a stack?

Administration across it. Individual tools each have their own account list, and no single place shows who has access to what, so removing a leaver takes a week and answering a question about usage takes longer. That gap is invisible while nothing goes wrong and expensive at exactly the moment something does.

How do we decide what to consolidate?

By what the duplication is costing, not by the fact of it. Duplicate licences and confusion about where to go are real costs worth removing. Two tools that overlap on paper while being genuinely better at different tasks are not costing anything, and consolidating them tends to push the team that lost out onto something unapproved.

How much should the pieces be wired together?

Less than the integrations pages suggest. A proportion of the stack will be replaced within a year or two, and a tool that is easy to remove is worth something real against one that is deeply embedded. Connect where the connection saves genuine effort, and treat reversibility as a feature rather than as a lack of ambition.

Glossary

AI stack

An AI stack is the collection of AI tools an organisation runs together, assembled to cover the work it actually does rather than acquired as a single vendor's bundle.

In plain terms

Almost nobody buys one AI product and stops. A team ends up with an assistant for drafting, something that searches internal material, something that automates the repetitive steps, and often a specialist tool for one department that needed it. That collection is the stack. It usually arrives one purchase at a time rather than by design, which is why the interesting questions are about how the pieces meet rather than about any piece on its own.

Why it matters

Because the cost, the risk and most of the frustration live in the gaps rather than in the products. Each tool is separately defensible and the combination is where duplication, inconsistent data handling and orphaned accounts appear. Organisations that think in terms of a stack ask who owns the overlap and what happens at the seams; organisations that think in terms of purchases discover the answer later, usually when somebody leaves or an auditor asks a question nobody has a place to look up.

How it works

Most stacks assemble by accretion rather than design, and that is not a failure. A tool solves a real problem, somebody else finds a different one, a department buys a third. The result is a working stack that nobody planned, and the useful response is to look at what has accumulated and decide what belongs, rather than to imagine it could have been specified up front by people who did not yet know what the work needed.

Layers are a more useful frame than categories, because they describe where a tool sits rather than what it markets itself as. Something people talk to directly, something that reaches across your systems to find things, something that runs steps without a person present, and underneath all of it the models being called. Two products described identically on their websites often sit at different layers, and the layer is what tells you whether they compete.

The seams cost more attention than the pieces. What passes between two tools, who is allowed to connect them, what happens when one changes its interface, and where material ends up as a consequence of a link that seemed minor at the time. A stack is mostly its connections, and connections are the part nobody is assigned to own.

Overlap is normal and only sometimes worth removing. Several tools will do a passable job of summarising, and consolidating onto one is a real saving in licences and in the mental effort of knowing where to go. Consolidating onto one that is worse at the specific thing a team relies on is a false economy that gets rediscovered as unapproved tool use a few months later. The test is whether the overlap is costing anything beyond duplication.

The layer people forget is administration. Who can add and remove access across all of it, where usage is visible, whether one leaver can be removed everywhere in an afternoon. A stack of five tools with five separate account lists is a different proposition from five tools behind one login, and the difference is invisible until somebody needs to answer a question about it.

Stacks change faster than the organisations running them expect, which argues for looseness rather than for integration everywhere. A tool that is easy to remove is worth something over one that is deeply wired in, because a proportion of what you buy this year will be replaced. Reversibility is a genuine feature, and it competes directly with the convenience of tight coupling.

Several tools in a stack are usually calling the same small number of underlying models, which is invisible from the product names and matters in two ways. It means a provider having a bad day can degrade three of your tools at once, so a stack that looks diversified is not necessarily resilient. It also means the differences between those products are in what they do around the model, the interface, the material they can reach, the controls they offer, rather than in the intelligence itself, which is a more useful way to compare two that seem interchangeable.

The question that keeps a stack honest is what each piece would be missed for. A tool nobody could name the loss of is a licence rather than a capability, and it will keep renewing quietly. Asking the question annually is cheap and tends to remove more than any consolidation exercise does.

Two ways to read the same five tools

The distinction sounds like presentation and it changes what gets noticed. Read as a list, the obvious question is whether each tool is worth its price, which is answerable per tool and misses everything between them. Read as a stack, the questions become which two of these compete, what material moves across that link somebody set up last quarter, and whether one person leaving can be removed from all five in an afternoon. Those are the questions that turn out to matter, and none of them is visible in a list of purchases. It is also why consolidation exercises driven by the left-hand reading so often disappoint: they remove a renewal and leave the seams exactly where they were, so the organisation saves a licence and keeps every problem it actually had.

Seen in the wild

A general assistant for drafting and thinking through problems, which is where most stacks begin.
ChatGPT
A search layer that reaches across the systems the organisation already has, answering from internal material rather than the web.
Glean
An automation layer running the repetitive steps without anybody present, connecting the other tools to each other.
n8n
A workspace that holds the documents and light databases the rest of the stack answers from.
Notion AI

Common misconceptions

People assume

A stack should come from one vendor.

In fact

It is a legitimate strategy and it buys administration, one bill and fewer seams, at the cost of being weaker in the places a specialist is strong. Most organisations end up mixed because one part of the work is unusual enough to justify a specialist. Neither is wrong; what causes trouble is a suite bought for coherence and then supplemented anyway without anybody revisiting the reasoning.

People assume

Overlap between tools is waste.

In fact

Sometimes, and often it is just what happens when two teams have different work. Removing overlap is worth doing when it costs licences or confusion about where to go, and worth leaving when the tools are genuinely better at different things. Consolidation that takes a capability away from the team that needed it tends to reappear as people quietly using something else.

People assume

The stack is the list of tools.

In fact

It is the tools plus the connections plus the administration, and the last two are where the effort goes. A list of five products tells you almost nothing about whether the thing works; what passes between them and who can see across them tells you most of it.

Telling them apart

AI stack vs AI strategy

AI stack

What is actually running, including whatever arrived without a plan.

AI strategy

What the organisation intends, and what it has decided not to do.

The stack is observable today. The strategy is a claim about direction, and the two frequently disagree.

Questions

Where should a stack start?: With one tool against one piece of work that is genuinely painful, rather than with a plan for the whole thing. Stacks assemble from real problems, and a design produced before anybody has used anything tends to specify layers the work never needed. The plan becomes useful once there is something to plan around.
How many tools is too many?: The count matters less than whether anybody can say what each one is for. Five tools with clear jobs is a stack; five where two duplicate each other and nobody remembers why the fifth was bought is a licence problem. The useful test is what each would be missed for, asked once a year.
Should we standardise on one vendor's suite?: It buys administration, one relationship and fewer seams, and it costs you the places a specialist is better. Where the work is ordinary the suite usually wins; where one part of the organisation does something unusual it usually does not. Deciding deliberately is the point, since most organisations end up mixed either way.
What is the commonest gap in a stack?: Administration across it. Individual tools each have their own account list, and no single place shows who has access to what, so removing a leaver takes a week and answering a question about usage takes longer. That gap is invisible while nothing goes wrong and expensive at exactly the moment something does.
How do we decide what to consolidate?: By what the duplication is costing, not by the fact of it. Duplicate licences and confusion about where to go are real costs worth removing. Two tools that overlap on paper while being genuinely better at different tasks are not costing anything, and consolidating them tends to push the team that lost out onto something unapproved.
How much should the pieces be wired together?: Less than the integrations pages suggest. A proportion of the stack will be replaced within a year or two, and a tool that is easy to remove is worth something real against one that is deeply embedded. Connect where the connection saves genuine effort, and treat reversibility as a feature rather than as a lack of ambition.

Key takeaways

Stacks assemble by accretion, and that is normal rather than a planning failure.
The seams and the administration cost more attention than the individual tools.
Overlap is only worth removing when it costs something; a tool nobody can name the loss of is a licence rather than a capability.
Several tools usually call the same few models, so a varied stack is not automatically a resilient one.
Reversibility is a feature, because a share of any stack gets replaced.