Do you really need 14 different AI tools?

Businesses spent the first phase of the AI boom adding tools. The next job may be working out which ones they actually need.

It starts innocently enough. Someone gets ChatGPT. Another person prefers Claude.

Microsoft adds AI to something you're already using. The marketing team finds an AI writing tool. Someone discovers an amazing research tool.

Meetings get their own AI assistant. Then there's an image generator. A presentation tool.

A coding assistant. An automation platform with AI built in. Your CRM announces its AI.

Your project-management software announces its AI. Your accounting software probably won't be far behind. Individually, each decision can make perfect sense.

Then one day you look around and realise: How many AI tools are we actually paying for? And perhaps more importantly:

Why?

We've been buying AI by feature

This is understandable. The first few years of generative AI have been dominated by visible capabilities. This one writes.

This one researches. This one creates images. This one records meetings.

This one helps with code. This one searches documents. This one builds agents.

So businesses have tended to buy the capability through the product that demonstrated it best. But those capabilities increasingly overlap. The writing tool researches.

The research tool writes. The chatbot analyses documents. The meeting tool drafts follow-ups.

The CRM summarises calls. The automation platform can call an AI model directly. And the software you already use keeps adding more AI.

Eventually the question changes from: Which AI tools should we add? to:

Which capabilities do we actually need, and where should they live?

Start with what people are actually doing

I'd begin with a very unglamorous exercise. List the AI tools being used across the business. Not just the ones IT or management officially bought.

Ask people. You may find: personal subscriptions,

free accounts, browser extensions, AI features inside existing software,

department-specific tools, experimental accounts, developer tools,

and services somebody signed up for six months ago and forgot about. Then, beside each one, write down: Who uses it?

What do they use it for? What information goes into it? What does it cost?

What would stop working if we removed it? That last question is particularly useful.

The subscription cost is the obvious bit

Imagine ten employees each have several AI subscriptions. Individually, none feels particularly expensive. £20 here.

£30 there. Another £15. Perhaps a specialist product costs considerably more.

Across a year, across a team, it adds up. But subscription cost probably isn't the biggest problem. The bigger cost can be fragmentation.

Every new tool creates another place where work can live

Someone has a useful conversation in one AI tool. Someone else creates a project in another. Research is sitting somewhere else.

Meeting transcripts live in another system. Prompts are saved in personal accounts. Files have been uploaded to several services.

A useful workflow depends on a browser extension only one employee knows exists. Now the company has more capability. But it may also have more places to search.

More accounts. More permissions. More data locations.

More renewal dates. More things to manage. More ways for useful knowledge to disappear when someone leaves.

That's the part I'd pay attention to.

Tool sprawl becomes workflow sprawl

Suppose somebody's process looks like this: Open the meeting AI. Copy the summary.

Paste it into ChatGPT. Ask for actions. Copy those into the project-management system.

Open another AI tool to research something. Copy the research into a document. Use another tool to rewrite it.

Then manually update the CRM. There may be excellent AI at every stage. But the workflow itself is terrible.

Again, the human has become the integration. This is exactly why I think businesses need to move from thinking about AI tools to thinking about AI-enabled workflows.

The question isn't "Which AI is best?"

That's usually too broad to be useful. Best at what? For whom?

Inside which process? With what information? At what level of risk?

Connected to which systems? A tool that is brilliant for a developer may be unnecessary for somebody in finance. A specialist research product might justify itself for a team doing research every day and be pointless for everybody else.

A meeting assistant may save one team hours and simply create more transcripts nobody reads in another. There doesn't need to be one winner. There needs to be a reason for each tool.

Think in capabilities instead

I'd map what the business actually needs. Perhaps: GENERAL ASSISTANCE

Writing, thinking, summarising, analysing. RESEARCH Finding, comparing and synthesising external information.

BUSINESS KNOWLEDGE Working with internal documents and company information. MEETINGS

Transcription, summaries and actions. SOFTWARE DEVELOPMENT Coding, debugging, testing and technical work.

CREATIVE Images, video, design and other media. WORKFLOW

Connecting systems and moving work. AGENTIC WORK Carrying out multi-step tasks using tools.

Now ask: How many separate products do we need to provide those capabilities well? That's a much better procurement question.

One tool may now cover several jobs

This is where consolidation becomes possible. A general AI assistant may now be able to: write,

analyse, research, work with files,

create images, help with code, and interact with connected services.

That doesn't automatically make every specialist product redundant. A specialist product may still be significantly better for a particular workflow. But businesses should periodically revisit the assumptions behind their stack.

The tool you bought for one capability a year ago may no longer be necessary if something else you're already paying for now does the job well enough.

"Good enough" matters

