Engineer AI that
survives production.
Most AI work stops at the demo. Ours starts there. If you would rather own
a system people depend on than ship another proof of concept,
this is the kind of engineering we do all day.
No open roles right now — we still read every application.
The work is the pitch.
No ping-pong table in the copy. Three things about the job itself that are actually different.
You ship it,
then you run it.
The same engineer who builds a system watches it meet real traffic. You will write the evals, read the traces and fix what they surface — the part most AI work hands off or skips.
Eight capabilities,
seven domains.
Agents, document intelligence, conversational AI, governance. Insurance one quarter, aviation the next. One delivery system underneath, so range does not cost you depth.
Hard problems,
honestly scoped.
We tell clients where automation will not pay off. That honesty points inward too: you will not be asked to demo something we know does not hold up.
Six things on the board right now.
Not a wish list. This is the shape of the engineering behind every system we ship.
Multi-agent orchestration
A coordinator and specialised agents working across CRM, ERP, knowledge and file systems — holding state across steps that take minutes, not milliseconds.
Document extraction at real volume
Forms, PDFs and email attachments turned into structured fields with a confidence score and the source document still attached. The edge cases are the job.
Evaluation harnesses
Every run scored against targets committed to before the build started. If you cannot measure the agent, you cannot claim it improved.
Guardrails and human-in-the-loop gates
Scope, tone and policy checks on every request, and a review queue where a human decision is worth more than an automated one.
Platform integrations
ServiceNow, BMC Helix, Guidewire, Contentful, AEM. Enterprise systems with real constraints, where the interesting problem is rarely the model.
Observability and cost control
Traces, token accounting and latency budgets — so a system that works in week one still works, affordably, in week twenty.
The tools, named.
So you can tell before applying whether this is the work you want.
Agents & orchestration
Models & retrieval
Enterprise platforms
Runtime & delivery
You are not expected to arrive knowing all of it. You are expected to be the kind of engineer who reads the docs and the source when something does not behave.
No openings
right now.
We are not hiring for a specific seat today, and we would rather say so than collect applications against a role that does not exist. When a project opens one, it will be listed here — and the people who wrote to us first are who we go back to.
Send us your details →Skip the
cover letter.
One email to hr@sudoboat.com. We would rather read one honest paragraph about something you built than three about your strengths.
-
Something you shipped. A repo, a live URL, a screen recording. Side projects count. Coursework counts if it is real.
-
Something that broke. What failed in production or under load, how you found it, what you changed. This is the answer we read most closely.
-
Which part of the work fits you. Point at anything on this page and tell us why it is the bit you want.
-
A CV, plainly formatted. PDF is fine. It is context, not the deciding artefact.
Early in your career and missing half the stack? Send it anyway and say so. We would rather see how you think than how well you match a keyword list.
Build the durable thing.
No seat is open today, but the next one is filled from the people who already wrote to us. Tell us what you have built and what you want to build next.