Custom Model Development
Agentic systems run on models. Most of the time a frontier model behind an API is the right choice. Sometimes it isn't: the task is narrow, the output has to conform exactly, the data can't leave your network, or the API bill and its dependency have become the problem. For those cases I develop small models built for one purpose.
Small models, specific jobs
This extends my work from building agentic systems to developing the models inside them.
A general-purpose model is very good at many things, and you pay for all of them on every call. A small model trained for one task does that task consistently, runs on modest hardware, and keeps behaving the same way because nobody else is updating it. For classification, extraction, routing and other well-defined steps, that is often the better trade.
I have done this for my own work: my speech recognition fine-tunes are small models trained for one dictation need each. For speech recognition specifically, see ASR fine-tuning. I bring the same approach to business tasks, either building the model myself or advising your team while they build it.
What I build
Bespoke models that sit inside pipelines, agents and workflows.
Accessory models for pipelines
Small models that handle a single stage of a larger pipeline, such as tagging, filtering, extraction or routing, so the expensive model only sees the work that needs it.
Classifiers for business data
Models that classify records, documents or messages against your own categories and return the result as JSON or another programmatic format that downstream code can consume directly.
Replacing API dependencies
Where a workflow calls a third-party model API for a narrow task, a model you own can take its place. You stop depending on another provider's pricing, rate limits and model changes for something your process needs every day.
Reliable structured output
Models trained to produce output that conforms to a fixed schema every time, for the tool calls and MCP connections where a malformed response breaks the workflow.
On-premises models
For organisations with data residency or sovereignty requirements, models small enough to run inside your own infrastructure, so sensitive data never goes to an outside provider.
Why output conformity matters more now
MCP and tool calling are a big step forward. They also make standardisation more important.
When a model only wrote text for a person to read, a slightly different format each time did no harm. Once the model is calling tools, its output is the input to another system. A missing field, an unexpected value or a different date format turns into a failed call, a wrong record or a workflow that stops halfway.
The more of your operations run through tool calls and MCP connections, the more of that reliability depends on the model producing the same structure every time. A model trained on your schema is one way to get there. Choosing it is part of the consulting below: sometimes validation and a well-specified prompt are enough, and I'll say so.
Consulting: from training data to deployment
Many teams want to build the model in-house. I can plan it with them and stay involved through rollout.
Training data plan
A plan for how the training dataset will be put together: what data you already have, what has to be collected or labelled, how much is needed, and how your team produces it internally.
Training plan
A plan for creating the model itself: the base model, the training approach, how results will be evaluated, and the stages from first experiment to a model ready for production.
Post-training and reinforcement learning
Recommendations on which methodology to follow, whether supervised fine-tuning, preference tuning or reinforcement learning, based on the task and the data you can realistically produce.
Fine-tuning providers and compute
Which provider to fine-tune with, and on what: managed fine-tuning services, serverless GPU or dedicated GPU instances, compared on cost, control and where your data goes.
Deployment recommendations
How the finished model is served: as an internal API inside your network, as a public API, or on serverless inference, and how it plugs into the agents and pipelines that will use it.
Implementation partnering
Working alongside your team through implementation, or building it for you, from the first dataset to the model running in production.
Have a task that needs its own model?
Describe the task, the data you have and where the model has to run. I'll tell you whether a custom model is worth it.