This isn't always a competition to find the absolute best model for every task. Imagine one tool produces a slightly better meeting summary. But another tool is already:

approved, paid for, connected to your systems,

used by employees, and governed properly. Is the marginal improvement worth adding another service?

Sometimes yes. Sometimes absolutely not. The technically best tool and the best business choice aren't always the same thing.

But don't consolidate just for the sake of it

There's a danger in going too far the other way. A company decides: We're standardising on one AI platform. Everyone must use it for everything.

That can be equally unhelpful. Different tools genuinely have different strengths. Developers may need specialist environments.

Design teams may need specialist creative tools. A research-heavy team may benefit from capabilities other employees don't need. An automation platform serves a different purpose from a conversational assistant.

The objective isn't: ONE AI TOOL It's:

NO UNNECESSARY AI TOOLS That's a much more sensible target.

The model and the interface aren't the same thing

This becomes important as AI moves deeper into business systems. An employee may interact with one internal interface while several AI services operate underneath it. One model might handle a particular kind of document.

Another might be used for research. Another might support code. A smaller, cheaper model might handle routine classification.

From the employee's perspective, they aren't juggling four AI tools. The system chooses the appropriate capability behind the scenes. That's very different from giving everybody four subscriptions and asking them to decide.

Businesses may need fewer AI interfaces, not fewer AI models

That's the distinction I think matters. We may end up using more AI underneath business systems while employees directly interact with fewer separate AI products. The complexity moves into the architecture.

That's often what happens when technology matures. Users don't need to understand every service involved. They need a reliable way to get the work done.

Data should influence the decision

Suppose your team uses three AI tools for broadly similar tasks. One is deeply connected to your business information. The others aren't.

That matters. AI becomes much more useful when it has access to the right context. But access creates another question:

Which tools should be allowed to see which information? Every additional service potentially creates another data relationship to understand and manage. So rationalising your AI stack isn't just about saving subscription fees.

It's about reducing unnecessary exposure and complexity.

Permissions multiply with tools

This gets more important as AI systems become capable of taking actions. A writing assistant that only receives pasted text is one thing. An AI connected to:

email, calendar, CRM,

cloud storage, customer records, or internal systems

is another. Now every new tool may come with: access,

permissions, tokens, integrations,

service accounts, and potentially the ability to change things. The more capable the AI stack becomes, the less casual I'd be about adding another product.

Ask where your business information is going

This should be part of the inventory. For every AI tool, understand: what employees put into it,

what business systems it can access, how accounts are managed, what happens when someone leaves,

what controls are available, and what the business has agreed to by using it. The exact answers will vary by product and account type.

The important thing is that somebody in the business knows them.

Shadow AI is the new shadow IT

Businesses have dealt with this problem before. Employees find a useful piece of software. They sign up.

It solves their problem. Nobody centrally knows it exists. AI makes that particularly easy because the barrier to entry is tiny.

A browser. An email address. A credit card.

Sometimes not even that. Trying to solve this purely by banning things usually misses why people adopted them. They had work to do.

The approved tools weren't helping enough. So rather than simply asking: How do we stop employees using unapproved AI?

I'd also ask: What were they trying to accomplish that our existing systems weren't helping them do? That's useful information.

Standardisation can make AI easier to use

A sensible core stack can actually improve adoption. Employees know: which tool to use,

where company information belongs, which services are approved, what they can upload,

what they shouldn't upload, which workflows already exist, and where to get help.

That removes one of the hidden problems with AI adoption: choice. If every employee has to constantly decide which of nine AI tools is best for a task, you've created another piece of work.

Training gets easier too

Imagine trying to train a company across 14 different AI products. Interfaces change. Features change.

Models change. Plans change. Integrations change.

Now imagine the business has a smaller number of clearly defined tools and workflows. Training can focus less on: which button do I press?

and more on: how do we use AI well? That's much more durable.

Don't standardise prompts before you standardise purpose

Companies sometimes start building prompt libraries. That can be useful. But if five departments are using four different tools to perform essentially the same process, I'd look at the process first.

What are we actually trying to achieve? What information does it need? What should the output look like?

Where should the result go? Who checks it? Once that's clear, the prompt becomes a component.

Not the strategy.

Cost isn't just licences

I'd look at AI stack cost in several layers. SUBSCRIPTIONS What are we paying directly?

ADMINISTRATION How many services need managing? TRAINING

How many interfaces and workflows must people learn? INTEGRATION How many things need connecting and maintaining?

DATA How many places are receiving company information? SECURITY

How many permissions and accounts need controlling? SWITCHING How much time is spent moving between tools?

DUPLICATION How many products are doing substantially the same thing? That's a much better picture of the cost of the stack.

