Build it

AI Engineering

Production AI systems built by people who spend the rest of their time attacking them. Evaluation harnesses, retrieval pipelines, agent orchestration, and the serving infrastructure underneath — designed so the security review and the invoice both hold up later.

Scope an engagement

Engagements from £16,000. Or start with a Exposure Review from £4,500.

What an engagement looks like

Scoped as fixed-window work with a written deliverable. No retainers you cannot exit, no findings held back for a follow-on sale.

Principle

If you cannot measure the behaviour, you are not engineering it.

A great deal of AI work is shipped on vibes: someone tries a dozen prompts, the outputs look reasonable, and it goes live. Then the model version changes, or the corpus grows, or a user phrases something unusually, and there is no way to tell whether the system got worse because there was never a measurement.

Every build engagement starts with the evaluation harness — not because it is glamorous, but because it is the only thing that makes every subsequent decision checkable. It is also what turns a security finding into a regression test instead of a memo.

  • Design constraint

    Guardrails outside the model

    Anything enforced only by instructions in the prompt is a request, not a control.

  • Design constraint

    Authorization at query time

    The index enforces the caller’s permissions, not the ingestion job’s.

  • Design constraint

    Side effects are idempotent

    An agent that retries must not double-charge, double-send, or double-delete.

  • Design constraint

    Substitutable inference

    Model choice is a configuration decision with a measurable answer, not a rewrite.

Questions we get asked

Do you build production systems or just advise?
We build. Engagements produce running code in your repositories, under your review process, with your team involved throughout — the goal is that they own it fluently when we leave. We are not interested in becoming a dependency you cannot remove.
Which models and frameworks do you work with?
We are deliberately model-agnostic and design for substitution, because the frontier moves faster than most procurement cycles. In practice that means an abstraction at the inference boundary, an evaluation set that makes swapping measurable, and no framework in the critical path that we would not be willing to fork.
Why does the security practice touch the build work?
Because retrofitting authorization onto a retrieval pipeline is far more expensive than designing it in, and because the failure modes we spend our time exploiting are cheapest to prevent at the architecture stage. Build engagements get security review as part of the work, not as an upsell.
Can you take over an existing system?
Yes, and it is a common starting point — usually a prototype that reached production faster than intended. The first phase is an honest assessment of what is salvageable, which occasionally concludes that a component should be replaced rather than repaired. We will say so plainly and cost both paths.
What size team do you field?
Small and senior. Boutique is a deliberate constraint, not a stage we are trying to grow out of — it is why the same people who scope an engagement are the ones who deliver it. It also means we turn work down when we are full, and will tell you that rather than staffing it thin.