Capability
AI Engineering
Models are the easy part. Running them where it matters is the work.
What we build
Custom LLM Development
Models adapted to your domain and your language, then distilled down to something small enough to run at a price the use case can carry.
- Fine-tuning
- Distillation
- Open-weight models
- Held-out evaluation
Private & On-Premise AI
Inference inside your own boundary, so controlled data never leaves the environment cleared to hold it. Air-gapped where the framework demands it.
- Self-hosted inference
- Air-gapped
- GPU sizing
- NIST CSF · CMMC
Retrieval & Knowledge Systems (RAG)
Answers tied to a source your organisation already trusts, so a reviewer can see where something came from and check it.
- Hybrid retrieval
- Reranking
- Chunking strategy
- Citations & provenance
Agentic Systems & Orchestration
Systems that take actions, with the actions they are permitted to take enumerated, logged and reversible.
- Tool use
- Multi-agent workflows
- Approval gates
- Full action audit
Computer Vision
Detection, classification and OCR across images and video, including the multi-modal work behind content classification and age assurance.
- Detection & segmentation
- OCR
- Video pipelines
- Edge inference
Applied Machine Learning
Forecasting, ranking and anomaly detection: the ordinary models that beat a language model on most numerical problems, for a fraction of the cost.
- Time-series forecasting
- Anomaly detection
- Gradient boosting
- Neural networks
We build the system around the model: what it retrieves, what it does when it is unsure, how anyone knows it is still correct next month, and where a person takes over. The model itself is one component, and usually the one we spend least time choosing.
The problem it addresses
Picking a model is a small decision now, and a reversible one. What decides whether an AI feature works is everything around it. Where the answer came from and whether it can be traced. What happens when the input is nothing like the training data. Whether last week’s improvement quietly broke something nobody was measuring. These are engineering problems, and they do not get solved by changing the prompt.
They get harder because most of our work has a constraint attached before it starts: an air-gapped network, a response-time budget a person will actually wait for, a device with no connectivity, or data that arrives late and malformed. A constraint discovered after the architecture is settled is the usual reason a working demonstration turns into a rewrite.
How the work runs
Three phases. The order matters more than the labels: nothing in a later phase starts before the one before it has an answer.
01_SCOPE & GROUNDING
The constraint and the jurisdiction, established first
Retrieval sources agreed with the people who own them
The evaluation harness written before the feature
02_BUILD
Model chosen against your own held-out cases
Behaviour under uncertainty decided at design time
Permitted actions enumerated, logged and reversible
03_RUN
Latency, cost and hardware measured under real load
Drift surfaced as a failing test, not as a complaint
Reviewer corrections fed back into the next version
How this is delivered
Team shape
2 to 6 engineers, with machine learning and backend in the same team
Common dynamic
From a scoped proof of value to multi-year ownership
Engagement model
Managed Delivery or Embedded Partnership
Delivery hub
London · Zagreb · Belgrade
Where a competitor would stay quiet
The trade-offs
We will tell you when the answer is not AI. A well-built search index, a rules engine or a considerably smaller model beats a language model in more situations than the market currently admits, and we would rather build the cheaper thing and say so. Where a model is the right answer, we build the evaluation harness before the feature. That makes the first demonstration later than you would like and every release after it faster, and if you need the demonstration first, we are probably the wrong firm for that piece of work.
Questions procurement actually asks
Whichever the constraint allows. Open-weight models self-hosted where data cannot leave the environment, hosted models where that restriction does not apply, and frequently something much smaller than either. We benchmark the options during scoping and revisit the choice later, because it is one of the cheaper decisions to change.