Customer estates, not internal demos
Engineers work on production systems inside customer infrastructure. You will meet the people who use what you build, and you will hear about it when it is wrong.
Careers
Work on the part that is actually hard
Entity resolution over thirty-year-old systems of record. Evaluation suites that can stop a release. Agents with real authority. Estates that have to keep running when we are not there.
The work
Most of it is not model work, and that is the point
If you want to spend your time on prompt engineering, this is the wrong place. The interesting problems here are further down.
Working out which of four systems is authoritative for a customer's legal name, and getting someone to own that decision. Designing a tool contract that a model uses correctly ten thousand times a day and that a risk function can read. Building an evaluation suite that will block a release your own colleagues want to ship. Standing up an air-gapped estate in a country where the answer to "can you just download that" is no.
The engagements are long, the systems are real, and the consequences are visible. Several of our customers make decisions on this platform that materially affect people's money, health or livelihood, which is a reason to be careful rather than a reason to be slow.
How it works here
What you can expect
Long engagements
Typical delivery engagements run twelve to thirty months. You see the second year, which is where the interesting failure modes live.
Written decisions
Architectural choices are written down with the trade-offs and the alternatives rejected. It slows the first week and saves the second year.
On-call that is staffed properly
We intend to run estates for regulated customers, which means a rota. It is compensated and it is capped. We are small enough that cover is a real constraint rather than a solved problem, and we would rather say so than describe a follow-the-sun rota we do not yet have.
Time on the craft
One day a fortnight on tooling, internal platform work, research or writing. It is scheduled rather than encouraged, because unscheduled time does not survive a delivery deadline.
Remote, with reasons to travel
Most roles are remote within the region. Sovereign programme roles are on-site by necessity, and delivery roles involve customer time — typically a week a month.
Open roles
Where we are hiring
Applications go to the recruiting team directly. If nothing here fits and you think it should, write anyway.
Hiring
How the process runs
What are the stages?
An introductory call, a technical conversation about work you have actually done, a practical exercise on a realistic problem, and a conversation with the team you would join. Four stages, usually within three weeks.
Is there a take-home exercise?
Yes, and it is capped at three hours with the scope written to fit. We pay for it. If a candidate tells us it took longer, we treat that as feedback on the exercise rather than on the candidate.
Do you hire people without AI experience?
Frequently. Strong distributed systems, data engineering or regulated-industry backgrounds transfer well, and the platform-specific knowledge is teachable. What does not transfer easily is judgement about production systems with consequences.
What does the clearance requirement mean?
Sovereign programme roles require eligibility for national security clearance in the relevant country, which usually means citizenship and residency requirements. Eligibility is assessed before an offer; the clearance itself takes months and we sponsor it.
How much travel is there?
Platform and research roles: occasional, a few times a year. Delivery roles: typically one week a month at customer sites. Sovereign programme roles: on-site as the default.
Nothing quite right?
Write to us anyway
Tell us what you have built and what you want to work on. We read everything, and roles open more often than this page is updated.