From Curiosity to Day Job

My journey with AI started in early 2023. My wife, who was a researcher at Exeter University at the time, said "have you come across ChatGPT?" So I had a look. Back then, you could scroll through LinkedIn without drowning in AI content. No "top 10 prompts that will change your life." No daily debates about which model is best for what. It was quiet.

Today I can't open LinkedIn or TikTok without being told about the best prompt for something, the seven layers of AI, a new tool that changes everything, or why one model is better than another. Some of it is genuinely good. A lot of it isn't.

My timing wasn't accidental. I was running a technology team at the time, halfway through deploying an AIOps platform across the organisation. AI wasn't a novelty for me. It was already part of the day job. ChatGPT just opened a door to something much bigger.

Not long after, I moved into a company building a self-driving telco network platform. It configured itself, healed itself, and protected itself, anchored to a knowledge graph of what the network actually was. Initial domain: fibre access in telco.

By then I'd moved from ChatGPT to Claude, which was already part of my daily working life. The company had opted for Perplexity as their AI of choice. What this role added wasn't more AI exposure. It was something different. I was working at C-suite level, helping reposition the business from engineer-led to product-led and market-driven.

Networks don't wait for a human to click "approve". Instead, they act autonomously. Decisions happen at network speed, driven by intents, bounded by guardrails, anchored to a knowledge graph that tells the system what the network actually is.

What mattered, looking back, wasn't the AI inside the platform. It was being in the room, before LLMs made any of this fashionable, while people argued about how to design a system that takes action on its own without going off the rails. That's not a thing you learn from talking about the best LLM, or linking with Google Sheets, or the best prompt for "x".

Wheat from Chaff

Since then, the content has exploded. Everyone has an opinion on AI. The best prompt for this. The best model for that. Five tools you need today. A new framework every week. Some of it is genuinely useful. But a lot of it keeps people stuck at the surface, endlessly consuming without ever getting anywhere.

Here's what I've noticed. A lot of the AI content out there focuses on prompting. The best prompt for this, the best prompt for that. Or on connecting AI to new tools. The latest integration, the slickest way to plug it into your inbox, your CRM, your stack. Both are reasonable starting points. Neither is the goal. When you move past generative AI and start understanding agentic AI, something shifts. You're no longer asking AI for answers, or wiring it up to do isolated jobs across your existing apps. You're building systems where AI takes action, makes decisions within boundaries, and operates as part of something bigger. And those systems aren't built by plugging in more tools. They're built by designing the structure agents need to operate in.

That distinction matters because it changes what skills you actually need. Knowing the tools is useful, of course it is, but agentic isn't a tool problem. Bolting more tools together adds capability and complexity in equal measure, and you tend to feel the complexity first. The skill that matters is understanding how systems fit together, anchored by the problem you're trying to solve and the outcome you want to realise. I've spent 30 years doing exactly that. Breaking businesses into their component parts. Understanding how processes connect, where data flows, where it's mastered, where ownership lives, where the dependencies sit, where the politics sits, how security wraps around all of it, and what happens when you change one thing and three other things break. That's not something I learned from AI. That's something I brought to it.

And here's the thing. I've watched this story play out before. Anyone who lived through the SaaS era will recognise the pattern. Someone in the business hits a problem they need solved today. They reach for a credit card, sign up to a tool, and the problem goes away. For them. Multiply that by a few hundred employees over a few years, and you've got shadow IT: a sprawling, undocumented, ungoverned mess that finance can't track, security can't see, and architecture has to retrospectively wrestle into shape. The AI version is the same shape, only worse. SaaS shadow IT at least left a paper trail. Finance could find the invoice once they went looking. The AI version often doesn't. A free ChatGPT account. A personal Claude subscription on someone's own card. A personal API key running on the side. A browser tab, a desktop agent quietly reading someone's files. People pasting contracts, customer lists, and source code into prompts they don't realise are being logged. Personal automations firing off actions in the company's name. And once those tools start taking actions on their own, once they go agentic, SaaS shadow IT will look quaint. At least back then, someone had to click.

I deployed n8n eighteen months ago because it was the right tool then. I pulled it out this year because it wasn't anymore. The systems thinking that made both of those calls hasn't moved an inch. Tools expire. The thinking doesn't.

Few tools, deep integration

A lot of people talking about AI operations assume the answer is more tools. A new platform for this. A new connector for that. An MCP for everything. The reasoning is intuitive enough. If AI is the new electricity, you want it everywhere, plugged into everything. This misses the mark. People are butterflying to the next newest tool when they should be learning to think in systems.

