Sirotics Start a project
Work Capabilities AI Research Sectors Approach Insights About Start a project

Active again,
and narrower.

Sirotics is a product innovation consultancy. We took a deliberate pause, and we are opening up again with a tighter definition of what we do, a first spinout already shipping, and a much shorter list of the markets we claim to understand.

Taking on new programmes

We are booking discovery sprints and feasibility studies now, with programme capacity opening progressively.

Why now

The gap we
came back for.

Three things changed at roughly the same time, and together they created a kind of work that very few firms are actually set up to do.

Frontier technology became genuinely deployable. The regulatory frameworks around it started to firm up. And the companies that need it are mostly not organised to build it: they have either the domain expertise or the technical depth, rarely both, and almost never the connective tissue between them.

That connective tissue is the entire proposition. It is also why we would rather be a small firm that goes all the way through than a large one that hands over at the interesting part.

This time

What we
changed.

A pause is only useful if you come back different. Three decisions shaped how Sirotics is set up now.

Fewer sectors, known properly

We cut the sector list to six. In each of them we can be useful in the first meeting rather than spending the first month learning the vocabulary, and we say so plainly when a programme sits outside them.

One team, all the way through

No handover between a strategy group and a delivery group. The people who frame the problem stay on it through engineering and validation, which removes the most reliable source of lost context in consulting.

Evidence built in, not bolted on

Regulatory and clinical thinking sits inside the product team from day one. It is the single change that most reliably protects a schedule in the markets we work in.

The team

How a Sirotics team
is put together.

We staff to the problem rather than to a standard template. A typical programme team draws on some of these roles, and the mix changes as the work moves through the stages.

Programme lead

Accountable for the whole thing. Senior enough to change direction without convening a committee.

Systems architect

Owns the architecture, the interfaces and the requirements the rest of the work is verified against.

Design researcher

Field research, human factors and use-related risk, the inputs everything downstream depends on.

Industrial designer

Form, interaction and CMF, working directly against mechanical and manufacturing constraints.

Product designer

Interfaces, design systems and the software experience, from clinician tooling to patient apps.

ML engineer

Models, evaluation harnesses and the honest answer about what the data will support.

Embedded & electronics

Firmware, PCB and power. Usually the first people to find out what the mechanism really needs.

Mechanical engineer

Mechanism, tolerance, materials and DFM, through tooling and into pilot builds.

XR engineer

Headset-native development, interaction and the performance budget that keeps sessions comfortable.

Robotics engineer

Controls, kinematics and autonomy, plus the test rigs that turn hopes into failure rates.

Quality & regulatory

Design controls, risk files and pathway strategy, embedded in the team rather than reviewing from outside.

Clinical & evidence lead

Endpoints, study design and validation, involved while the architecture can still respond to them.

Working together

What it's actually
like week to week.

Consultancies are usually vague about this, which is strange, because it is the part clients live with.

Cadence
A fixed weekly rhythm: one working session with your team, a written update every Friday, and a demo or decision point every two weeks. No status meetings that exist to generate status.
Tooling
We work in your repositories, your tracker and your document system wherever possible. Where you do not have one yet, we set up something conventional that you can keep.
Access
Direct contact with the engineers and designers doing the work. No account manager sitting between you and an answer.
Documentation
Written continuously, not assembled at the end. Decisions are recorded with their rationale, which is what makes a design history file useful rather than merely compliant.
On site
Where the work needs it: field research, usability sessions, lab integration, hardware bring-up and manufacturing transfer. Otherwise remote, so the calendar stays predictable.
Ending well
Every engagement has a defined handover: documentation, walkthroughs and a period of supported transition. We plan for you not needing us.

Spinouts

Kerneta, and the
.dai format.

Kerneta is our first spinout. It builds DaiDocs and the open .dai format, a way to store an AI assistant's long-term memory as plain text files you own, portable across Claude, GPT, Gemini, Cursor and local models. It currently ranks 2nd on LongMemEval-S, the standard AI memory benchmark, 1.8 points off first place while using roughly a third of the tokens.

It began the way most useful infrastructure does: as an internal fix. Long-running AI programmes kept losing their own history, and every team was rebuilding the same fragile memory layer. Rather than solve it once per client, we solved it properly and made the format open.

We spun it out because a format only becomes a standard if it is not owned by one consultancy's client list. It is Apache 2.0, separately held as Siro Robotics Ltd, and free to adopt with no relationship to us at all.

Careers

We're building the
bench again.

As Sirotics ramps back up we are talking to senior engineers, designers and researchers who want to work on hard problems all the way through, not just the part that fits in a sprint.

We are particularly interested in people with real regulated-market experience, and in the rarer profile that can move between hardware and software without treating either as somebody else's problem.

Introduce yourself
What we look for
  • Depth in one thing, working literacy in the neighbouring things
  • Comfort saying "I don't know yet, here is how I'd find out"
  • A record of finishing: shipped products, not just explored ideas
  • Willingness to be the person who raises the awkward risk early

No open listings at the moment. We read every introduction and keep them on file for when a programme creates the right seat.

Next step

Let's find out
if we're a fit.

Thirty minutes, no deck, no pitch. Bring the problem you have been going around in circles on.