Services · What we do
Three lines of work.
We turn one down for every one we take.
We're not generalists. Most engagements fall into one of three shapes. Below: when clients hire us for each, what we ship, and what we won't do.
Agentic systems
Production agents that survive contact with real users.
The demo works. The first hundred users break it. We design the system you actually deploy: a planner that fails gracefully, a tool layer with real auth, an eval harness the team can read, and guardrails that hold under adversarial load.
- When clients hire us
-
You have a prototype that's good enough to demo and not nearly good enough to ship. Or you have something in production and the unit economics don't work. Or you've shipped and the support volume is now its own engineering problem.
- What we ship
-
- Planner / orchestrator written for observability first, intelligence second
- A tool layer with real auth, real rate limiting, real audit trails
- Eval harness the team can extend without us: golden sets, regression suites, drift checks
- Guardrails: input validation, output filtering, prompt-injection defences, kill switch
- A staged rollout: flag, canary, shadow mode, full production
- Documentation written for the engineer who joins six months after we leave
- What we won't do
-
We won't build an agent for a problem that doesn't need one. Half the prototypes we audit could be replaced by a deterministic pipeline with one LLM call at the end. If that's what your problem looks like, we'll tell you in the First Hour.
Engagement
4–9 months
Team
2–4 engineers
Handover
90-day own-it window
ML models
Models built for the cost and latency budget you actually have.
We start by closing the loop between feature store, training, and the live request path. The model itself is usually the last question, not the first. It's often the easiest, too.
- When clients hire us
-
You have a research team shipping notebooks and an engineering team that can't put them into production. You have a model in production that drifts, and no one knows why. You have a vendor model that costs more than the revenue it produces.
- What we ship
-
- A feature platform research and production agree on: one specification, one code path
- Training pipelines that produce deployable artefacts, not just metrics
- A live serving path that hits its latency budget under real load (usually the actual problem)
- Monitoring on the inputs (drift, distribution), not just the outputs (accuracy)
- A model registry, if you need one. If you have one, we'll work in it.
- Cost analysis: per-request, per-customer, per-business-outcome
- What we won't do
-
We won't build a research function. We're an engineering practice. If your problem is "the science isn't there yet" we'll tell you, and probably name people who could help. We're not interested in chasing benchmarks.
Engagement
3–7 months
Team
2–3 engineers + ML lead
Handover
Runbook + on-call rotation transfer
Platform scaling
When a working product starts cracking at the seams.
The first ten million users find the corners of your architecture you'd rather they hadn't. We rebuild the hot path (usually data, often infra, occasionally the team's habits) so the next ten million don't break it.
- When clients hire us
-
P99 latency is creeping up and on-call is getting worse. A founder-engineer left and the platform's institutional memory left with them. You're about to launch in a new region and don't trust the failure modes. The migration has been "next quarter" for four quarters.
- What we ship
-
- An honest map of the system: what's load-bearing, what's vestigial, what's quietly on fire
- Targeted rebuilds of the hot path: usually one or two services, not a rewrite
- A data layer that won't be the next bottleneck: partitioning, caching, read paths, indexes
- SLOs that mean something to the business, monitored on the metrics that move them
- Runbooks, on-call training, and an incident process the team will actually use
- Sometimes: hiring help (JD writing, interview design, pairing with the new senior hires)
- What we won't do
-
We won't do a big-bang rewrite. We've never seen one work. If your problem genuinely requires one, we'll tell you and walk away. Find a build-from-scratch shop. If it doesn't, we'll show you the smaller cut that solves the same problem.
Engagement
6–12 months
Team
3–6 engineers + lead
Handover
Pair-and-fade with your team
What we don't take on
Being specific about this saves both of us time.
- Staff augmentation under three months. Below that horizon we can't materially change anything and we just slow you down.
- Unfunded MVPs. We're not the right shop for "build us a prototype" with no scaling problem behind it. There are good shops for that. We're not one of them.
- Pure data-engineering rip-and-replace. ETL-only work without a modelling or scaling problem isn't where our seniority is most useful.
- Customer support automation as a primary objective. Adjacent to what we do; not core.
- "Use AI somewhere." If the brief doesn't start with a customer problem, we'll politely decline.