Mode oneAI in the business
Find where it pays, then build the first one
Every department has a list of things AI could do. Most of them do not pay, several cannot be done with the data you actually hold, and a few are worth real money. Sorting them means looking at your systems and your data, so what comes back is a short list with the reasons attached, and the cases I would leave alone are on it too.
Then one of them gets built. In production, on real data, used by the people whose work it changes, because a pilot nobody uses settles nothing.
- Where it pays, where it does not, and what each would cost to find out
- What your data and systems support today, checked rather than assumed
- One case in production, with your developers in the repository while it happens
- What it cost, and an honest read on whether the second one is worth starting
Mode twoAI in how you build
Agents in your own development
Your developers already use AI, in ways nobody has written down and nobody reviews. Turning that into a practice means rules the agents follow, automation from alert to ticket to pull request, and quality and security gates that run without being remembered. Two or three of us per team, next to the people who keep it going afterwards.
Agents write, review and test code here every working day, so the pace already assumes them. That is worth something to you only if it survives our leaving, which is why the rules go into your repository instead of staying in our heads.
- Agent rules and review practice written down, in your repository
- Automation from alert to ticket to pull request
- Quality and security gates that run without anybody remembering them
- Where not to point an agent, and how to tell when it is confidently wrong
Before the money goes in
Whether the AI in the pitch is a product
A company describes itself as AI-led. The useful question is whether that is a product, a thin wrapper on somebody else's model, or a slide. Reading the code, the data rights and the evaluation results answers it, and the answer can be written so it survives an investment committee.
After it goes in
The same questions, answered once for the portfolio
Every company in a portfolio meets the same AI questions, and each one answers them alone, slowly, and at full price. One framework agreement puts the same people across several of them, so the work is reused instead of bought again. Each company still gets its own answer, because their data and their customers differ.
For the fund itself
Cases inside the fund itself
Deal flow screening, document work, the reporting nobody enjoys. A fund runs on reading and summarising, which is the work current models are genuinely good at, so the cases are often closer to hand than in an operating company.
Built end to end
AI Ship Systems Design
A document-analysis product built around nearly 18,000 pages of maritime classification rules: OCR, chapter-aware parsing, hybrid retrieval and cited answers, which take an analysis from days to hours. It went to a commercial shipyard pilot on a multi-tenant foundation.
This is the shape of a first case done properly: real documents, real users, and answers that cite their source so a naval architect can check them.
RAGpgvectorEvaluationEnterprise SaaS
Agents in a development organisation
AI-assisted development at Everon
Getting agents into how a company actually builds, where it had to work for product, engineering and QA together instead of running as a pilot beside the real process. Health technology, device to SaaS, across three countries.
The hard part was never the model. It was the review practice, the gates and the habits around it.
Agent workflowsCI and releaseQuality gatesCoaching
Both sides of the table
Two acquisitions at Wiztivi
Technical diligence seen from the company being bought and from the side doing the buying, as COO and CTO. It is a useful pair of experiences when the question is whether a technical story holds up.
Worth saying plainly
What I am not
I am not a research lab, and I do not train foundation models. The work is applying models that exist to problems that are yours, which is where nearly all the value in an AI strategy sits this year. If your case genuinely needs original research, I will say so early.
Step oneA short set of questions
Thirty minutes, free, and sometimes the answer is no
A short call about what you are trying to do and what you already have. Often that is enough to tell whether there is a case here worth paying to explore, and if there is not, saying so costs us both half an hour.
Step twoScoping
Scoping before anything is promised
What has to be true when it is done, what already exists, what the constraints are, and which parts nobody can size yet. That last category is what sinks fixed bids, so it gets named out loud instead of hidden inside a number.
Step threePricing and people
Named people, and a price that matches the work
The parts we can scope get a fixed price. The parts nobody can honestly size yet are billed by the hour until they are understood. You see who is coming, by name, with what they have delivered. The contract is with my company, STC, whatever the size of the team, and the terms are the same as for any SWAT engagement.
- Nothing recommended is chosen to keep you tied to us
- The handover plan starts on the first day rather than the last
Worth knowing before you call
It will not write a strategy to be filed
If what you need is a board-ready document and nothing is going to be built this year, a large consultancy will do that faster and with better slides. The value here is that the people judging what is worth doing are the people who would then have to build it, and that only pays off if something gets built.
It also will not tell you AI solves something it does not. A fair number of the cases that arrive are ordinary software problems wearing a fashionable hat, and those are cheaper to fix as ordinary software.