How we work

Four phases.
Three gates.
One system in production.

Most AI projects fail in the gap between a promising demo and a system that survives Tuesday morning. Our process is built to close that gap — every phase ends with a concrete artifact, and every gate is a real decision to continue, change course, or stop.

Walk the phases
Typical first ship
4–6 weeks
Gate decisions
3, written
Engagement shape
Fixed-scope phases
aether / engagements / northwind-retrieval
phase probe → build → harden → operate
gate 1 the case holds
gate 2 eval bar cleared
gate 3 on-call handover
evals 94% pass
p95 latency 1.8s · budget 2.5s
cost / request $0.0031
escalation rate 11% → human queue
A sanitized snapshot of a live engagement dashboard — the kind of record that accompanies every phase, not a mockup.
  1. 01 Probe 1–2 weeks
  2. 02 Build 3–6 weeks
  3. 03 Harden 2–4 weeks
  4. 04 Operate Ongoing

Probe

1–2 weeks · fixed fee

We start by trying to disprove the idea. A probe is a two-week inquiry into whether AI is actually the right lever for this problem — cheaper, faster and safer than discovering that six weeks in.

We sit with the people doing the work today. We read the ticket history, the SOP documents, the shadow spreadsheets. We take a sample of real cases and measure what a good outcome looks like — accuracy, time saved, escalations avoided — before touching a model. Then we build the smallest possible prototype and put it in front of three to five of those users.

The probe frequently ends with "don't build this." That is a success: you've spent two weeks to avoid a nine-month mistake. When it ends with "build this," you leave with a quantified business case, a task definition, a data inventory and an eval set already drafted from real cases.

You receive

  • Opportunity memo — the problem, proven or not
  • Task definition with measurable success criteria
  • Data inventory and access assessment
  • First-pass eval set (30–60 real cases)
  • Cost model and build/not-build recommendation

Build

3–6 weeks · scoped by deliverable

The build is where the prototype becomes a system. We work in weekly increments against the eval set from the probe, so at any point you can see exactly how much better the thing is getting and where it still fails.

Everything is instrumented from day one: retrieval quality, model calls, latency, cost per request, escalation events. We build the eval harness before the feature, because a system you can't measure is a system you can't ship.

We rarely hand you a new product to adopt. Where possible the build lands inside the tools your team already opens — a Slack bot, a panel in your CRM, an API your existing team can call.

You receive

  • Working system in staging, wired to real data
  • Eval harness with pass/fail report per increment
  • Architecture doc and runbook
  • Instrumentation dashboard — latency, cost, quality

Harden

2–4 weeks · before go-live

A system that works in staging is not the same as one that works at 3am on a Saturday. Hardening is where we make the failure modes boring, visible and survivable.

We break things on purpose: audit the prompt-injection surface, test with adversarial inputs, simulate a model provider outage, verify that fallbacks degrade gracefully. We add guardrails for the outputs where a wrong answer is expensive, and human-in-the-loop checkpoints where a wrong answer is unacceptable.

Most importantly, we hand over the muscle. Your team — not ours — runs the system through a go-live rehearsal, so the first real incident is not the first time they've touched it.

You receive

  • Threat model and prompt-injection audit
  • Failure-mode matrix with fallback behaviour
  • Alerting and on-call runbook
  • Rehearsal record and documented handover

Operate

Ongoing · retained or handed off

Models drift. Data shifts. Traffic patterns surprise you. We stay close after launch — either as retained operators or as a quiet call you can make — so the system keeps earning its place.

On a retainment we watch the dashboards, triage evals that dip, retrain or re-index on a cadence, and bring you a quarterly review of what the system is doing well and what it is quietly failing. You get a proactive partner, not a support ticket queue.

If you'd rather own it entirely, we do a clean handover: source, infrastructure, evals and docs, plus two months of on-call shadowing to catch anything we missed.

You receive

  • Quarterly quality and cost review
  • Drift monitoring and alerting
  • Re-index / retrain cadence with rollback
  • Ongoing eval maintenance

A typical engagement,
week by week.

Not every project follows this exact line, but a first system usually takes eight to fourteen weeks from scoping call to go-live. Here is where the time actually goes.

  1. Scoping call

    Forty-five minutes to understand the problem and confirm a probe is the right move.

  2. Probe

    Interviews, data sampling, prototype and the go/no-go memo.

  3. Build

    Weekly increments against the eval set. Staging ships from week five.

  4. Harden & rehearse

    Adversarial testing, guardrails, then a live rehearsal owned by your team.

  5. Operate

    Go-live with rollback ready, then monitoring, reviews and cadence.

What we optimize for,
in every phase.

Four principles that stay constant no matter how the project changes shape.

  • Measured or it didn't happen

    Every build carries an eval set from real cases. Quality, latency and cost are visible from the first increment to the hundredth.

  • Boring beats clever

    We pick the simplest architecture that clears the bar. Complexity is a liability we only accept when it buys measurable reliability.

  • Handover is the deliverable

    A system your team can't own isn't finished. We rehearse the handover before launch, not after.

  • Honest ends

    A "no" at gate one costs two weeks. A "no" eighteen months in costs a team. We tell you early, plainly, and in writing.

Questions we get
before gate one.

If your question isn't here, the scoping call is the fastest way to an answer.

Do we need our data ready before we start?

No. The probe includes a data inventory, and messy data is often the real finding. We work with what exists to judge whether it's usable, and tell you what would need cleaning or collecting before a build.

What if we already have a model or a vendor?

We work with it. A probe is often used to validate or challenge an existing approach before committing further. If something already works, we'll say so and focus on the gaps rather than rebuild for the sake of it.

Who actually does the work?

A small, named team: one lead engineer and one applied researcher from the same studio throughout. No handoff to a junior bench after the pitch. You'll know exactly who is on the project from the first call.

What happens at gate two if the eval bar isn't met?

We present the gap, the cause and the options: extend the fixed scope to close it, narrow the task to what passes, or stop. The decision is yours and the artifacts up to that point are yours regardless.

Can we start small and pause between phases?

Yes — that's the point of gates. Any phase can be the last. Many clients run a probe, decide to build, and then choose whether to hand off hardening to their own team or keep us involved.

Start with a probe

Two weeks to find out
if it's worth building.

The lowest-risk way in. We bring the process; you bring one problem you'd love to hand to a machine.

See contact details