AI implementation for mid-market enterprises

Roughly 50 to 2,000 people. Large enough that the same decision is made hundreds of times a week by different people, small enough that no one has a department dedicated to machine learning.

The constraint is rarely ambition. It is that the people who understand the process are already fully occupied running it, and the engineering team is already committed for two quarters. Any AI project competes directly with work that is already funded.

The pattern that pays is a decision made repeatedly, by people, using information that already exists somewhere in your systems. Claims triage. Supplier document review. Support classification. Catalogue quality. Order exception handling.

What these have in common is a defensible definition of a correct answer. If two experienced people would disagree about the right outcome half the time, no model will fix that, and the project becomes an argument about the rubric instead.

• —A repeated decision, not a one-off analysis
• —A definition of "correct" your own experts agree on
• —Enough historical examples to test against
• —A team that owns the outcome after handover

The model is almost never the problem. Pilots die on missing business context, on evaluation that was never built, on access control that was left to the end, and on the absence of anyone who owns the system after the demo.

A pilot that runs on a curated sample proves the technology can do something. It does not prove your version of the problem is solvable, which is the only question worth answering before you commit a budget.

We start with the decision, not the technology. What happens today, who does it, what it costs when it goes wrong, and what would have to be true for a system to be trusted with it.

Then we build the evaluation set before we build the system: real examples, scored against a rubric written with your own reviewers. That set is the asset. It tells you whether anything is working, and it survives every later change of model or vendor.

A working system inside your environment, the evaluation set and rubric that prove its performance, documentation of its limits and failure modes, and the handover that lets your team change it without calling us.

• —Discovery that ends in a recommendation, including "do not build"
• —A production system, not a demo
• —An evaluation set you keep
• —Human review points and escalation paths defined before launch
• —Runbooks and documentation for your own team

Systems may run in your cloud, on your infrastructure, or through approved model providers, depending on your security, operational and cost requirements. The choice is yours and we document the trade-offs rather than defaulting to whatever is easiest for us.

Where we hold data, the agreement sets out who may access it and what it may be used for. Client data is not used to train models for other clients unless you authorise it in writing.

We keep the evaluation set and the business rules as assets you own, and we design the system so that changing model means re-running an evaluation rather than rebuilding an application.

A model change still has to be evaluated. Tool calling, context limits, output schemas, latency and cost all differ between providers. The aim is that a switch is a measurable decision, not a rewrite.

When the process is about to change anyway. When nobody can define a correct answer. When the data that would ground the system does not exist in any retrievable form. When no one is willing to own the outcome. When conventional software or a fixed process would do the job more cheaply and more predictably.

We would rather tell you this in the first conversation than three months into an engagement.