There is also a cost to changing constantly

AI is moving ridiculously quickly. Every week there's another product that looks better than the one you chose last month. If businesses continually switch tools chasing every improvement, they'll spend their lives migrating.

New accounts. New workflows. New training.

New integrations. New policies. Sometimes switching is worth it.

But the improvement needs to justify the organisational cost of change.

Don't build your workflow around a logo

This is one of the architectural principles I'd use. Where possible, define the business process separately from the AI provider. The requirement might be:

Classify this enquiry. Not: Send this to Model X because that's what we currently use.

Or: Extract these fields from the document. Not:

Our business process is built around this particular AI interface forever. Providers will change. Models will change.

Prices will change. Capabilities will change. Your business process should be able to survive some of that change.

That doesn't mean everything has to be portable

Perfect provider independence can create complexity of its own. Sometimes a product is excellent because it's deeply integrated with a particular ecosystem. That's a legitimate trade-off.

The point is to make the choice consciously. Know where you're creating dependence. Know why it's worth it.

A simple AI stack audit

If I were looking at a company's AI stack, I'd create one table. For every tool: TOOL

What is it? PURPOSE What business problem does it solve?

USERS Who actually needs it? CAPABILITY

What does it uniquely or particularly well provide? DATA What information can it access?

ACTIONS What can it do, not just read? OVERLAP

Which other tools provide the same capability? COST What does it cost directly and operationally?

DEPENDENCY What breaks if we remove it? DECISION

Keep, consolidate, replace, restrict or retire. That will tell you far more than another "Top 20 AI tools for business" article.

The KEEP test

For each AI product, I'd ask four things: K: KNOWN PURPOSE Can we clearly say why we have it?

E: EVIDENT VALUE Is it genuinely improving something? E: ESSENTIAL DIFFERENCE

Does it provide something we don't already have elsewhere? P: PERMISSION FIT Are its access, data and actions appropriate for what we're using it for?

If you can't answer those comfortably, the tool deserves another look. Not necessarily deletion. Just scrutiny.

What should a small business actually have?

There's no universal number. For some small businesses, one general AI assistant plus the AI already built into their existing software may be enough. Another business might genuinely need:

a general assistant, a coding environment, a creative tool,

an automation platform, and a specialist system for its industry. That's fine.

The question isn't whether five is too many. It's whether you know why there are five.

And what about larger organisations?

The same principle applies, but governance matters much more. Different teams will need different capabilities. The aim isn't necessarily to force everybody onto exactly the same interface.

It's to create: a sensible approved core, clear exceptions,

defined data rules, appropriate access, managed integrations,

and visibility of what's actually being used. Central control without understanding the work will frustrate people. Total freedom creates its own problems.

You need both governance and usefulness.

Your AI stack will probably keep changing

This isn't a one-off tidy-up. Capabilities are converging quickly. Things that required specialist products may become standard features.

New forms of AI will create genuinely new categories. Business software will absorb more intelligence. Some standalone tools will remain valuable.

Others will become features. So I'd review the stack periodically. Not every week.

Not every time somebody posts an impressive demo. Periodically.

The future may be fewer places to "go and use AI"

This connects to something bigger. I don't think employees will necessarily spend their days jumping between dozens of AI applications. AI is increasingly likely to sit inside:

the CRM, the inbox, the browser,

the development environment, the customer-service system, the finance workflow,

the internal knowledge system, and the processes connecting them. The AI becomes part of the infrastructure.

When that happens, counting AI tools becomes even less useful. The important thing becomes understanding the capabilities and controls underneath the work.

So, do you need 14 AI tools?

Maybe. There is nothing inherently wrong with 14. If each one solves a distinct problem, creates value and is appropriately managed, fine.

But if nobody knows why half of them are there, three do essentially the same thing and employees spend their day copying information between them, probably not. The first phase of business AI was understandably about experimentation. Try things.

See what's possible. Learn. The next phase needs a little more architecture.

What capabilities do we need? Where should they live? What information should they access?

What should they be allowed to do? Which systems should connect? Which tools have earned their place?

Because a business doesn't need the biggest AI stack. It needs the smallest stack that gives it the capabilities it actually needs.

Where to go next

• The most important AI may be the AI you stop noticing Why AI is moving from a separate destination towards a capability embedded inside business systems.
• Don't start with AI. Start with the work. Don't collect tools first. Find the work worth improving.
• AI vs automation: what's the difference, and when do you need each? Not every problem needs another AI product.
• The important question isn't what AI can do. It's what you should let it do. Every new connected AI tool potentially introduces another set of permissions and actions to manage.

Related: The most important AI may be the AI you stop noticing.