Applied AI that runs where the work happens

Applied machine learning

Most useful models are not large. On tabular business and sensor data, a gradient-boosted model with well-chosen features often matches or beats a deep network, trains in minutes and is easier to explain. We start with a simple baseline, measure it honestly and add complexity only when it earns its place.

Every project gets a held-out test set that reflects how the model will be used. Anything that forecasts gets time-based splits, so the accuracy we report is as close as we can make it to what you will see in production. Our founder, Kunal Miind, set out this way of working in AI System Blueprints (2022), a book on building AI and machine-learning systems.

Computer vision

Cameras are cheap sensors. With the right model they can count stock at a water point, check a crop row, read an analogue gauge or spot a defect on a production line. We build detection, segmentation and tracking pipelines, and we collect and label training data in the lighting, dust and camera angles of the real site.

For field cameras, we run the model on the device and send only the result: a count, a class, a position or a small cropped image. That turns a video problem into a few bytes, which a LoRa or satellite link can carry.

LLM agents that use your tools

Large language models are useful when they are connected to your systems and checked against known answers. We build agents that search your documents with retrieval, call your APIs as tools and write each step to a log. Each agent gets an evaluation set of real questions with expected answers, and we track its score with every change to the prompt, the model or the tools.

Controls match the risk. Tools are read-only by default, actions that change records or spend money need human approval, and personal information is redacted before it reaches a hosted model. Where data cannot leave your environment, we deploy open-weight models on your own hardware.

Edge inference

Running a model on the device saves bandwidth, works offline and responds in milliseconds. It also means fitting the model into a fixed budget of memory, compute and power. The tools we use:

• Quantisation. Converting 32-bit weights to 8-bit integers makes a model about four times smaller, usually for a small loss in accuracy, which we measure on your test set.
• Distillation. A small student model learns from a larger teacher and keeps much of its accuracy at a fraction of the size. Our sister company Vedametric builds distilled AI models.
• Runtimes. ONNX Runtime for portable deployment, TensorRT on NVIDIA Jetson modules, and TensorFlow Lite on phones and microcontrollers. The hardware decides the runtime.
• Hardware. Microcontrollers for small audio and vibration models, Linux boards with neural accelerators for light vision work, and GPU modules when a camera stream needs it.

MLOps: keeping models accurate

A model is at its most accurate on the day it ships. After that, seasons change, sensors age and behaviour shifts. We set up versioned training data, a model registry, reproducible training pipelines and monitoring that compares live inputs and outputs with what the model was trained on. When drift passes a threshold, the pipeline flags the model for retraining. Every model version can be traced to the data and code that produced it, which matters when someone asks why a model made a decision.

Questions