Real ownership.Unreasonable problems.

What you would do

• Design and ship agentic pipelines that survive real inputs, not curated ones
• Own a client system end to end: scope, build, deploy, and the week after
• Write the evaluation before the feature, so drift is caught by a test rather than a phone call
• Sit with the people doing the repeating, and come back with what is worth automating

What you need

• Strong Python or TypeScript, and opinions about where each belongs
• You have put an LLM in front of real users and dealt with what came back
• Comfort with queues, retries and the boring half of distributed systems
• The instinct to ask what the work is for before asking what to build

What you would do

• Map silos, then design and build the connective layer between them
• Bi-directional sync with conflict rules a finance lead can read
• Wrap legacy systems that have no supported way in
• Migrate data without a weekend of downtime and a rollback plan nobody trusts

What you need

• Hands-on time inside Salesforce, SAP, Odoo, HubSpot or equivalents
• SQL you write without looking things up, and schema instincts
• Patience for undocumented APIs and vendor support queues
• You have owned a migration that could not be redone

What you would do

• Train and deploy detection, OCR and tracking models on client hardware
• Build the labelling and retraining loop the client's own team will run
• Take a model from a notebook to a camera on a factory wall
• Be honest, in writing, about what the system cannot see

What you need

• PyTorch, and enough classical CV to know when a model is overkill
• Edge deployment experience: ONNX, TensorRT, Jetson or similar
• Willingness to travel to sites, in shoes you do not mind ruining
• Evaluation discipline; a demo that works on your laptop is not a result

What you would do

• Design and build internal tools, platforms and services from an empty repository
• Turn a process walked through on a call into a data model that survives it
• Own a release end to end: tests, deployment, and the bug report a week later
• Leave code the client's own team can read, extend and run without us

What you need

• Strong TypeScript or Python, and production systems you can point to
• Sound instincts for data modelling, APIs and the boring half of reliability
• You have shipped something people depended on every day
• A preference for the simplest design that will still be right next year

What you would do

• Design serving and scheduling for inference workloads that are not cheap
• Build the deployment path once, well, so every engagement inherits it
• Observability that answers the question before someone has to ask it
• Decide, per client, between cloud, on-premise and the awkward mix

What you need

• Kubernetes, Docker and Terraform, at a depth beyond the tutorial
• You have been paged, and you fixed the class of problem rather than the instance
• GPU scheduling or high-throughput queues in anger
• A bias toward boring, well-understood infrastructure

What you would do

• Sit with a client's team and work out where their hours actually go
• Build the first release alongside the client's team, in the open
• Handle the handover: docs, evaluations, and the training that makes them stick
• Be the person the client calls, and the reason they call back

What you need

• You can ship code and run a room, and you enjoy both
• Enough breadth to be useful across automation, integration and data
• You write clearly; most of this job is written down
• Comfort with ambiguity that resolves only by asking better questions

What you would do

• Design and implement internal tools, copilots and dashboards clients will use daily
• Own our design system and the front of house it builds
• Prototype in code, because static mockups hide the hard parts
• Make dense, technical interfaces feel calm

What you need

• React and TypeScript to production standard
• Real typography and layout judgement; a portfolio that shows restraint
• Motion that serves comprehension rather than showing off
• Accessibility treated as correctness, not a checklist

What you would do

• Take a hard question from the bench to something we can demonstrate
• Build the evaluation harnesses the delivery teams depend on
• Write up what did not work, the negative results especially
• Decide when a Labs experiment is ready to become an offering

What you need

• You have taken a research idea all the way to something that ran
• Rigour about measurement, and suspicion of your own demos
• Writing that a non-specialist can follow
• Tolerance for the weeks where the answer is no