Who you would be working with
An interdisciplinary team that has shipped this before
predictes is built around a simple observation: AI programmes fail at the seams — between the strategy and the build, between the model and the process, between go-live and the month nobody was watching. Covering those seams needs people who have worked on both sides of them.
- SME → enterpriseCompany sizes we work across
- 5Platform families: Azure, Google Cloud, AWS, IBM Cloud, open source
- 12Services, from framing to managed operations
- 0Licences or cloud contracts we resell
Interdisciplinary, because the failures are
The reason AI work needs a mixed team is that almost none of the hard parts are modelling problems. A recommendation that is technically correct and organisationally impossible fails. A beautifully engineered pipeline over data nobody agrees on fails. A working system that nobody was trained to operate fails nine months later, quietly.
So the team spans strategy and change work, data and ontology engineering, application and agent engineering, and the operations side that keeps a system honest after the launch. The point is not breadth for its own sake — it is that the same people can follow a problem across the seams where it would otherwise be dropped.
From SME to enterprise
The engineering does not change much with company size; the sequence does. A twenty-person company needs one process fixed and something running in weeks, with almost no tolerance for a programme. A two-thousand-person organisation needs the same thing eventually, but has committees, an existing estate and a change budget that determine what is even possible this quarter.
Getting that sequence wrong is the single most common way good work is wasted. Small companies get sold transformation programmes they cannot absorb, and large ones get sold pilots that were never going to scale past one department.
Open-source platforms and commercial clouds
Both, deliberately. Commercial clouds are the right answer more often than open-source advocates admit, particularly when a company already has a commitment, skills and a working estate. Open-source stacks are the right answer more often than platform vendors admit, particularly when data cannot leave, when a licence cost scales badly, or when procurement now asks what leaving would take.
Most real architectures are a mixture, which is unsatisfying to everybody selling a single answer and is usually the truthful recommendation.
What we would want you to check
Ask what we resell — nothing. Ask what happens to the code and the data if you stop — they are already yours. Ask what the engagement looks like in month nine — smaller. And ask us to frame your problem in an hour and see whether the questions are better than the ones being asked internally. That last one tells you more than any credential.
About us
Vendor-neutral by structure
We resell nothing and hold no partner quota. That is a smaller business model and it is the only structure in which the recommendation and your interest point the same way.
You own what we build
Code in your repositories from day one, data in your infrastructure, models and prompts documented as deliverables. The exit is agreed before the work starts.
We train ourselves out of the job
Documentation written during the work, your engineers pairing rather than reading summaries, and a support tier that is meant to decline. If it does not, one of us is not doing the job.
Outcomes, not deliverables
An engagement is scoped around what will measurably be different, not around a list of documents. If that cannot be written down, the problem is not framed yet.
Honest about limits
AI systems fail quietly and are wrong in ways that require domain knowledge to spot. We design for that from the start and say so, rather than discovering it with you in month nine.
We will tell you not to
Some problems are process problems, data problems or organisational problems wearing an AI costume. Saying so costs us a project and saves you a programme.