Making AI Work
This is the second in a series of five articles on what AI transformation actually looks like in mid-market businesses, and the role a PE firm should play in making it happen.
I cast my mind back to December 2024 (when, in AI terms, feels like a long time ago) and remember how excited I was when I first got my hands on Microsoft Copilot. Fully embedded into the Microsoft 365 suite, it seemed like the moment AI would finally become genuinely useful in day-to-day work.
At the time, I was CTO at PSSG, and we moved quickly – running pilot programmes, testing use cases, and trying to understand where the value really was. My overwhelming reaction was one of disappointment. What we had was a slightly better way of accessing ChatGPT, with some patchy context layered on top. The only feature that genuinely stood out was automated note-taking in Teams. Everything else felt marginal. Fast forward to February this year, and Anthropic launched Claude in Excel and PowerPoint, accompanied with Claude Cowork and followed more recently with Claude in Word. These were much closer to what I had hoped Copilot would be – tools that could lead, change and create your Microsoft documents on your behalf.
At Tenzing, we adopted then quickly. More importantly, we trained people to think differently about how they work. For those doing Excel-heavy tasks, the impact was immediate. Work that used to dominate their time was compressed, and suddenly there was space made to focus on things that never quite made it to the top of the list.
There’s a common thread running both my Copilot disappointment and most of the underwhelming AI features I see in Software products today: the assumption that users want is AI that answers questions about their data, inside your UI. They don’t – they want to get things done. And increasingly, they want to do those things with their own AI agents, working across whichever systems they choose.
The two AI mistakes – chatbots and data moats – both come from missing this. The AI solutions come from accepting it.
The AI Mistakes
Not another chatbot!
The Copilot example illustrates that first failure mode: building an AI “copilot” that does little more than query your data and answers questions. The underlying assumption is that all users primarily want better access to information that already exists in their system. But this is rarely the real problem.
Even when it works, it can create friction. Will the AI understand what the user is asking? Or will the answer even be correct? And if itis, will the user trust it enough to act on it? In many cases, iIt often creates more questions than it answers.
In addition, there’s also a structural issue: LLM providers are much better at building chat interfaces and using their tools for data querying tasks than most software companies. Their tools are already connected multiple systems and sets of data. So the question becomes – what is your simple chatbot actually adding?
The Data Moat Myth
The second mistake is trying to protect your data because you have a ‘data moat’ that can’t be easily replicated. Historical data has a limited shelf-life. It’s useful for historical reporting, auditing and understanding what has happened – but far less useful for driving future value. Few companies operate today in the same way they did even three years ago, let alone ten.
Closely related to this is the belief that this data can be used to reliably predict future outcomes. There are some limited exceptions to this (e.g. regulatory or early access data) but in most cases, the value and deliverability of this is extremely limited.
Predicting human behaviour is inherently difficult. Companies that try to protect the data that is in their systems and prevent their customers moving it and using it how they see fit will struggle in the new LLM-driven world.
The AI Solutions
Agents are the Key
It’s not a new idea that agents are the breakthrough – but it’s worth being precise about what that means. An agent is any AI system that takes action, rather than simply returning information.
The best example today is tools like Claude Code, which don’t just generate code but can test it, run it, and even deploy it. That’s a fundamentally different level of capability.
This is the key distinction between early Copilot-style tools and the newer generation of AI integrations. The latter are genuinely agentic: they can interpret context, make decisions, and execute tasks in a way that materially improves productivity.
For us as investors in SaaS and software-enabled businesses, the direction is clear: companies should be moving towards genuinely agentic systems, both within their products and enabled through them.
Managed “Super’ Agents”
The most practical starting point for most companies is to build their own managed agents -systems that can perform specific actions that users would otherwise do manually.
Software companies are uniquely well placed to do this. They understand their own products, the edge cases, and where things can go wrong. This allows them to design agents that are both effective and safe.
They can also optimise model selection, control costs, and build multi-agent systems that introduce validation and checks – something that would be difficult for customers to replicate themselves. Done properly, this leads to “super agents”: systems that can execute tasks at a level that is faster, more consistent, and in some cases better than a human user.
A Post-UI World
If you’re old enough (like I am), you’ll remember early computers as command-line interfaces – black screens, green text, and a steep learning curve. GUIs were introduced to make software usable for everyone.
We are now seeing a shift in the opposite direction.
AI doesn’t want to use your UI. It’s slow, inefficient, and not designed for machine interaction. Today, LLMs have to take screenshots and simulate mouse movements to navigate interfaces – something they are fundamentally not good at.
The implication is clear: software needs to be accessible programmatically, not just visually.
The emerging standard here is MCP (Model Context Protocol) – a way to expose your system to LLMs in a structured, permissioned, and AI-friendly format. In effect, it allows AI to control your software through language.
Once that exists, how customers use your product changes completely – and you don’t control it anymore.
They might build workflows you never designed. They might combine your product with others in unexpected ways. They might even create features (like bulk imports) that you never built, simply by orchestrating your API through an LLM.
This isn’t a threat – it’s the point. Users don’t want to log into ten systems and manually perform dozens of tasks. They want to instruct an AI to do it for them.
Paradoxically, by making your product more accessible, you make it more embedded. Instead of logging in 50 times a day, your product becomes a critical part of automated workflows that are much harder to replace.
A powerful pattern here is combining MCP access with your own managed agents. This allows external LLMs to trigger controlled, efficient, and safe actions inside your system – giving users flexibility without sacrificing control.
Conclusion
What marks out the software companies of the future from the ones that will get left behind is not the data moat but the data accessibility.
The winners will be those who make it easiest for AI to interact with their systems – exposing the right capabilities, enabling agents, and building meaningful automation on top.
The losers will be those who try to defend their position by restricting access and shipping low value “AI features” that frustrate users without solving real problems.
If you’re a CTO today, the risk is simple: if you don’t enable LLMs to work with your product, your customers will find a product that does.
For leadership teams, this comes down to three questions that should be answered this quarter:
- What is your MCP roadmap, and when can a customer’s AI agent perform a meaningful action in your product?
- How much of your perceived data moat is defensible?
- Which AI features on your roadmap are genuine “super agents” that automate real work – and which are answer bots you should kill?
The companies that can answer these clearly are ahead. The ones that can’t are at risk.
Next: Part 3 – AI for operational transformation – Making the Entire Business AI-Capable
The series:
1. You Need to Understand AI Before You Implement AI
2. AI in Your Product – Data Moats and Why Most AI Features Are Worthless
3. AI for Operational Transformation – Making the Entire Business AI-Capable
4. AI for Product Development – Why Your Engineering and Product Teams Need to Change Now
5. The AI Transformation Toolkit – Frameworks, Checklists, and What We’re Actually Buildin
