Research areas
Memory & long context Agentic systems LLM adaptation In-house data extraction Pure research Past projects Applications Enterprise AI adoption Research to deploymentMore
AI Research Sectors Approach Insights About Start a projectWe run a real research practice, not a slide about one. It exists because the distance between a working prototype and a system a company can actually depend on is where almost all of the value is currently being lost.
Why we do this
Almost every organisation can now produce an impressive AI demo in a fortnight. Almost none can turn that demo into something that runs unattended, behaves predictably on their own data, and survives contact with the people who have to use it.
That gap is not a tooling problem, and buying a bigger model does not close it. It is a research problem about memory, retrieval, evaluation, failure behaviour and cost, the unglamorous parts that determine whether a system is trustworthy enough to put in front of a customer.
So the practice runs on two tracks. Applied work sits inside client programmes, and pure research runs alongside it with no deadline attached. Both are judged the same way: by whether the result ended up in something that shipped.
Research areas
Eight threads, chosen because each one repeatedly turned out to be the reason a client's system could not go to production.
Context windows keep growing and systems keep forgetting the things that matter. We work on what to keep, what to compress, what to retrieve on demand, and how a system should decide between them at runtime.
Agents are easy to build and hard to trust. The research is in decomposition, recovery from a bad step, knowing when to stop, and staying inside a cost budget nobody has to apologise for.
Making a general model good at your specific thing, and knowing which lever to pull. Most teams reach for fine-tuning when the answer was retrieval, or for a larger model when the answer was a better prompt contract.
The highest-value AI work in most companies is not a chatbot. It is turning twenty years of documents, scans, tickets, lab notes and legacy database fields into something structured enough to reason over.
Systems that read an image, a chart, a scan or a video feed and reason about it in the same breath as text, where most real industrial and clinical questions actually live.
You cannot improve what you cannot measure, and public benchmarks measure somebody else's problem. Building the evaluation set is usually the single most valuable week of an AI programme.
Unit economics decide whether an AI feature survives its first budget review. And a great many products cannot send data to a datacentre at all.
Our largest research thread, and the one we think matters most over the next decade. Perception, control and learning for systems that act in the world rather than only writing about it.
Pure research
A share of our time goes to questions nobody is paying us to answer. Not because it is a nice thing to do, but because the applied work stops being good if the only problems you ever look at arrived with a deadline.
Pure research here means open-ended, publishable, and free to fail. It is where the methods come from that later turn up inside client programmes, usually two or three years earlier than we expected.
What a model should learn from breathing, cardiac and movement data when almost none of it is labelled, and the labels that do exist came from a human scoring a trace by eye.
Pretraining on the enormous quantity of unlabelled recording that every sensor programme accumulates, so a downstream task needs hundreds of labelled examples rather than tens of thousands.
A model that is confidently wrong is worse than one that abstains. We work on calibrated confidence and on knowing when a sample sits outside the distribution the model was trained on.
What a system should keep, compress or fetch, and how it decides at runtime. This thread produced Kerneta and the .dai format, now a separate company.
Perception built on asynchronous change rather than frames. Shared with the Physical AI practice, where it meets real optics and real motion.
How to measure a system whose output is open-ended, and how to build a benchmark that still means something once people start optimising against it.
Selected research
Research we have taken far enough to know what is genuinely hard about it, rather than far enough to write a summary.
The question
Sleep apnea is diagnosed by polysomnography: a night in a lab, wired to a dozen sensors, scored by a technician. Most people who have it are never tested. Could a single microphone recording a night of breathing get close enough to be useful as a screen?
The approach
Recorded audio is converted to spectrograms, turning breathing into a time-frequency image where a trained model can see what a clinician hears: the snore, the silence of an obstructed airway, and the loud recovery breath that ends the event. Detection then becomes a pattern recognition problem over that image, with apneas and hypopneas separated by how completely airflow stops and for how long.
What is actually hard
Applications
The same model lands very differently depending on whether it ships as software or inside a physical product. The constraints diverge early, and the choice is worth making deliberately rather than by default.
Fastest to ship, easiest to change
Software gives you room. You can update weekly, run a larger model, and fix a bad decision in a release rather than a recall. The constraint is trust rather than compute: people have to believe the output enough to act on it.
Harder, and much harder to undo
Putting a model inside a product means committing to a compute budget, a power budget and a sensor years before you know what the model will need. Get it right and you own something a competitor cannot replicate in software. Get it wrong and the fix is a new revision of the board.
Three examples of the shape this takes.
The apnea research as a product: a microphone, an embedded processor and the model running on-device overnight, reporting an event index in the morning.
A dynamic vision sensor and an embedded accelerator inspecting parts moving too fast for a frame camera, deciding pass or fail in under a millisecond.
A body-worn sensor classifying breathing continuously at the edge, streaming events rather than raw signal so the battery lasts a useful number of days.
Whether inference runs on the device or in a datacentre is not an infrastructure detail. It sets your privacy posture, your latency, your unit cost and your regulatory surface, and it is close to irreversible once the hardware is committed. We would rather argue about it in week two than in month ten.
Enterprise adoption
Most AI programmes inside established companies do not fail technically. They stall somewhere between a successful pilot and anyone actually changing how they work.
We treat that as an engineering problem with a human systems component, not a training exercise, and we start from your data rather than from a platform someone wants to sell you.
What the work involves
A four-week AI readiness review: where the genuine opportunities are, what your data will and will not support today, and a costed shortlist of two or three things worth building first, with the ones we advise against and why.
The failure we see most
A pilot that succeeded on curated data, handed to a team with no evaluation harness, no monitoring and no owner. It degrades quietly for two quarters and is then quoted internally as evidence that "AI didn't work for us".
Research to deployment
The pipeline every thread above runs through. Each stage has an exit criterion, and work that cannot meet one does not advance just because it is interesting.
A rough, throwaway attempt at the hardest part. The only question is whether the approach is plausible enough to spend real time on.
Before building anything properly, we build the thing that measures it, using your data, your edge cases and a rubric your domain experts agree with.
Iteration against the harness, with the cheapest interventions tried first. Prompt and retrieval changes before fine-tuning; fine-tuning before anything exotic.
The unglamorous half: failure handling, rate limits, tenancy, observability, security review, and the interface that decides whether anyone trusts the output.
Models drift, providers deprecate, and your data distribution moves. Systems that are not watched degrade silently, which is the worst way to degrade.
Working with the research practice
Research engagements are scoped tightly on purpose. An open-ended research budget is how organisations end up with a lot of learning and nothing deployed.
Where the real opportunities are, what your data supports, and a costed shortlist of what to build first, including what not to build.
One hard question taken from spike through evaluation harness to a system that either clears your threshold or explains precisely why it cannot.
Researchers and ML engineers inside your organisation, on your data and your backlog, building capability that stays with your team when we leave.
Next step
If you have a prototype that works in a notebook and has been three months from launch for a year, that is exactly the conversation we want.