To anyone who's been told "best of breed" is the right answer, that sounds like a regression. It isn't. The reason most AI deployments stall is not that the models aren't capable. It's that the data they're acting on is scattered across fifty SaaS tools, each with its own schema, its own permissions model, its own definition of a customer. Wiring AI into that mess doesn't fix the mess. It just hides it behind a chat interface.

It's easy to get caught up in the hype. For my own use case I disciplined myself to go the other way. My stack started life minimally. Claude (API and Code), my own platform (the Paradigm-ICT website with MySQL underneath), and n8n for workflow orchestration. That was it.

And I had a clear problem I needed solved, with a clear outcome I wanted. The problem: keeping my network alive, current, growing and visible while I'm head-down in a client engagement. Networking is hard to keep active when you're focused on delivery, and going direct, rather than relying on agencies to bring me work, meant the pipeline had to keep running whether I had bandwidth or not. The outcome: a business development engine that ran whether I was looking at it or not. And I had a criterion that would tell me when I'd got there. The same criterion the telco platform had been built around. Autonomous. The system had to run itself.

The unsexy truth is that AI-first operations are mostly a data architecture and process problem. In my platform, every customer, contact, task, action, skill, workflow, and log lives in one MySQL schema with one definition. When I point an agent at "all overdue actions for the engagement pipeline," there's no reconciliation, no schema-mapping, no "which CRM is the source of truth this week." The agent just runs the query. Get the data structured, governed, and mastered in one place and AI becomes genuinely useful. Skip that step and you risk amplifying the mess you already had.

So the 101 tools approach isn't just expensive. It's actively working against the thing you're trying to build. Every tool you add is another schema to reconcile, another set of permissions to manage, another place where the truth might live. The best AI strategy I've found is the boring one. Fewer tools. Deeper integration. Everything in one model. Then point intelligence at it.

Pilot to Production

There's a conversation happening right now about moving from pilot to production. I see it in conferences, in strategy decks, in boardrooms. "We've done the POC, now how do we scale?" And I see the same conversation still happening six months later.

There was no pilot. Not because I was reckless. By the time I'd framed the problem and the criterion, the question wasn't whether to pilot. It was where to start. Pilots are for things you can still walk away from. This wasn't optional. So instead of a big design phase, a sandboxed POC, and a months-long production transition, I just built it in pieces. Small bits of code. Small bits of functionality. Each one tested locally. Each one deployed to live the moment it was ready. Build, ship, watch, fix, repeat.

Before each piece, I drew out the workflow. Systems thinking first. What's the actual process. Where does the data flow. Where is it mastered. Where do the dependencies sit. Where does AI fit. Where doesn't it. That last question mattered most. The map told me where to point the intelligence, and where to leave well alone.

The early pieces were the boring ones. Data enrichment. Log classification. Alert triage. Tasks where if the AI got it wrong, nothing caught fire. A contact that gets the wrong industry tag doesn't cost anyone money. A misclassified log entry doesn't bring down production. The stakes were low enough that I could let it fail, watch how it failed, and fix it.

What I found is that the interesting problems aren't the ones everyone's talking about. They're not "try it in the Gemini app, it's mind blowing" or "5 AI agent tools that make ChatGPT feel outdated."

My problems were engineering problems: permissions, security, observability, efficiency, cost control, controlling hallucinations, keeping the context window from filling up, and preserving state across multi-agent systems.

How do I stop the context window filling up halfway through a complex task, so the agent forgets what it was told at the start? How do I keep eight agents in sync when one of them changes something the others depend on? How do I budget this so it doesn't cost a fortune? How do I know what it's doing when I'm not watching? And the big one. How do I get it to the point where it genuinely runs itself, without me babysitting every step?

Pilots don't surface those questions. Real builds do. The answers aren't in a framework or a tool guide. They're in shipping, breaking, and fixing.

That's what moved me from one AI task to eight autonomous agents operating across every part of my business. One classifies every log entry the moment it's written. One triages and resolves ITSM alerts. One enriches every new contact with intelligence pulled from their company's web presence. One transcribes and analyses every meeting I take. One audits the catalogue of my own platform every night to catch drift. None of them were planned at the start. Each came from solving the next problem, measured against the same criterion. The system has to run itself.

This is what AI-first operations look like in practice. Not a pilot. Not a tool stack. A clear problem, a clear criterion, and the willingness to build, ship, and fix until the system runs itself.

If you're trying to make AI-first operations actually work in your own organisation, past the pilot and into the day-to-day, and you want a sounding board from someone who's already done it, get in touch. The patterns generalise. The specifics never do.