The AI services practices we ship from.
Twelve surfaces across the AI engineering stack, from autonomous agents to MLOps. Each is owned by senior engineers and runs the same eval-first build process. The practice changes; the rigor doesn't.
What we build.
Every practice runs the same discovery-to-run loop. The framework choices, team shape, and model selection change; the eval gates don't.
One build process. Every practice.
The six stops below run on a 4-week Pilot and a 16-week Production Build alike. The eval set authored in week 2 of a Pilot becomes the regression suite that blocks bad deploys a year later. Skipping it, or deferring it to "after the prototype", is the single most common reason AI projects fail silently: the system ships, the quality degrades, and nobody notices until a user complaint reaches a Slack channel at week 14.
Discovery
Workload shape, success criteria, data residency, cost target. No tooling picked yet, the eval surface comes first.
Spec
Written scope with measurable exit criteria for every phase. If we can't agree on what done looks like, we don't start.
Prototype
Minimal build against the eval set, enough to score, not enough to ship. Used to surface the hard unknowns early.
Eval gates
Domain-expert-graded examples re-run on every code change. Gates block a deploy the same way a failing test does.
Deploy
Auth, observability (Langfuse or equivalent), model fallback, cost guardrails, regression alarms baked in before launch.
Run
Weekly eval re-runs, drift alarms, prompt iteration log, model-upgrade regression checks. The eval set grows with usage.
Four ways to start, any practice.
The four shapes below apply across all twelve practices. A Pilot on an AI agent engagement looks structurally identical to a Pilot on a generative AI engagement, one scoped workload, one eval set, a demo, a build-or-stop memo. The domain-specific detail lives on the pillar pages.
One workload, scoped and scored in 2–4 weeks.
- One scoped workload, agreed in writing before work starts
- Eval set (30–60 examples) authored with your domain expert
- Two to three candidate approaches scored against the eval
- Working demo against your actual data
- Build-or-stop memo with a cost and timeline estimate for phase two
- Production deploy
- Auth, observability, or cost guardrails
- Multi-workload or multi-practice scope
Production system with eval gates baked into CI.
- All Pilot deliverables, or discovery from scratch if no Pilot ran
- Eval gates in the deploy pipeline, a failing gate blocks the deploy
- Auth, rate-limiting, cost guardrails, model fallback
- Observability (Langfuse or equivalent) from day one of staging
- Four weeks of post-launch iteration included in scope
- Runbook and eval-set ownership transferred to your team at close
- Ongoing retainer support (available separately)
- Fine-tuning unless the eval set justifies it
- Infrastructure you already own and operate
Read your system, root-cause the gap, no rebuild.
- Read of your existing system: code, prompts, retrieval, evals
- Scored run against your current eval set (or we author a minimal one)
- Adversarial and edge-case stress test of the live system
- Root-cause memo: where quality is leaking and why
- Prioritised fix-list with estimated effort per item
- Any code changes (Rescue engagement covers fixes)
- Rebuild or re-architecture
- Ongoing monitoring
Diagnose the failing layer, fix it, ship regression tests.
- Audit (weeks 1–2) to find the root cause before touching anything
- Targeted fix of the diagnosed layer, not a full rebuild
- Regression tests that would have caught the original failure
- Re-run of the full eval set to confirm the fix held
- Hand-off memo documenting what failed, why, and what prevents recurrence
- New features or scope added during the engagement
- Full architectural rewrite unless the diagnosis specifically requires it
Why every practice runs the same eval discipline.
The failure mode we see most often is not a wrong model choice or a bad prompt. It's a system that ships to production without an eval set. The team built the demo, the demo impressed someone, the prototype became the product. Months later, a user complaint surfaces in a Slack channel. The team digs in and discovers the system has been wrong on a specific query class for weeks, quietly, consistently, with no alarm to trip because there was never a measurement in place. The cost of the fix is manageable. The cost to trust is not.
Eval-first means the eval set precedes the prototype, not the other way around. Before we write a prompt or call an API, we agree in writing on what correct output looks like for a representative sample of your real workload, authored by your domain expert, graded against your standards. That set becomes the gate. A deploy that regresses the score doesn't ship. The eval set also becomes the diagnostic tool when something breaks in production: you run the set, the score drops, you bisect the change history, you find the commit.
This discipline applies identically whether the practice is RAG, fine-tuning, workflow automation, or a voice agent. The eval artefacts differ, retrieval recall and precision for RAG, task-completion rate for agents, output schema conformance for generative pipelines, but the structure is the same: explicit success criteria, graded examples, a gate that blocks bad deploys. Teams that skip this don't discover the gap at week 2; they discover it at week 14 when a real user finds it first.
The practical implication for a new engagement: the first two weeks of any build are not about the model or the architecture. They're about writing down what good looks like. If that conversation is harder than expected, if stakeholders can't agree on a scoring rubric, or if nobody has domain expertise to grade the outputs, that is the risk to surface and resolve before any code ships. We facilitate that conversation on every engagement. We've ended discovery calls by telling a prospective client that the org needs to resolve an internal disagreement about quality criteria before any engineering makes sense. That's the right call, even when it means a smaller engagement.
Cross-cutting tools, how we pick them.
These are the decisions that recur across all twelve practices. Each card shows when we reach for the tool and when we don't, the honest trade-off, not the vendor brief.
Fast to ship, top-of-class quality, no inference infra to operate.
Default for most workloads below ~500k requests/day. Data residency rules permitting.
When a regulatory ring-fence forbids third-party inference, EU health data, defence-adjacent, financial services with strict data mandates.
Claude Sonnet 4.6 as default reasoning model; GPT-5 for vision-heavy; Gemini 3.0 Pro for long-context document work.
Data stays in your cloud, fixed infra cost, adapters and weights you own.
Regulated workloads with residency rules, or very high volume where per-token cost justifies the infra overhead.
When the team has no ops capacity, self-hosted needs someone on-call for the inference layer.
Llama 4 / Mistral on vLLM with continuous batching. LoRA/QLoRA adapters where fine-tuning is warranted by data.
Semantic retrieval at scale, hybrid search (dense + sparse), metadata filtering.
Any RAG workload, long-term agent memory, semantic deduplication pipelines.
When the corpus is under ~10k chunks and a well-indexed Postgres full-text search covers the use case.
Qdrant for self-hosted; Pinecone for managed; pgvector when staying in existing Postgres is the right trade-off.
Quantified quality scores that block bad deploys, not vibes, not manual review.
Every production engagement, from week 2. Non-negotiable; this is the whole point.
Never skip. On short Pilots the eval set is smaller (30 examples), not absent.
Inspect AI for agent task eval; RAGAS for retrieval quality; Langfuse for production traces and LLM-as-judge scoring.
Durable execution, retry logic, multi-step agent coordination without hand-rolled state machines.
Workflow automation and any agent system where a mid-run crash would cost meaningful retries or user trust.
Simple request-response LLM apps don't need an orchestration layer, it adds latency and complexity for no benefit.
n8n for no-code-adjacent automation; Inngest for event-driven serverless; Temporal for long-running stateful agents.
Each major cloud has a different strength for AI workloads, provider lock-in is a real cost to manage.
AWS as primary (Bedrock + SageMaker + Lambda). GCP when Vertex AI or BigQuery is already in the stack. Cloudflare Workers for edge-latency constraints.
We don't build multi-cloud for its own sake, it raises cost and complexity without a proportional resilience benefit at most engagement sizes.
AWS-first. CDK for infra-as-code. Cloudflare for edge inference and static delivery.
Common questions across all practices.
Questions that apply regardless of which practice you're evaluating. Practice-specific questions live on the pillar pages.
How do I know which practice fits my workload?
Start with the output: if you're moving data between systems with minimal judgment required, that's Workflow Automation or RPA. If the system needs to reason, retrieve, or generate, it's one of the model-layer practices (LLM Development, RAG, Generative AI). If you want a system that takes multi-step actions with tools, that's AI Agents. If you have a running system that's underperforming, that's MLOps or a consulting engagement before any rebuild.
The contact form asks you to describe the workload in one sentence, that's usually enough to route you. If it genuinely spans two practices (common: RAG + Agents, or LLM Dev + MLOps), we'll say so and scope accordingly.
Can two practices ship in one engagement?
Yes, and it's common. A production AI agent almost always spans AI Agents + RAG + LLM Development, the agent is the orchestration layer, RAG is the retrieval layer, and LLM Development is where model selection and eval live. We scope these as a single engagement with a unified eval set, not three separate SOWs stapled together.
What we don't do: scope two practices in one engagement when the work genuinely runs in sequence. If you need a consulting engagement to clarify what to build before the build starts, that's two phases, not one, and conflating them is how scope creep starts.
What's the actual difference between Pilot, Build, Audit, and Rescue?
Pilot is a bet-sizing exercise. One scoped workload, one eval set, a working prototype. The deliverable is a demo plus a build-or-stop memo, not a production system. Fixed scope, 2–4 weeks.
Build is production. Eval gates baked into CI, observability, auth, cost guardrails, model fallback. It starts where the Pilot ended. 8–16 weeks depending on scope.
Audit is a read-only engagement. We don't touch your code; we read it, run your system, stress the eval surface, and hand back a prioritised fix-list and a root-cause memo. 2–3 weeks.
Rescue is an Audit where we stay to fix it. We diagnose the failing layer, usually eval debt, a poisoned retrieval index, or a prompt that was never stress-tested, and ship the regression tests that prevent the same failure next quarter. 4–6 weeks.
How does eval-first change the process if my team has no ML experience?
The eval set is the only ML artefact your team needs to own long-term, and it doesn't require ML expertise to write, it requires domain expertise. An eval example is a question your system should answer, plus a graded correct answer your subject-matter expert signs off on. A lawyer can write legal-domain eval examples without knowing what a transformer is.
What eval-first changes in practice: it front-loads the hardest conversation (what does "good" look like for this output?) to week 2 instead of week 10 when a user complaint surfaces it. Teams without ML experience are often surprised that this is the bottleneck, not the model, not the code, but whether anyone in the organisation can grade the output consistently. We facilitate that process, but the domain knowledge has to come from your side.
How is pricing structured across practices?
Fixed-scope per engagement, quoted up front. Pilots and Audits ship on a fixed fee tied to a written scope and exit criteria; Production Builds are scoped after the Pilot or Audit closes so the number is anchored in real eval data, not a guess. Rescue engagements quote after the diagnostic week so we're pricing the actual fix layer, not a sales estimate.
We don't price on team size, scope and deliverables drive the number. Every quote ships with a written scope, eval gates, exit criteria, and a line explaining what we'd descope first if the budget needs to come down. For specific dollar ranges, talk to engineering, we'll scope to your workload in the discovery call.
When do you say no?
When nobody can grade what good looks like. Every AI system we ship needs a measurable eval surface, if the output is inherently subjective and the stakeholders can't agree on a scoring rubric, we're not the right team. We'll say this in the discovery call rather than take the engagement and deliver something neither side can evaluate.
We also say no to research POCs with no path to production, projects where the real ask is headcount augmentation rather than a shipped system, and anything where the success criterion is "impress the board demo" with no production follow-through. The pattern we've seen too many times: a flashy demo, six months of slide-deck iteration, and a production system that never ships because the eval set was never written.
Describe the workload. We'll route you.
One sentence about what you're trying to build is enough to map it to the right practice and suggest an engagement shape.