Forward-deployed AI engineering
Your AI pilot worked. It still isn't in production.
We put engineers inside your team and your systems, pick one workflow with a number attached, and take it all the way to production — measured against a baseline you agreed before we started.
Why we exist
Most enterprise AI never leaves the demo. The gap is almost never the model — it's the method: the data access, the permissions, the evaluation harness, the fallback when it's wrong, and the team that has to run it on a Tuesday.
Nobody owns that work, so it doesn't get done, and a capable pilot quietly becomes a line item. It can't be delivered from a deck either, because it is specific to your stack. It has to be built next to the people who will inherit it. That is the whole reason this firm exists.
One pattern worth knowing: programmes rarely fail during the build. They fail earlier, in the stretch where nobody managed to turn an ambition into a scoped, measurable use case. That is where we spend our first weeks, and it is why some of them end with us telling you not to build.
What we build
The work, concretely
These are the shapes of problem we take on. Each one is a workflow a team already performs by hand, at volume, where the cost of doing it is visible in a system you already own.
Intake triage & routing
High-volume inbound work arriving through several front doors with no consistent classification. Agents classify on arrival, attach the missing context, and propose a route for one-click confirmation.
Duplicate consolidation
During an incident the same issue is reported dozens of times and linked by hand. Agents match each arrival against open work on both meaning and structure, propose a parent, and catch the late stragglers.
Grounded answers for the frontline
Answers scattered across four systems, written for engineers rather than the people asking. Retrieval inside the tool your team already works in, with citations and an explicit confidence score.
Knowledge that maintains itself
The opposite problem: a corpus decaying in silence. Agents find the recurring issues no article covers, flag the drift between what resolvers did and what the article says, and draft the fix for an owner to approve.
Change & approval review
Volume far beyond review capacity, so most of it is sampled or waved through. Agents do the pre-work, score each record against your own control checklist, and hand reviewers a ranked agenda with the evidence attached.
Blast-radius assessment
Work rated low-risk because nobody mapped what depends on it. Agents walk the dependency graph for affected services, criticality and schedule conflicts — and say plainly where the mapping is too thin to trust.
Closed-loop remediation
Alerts that a person triages, researches and fixes by hand with no verified loop back. Agents enrich, validate the target asset, execute through your existing automation once a human approves, then confirm the alert actually cleared.
Document-heavy drafting
Formal artefacts assembled by reading hundreds of source documents. Parsing to structure the history, drafting to your template and precedent, a human reviewing before anything leaves the building.
Closure integrity
A free-text box where partial failures get recorded as clean successes. Agents draft the closure record from what actually happened and link the work to the incidents it caused — so the next decision has honest history behind it.
Intake quality at the source
A long form filled in badly, then weeks of chasing. Agents pre-fill from similar past requests, pull fields out of attachments, and catch the gaps before submission rather than after.
Coordination & chasing
Cyclical processes that stall on getting decisions out of people across email and chat. Agents identify the accountable owner, run the follow-up, and close the loop back to the system of record.
Evaluation harnesses
The part most teams skip. A golden dataset and a scoring suite — exact comparison where the output is structured, judged scoring where it's prose — so a model or prompt change becomes a measured decision.
Not on this list? The test isn't the technique. It's whether the work happens at volume, in a system with real history, with someone accountable for a number it affects. Bring it and we'll tell you honestly.
Engagements
Three ways in
Which one you start with depends on two things: whether there is already work running in systems we can mine on day one, and whether an executive has committed to a specific, high-value use case. Most clients start narrow and widen.
Start from what you already run
You have workflows at volume in systems with real history, but no single flagship use case yet. We mine your own schema, volumes and audit trail and put the first agents into production quickly, because the evidence we need already exists.
Start from the use case that matters
An executive has named the outcome and will sponsor it, but the ground is greenfield. We build the data and evaluation foundation alongside the agent, against a target written down before sprint one.
Both at once
You have the running workflows and the sponsored outcome. Two tracks in parallel: quick operational wins that earn trust and fund the programme, and the strategic build that changes how the function works.
The engagement
Four phases, every time
Whichever way you come in, the shape does not change. Qualification decides whether we engage at all; discovery sets up the build; the build ships in two-week sprints; and the last phase exists to prove the number and get out of the way.
| Phase | Length | What happens | Done when |
|---|---|---|---|
| Qualify | 2–4 weeks | Confirm the workflow, the sponsor and the metric. Decide which way in — or that we're the wrong firm for this. | A named sponsor, a named metric, an agreed entry point. |
| Baseline | 3–4 weeks | Environment and access set up. Each KPI defined as a query against your production data and agreed in writing. Scope and architecture fixed. | A signed one-page baseline and a Phase 1 scope with explicit exclusions. |
| Build | 6–12 weeks | Two-week sprints. A working agent in front of users early, behind human review. Evaluation suite grows with the build. | In production, used by the real team, measured against the baseline. |
| Prove & hand over | ~4 weeks | Monitored in production against the baseline. Runbooks written, your engineers running it with us watching. | An agreed value number and a team that no longer needs us. |
Method
Work backwards from the outcome
The agent is the last design decision, not the first. This is the discipline that separates a number from a demo, and we apply it to every engagement without exception.
Start from a pain somebody can price
Chosen because a sponsor can name the problem and what it costs — not because the technology is interesting. "It would be useful if…" is not a starting point.
Find a metric you actually control
If the agent works perfectly, does this number move directly? A KPI that needs three teams outside the scope to cooperate is not a target, it's a hope.
Write the outcome sentence first
One sentence stating the target. The capability list falls out of it. If the capability list came first, the scope is already wrong.
Build the baseline before the agent
Two weeks of your own data beats six months of industry benchmarks. Write the query before the prompt, and get the number agreed in writing while nobody yet has a reason to prefer a different one.
Prove the value exceeds the cost
Productivity value, minus running cost at target volume, minus what it takes to build and keep it alive. If that isn't comfortably positive, we rescope rather than build and hope.
We will tell you when the arithmetic says no. Finding that out in week one is the cheapest good news available; finding it out after launch, in front of a steering committee, is the expensive version of the same discovery.
Delivery
Production-grade beats demo-quality
Three things run in parallel through every build, because a working system that nobody adopts and a popular system that moves no number both count as failures.
The system
A production-grade build: monitoring, cost controls, empty-result handling, and a validation gate after every significant step.
The number
Continuous measurement against the agreed baseline, netting out overlaps so two levers never claim the same saved hour.
The adoption
Enablement for the people whose work changes, and runbooks for the team who will own it after we go.
Autonomy is earned, never assumed
Every agent is classified by the cost of being wrong, and that classification sets how much it is allowed to do. Everything ships at the first tier, whatever the demo looked like.
| Tier | What the agent does | Applies to |
|---|---|---|
| Recommend | Surfaces a recommendation and its evidence. A person reviews and executes every action. | Everything, at go-live. |
| Act with approval | Executes, but stops for human approval before anything irreversible. | Agents that change records or start fulfilment. |
| Act alone | Runs unattended. | Low-stakes agents only, after a formal review against pre-agreed accuracy benchmarks. |
No agent of ours blocks, rejects or modifies a record of consequence without a human in the loop. Moving up a tier needs evidence from production and your sponsor's sign-off, not our enthusiasm.
The retrieval layer comes first
Most disappointing agents are retrieval failures wearing a model's clothes. We build the grounding layer before the agent, and we build it narrow.
Pointing a model at your entire history sounds thorough and behaves badly: it bloats context, it costs more, it is slower, and when somebody asks why the agent said that, "the embeddings returned these" is not an answer you can defend. We curate instead — a governed set of sources worth retrieving from, graded by how much weight each deserves, with provenance attached. Curation is expressed as rules and patterns, never record by record, because hand-tagging does not survive contact with six figures of records.
What you get, and what you don't
- The working system, in production, on real work
- The evaluation suite and golden dataset behind it
- Dashboards measuring against the agreed baseline
- Architecture notes and the decisions behind them
- Runbooks, a path-to-production guide, and knowledge transfer
- Ongoing support or managed service
- Enterprise-scale load testing
- Platform administration and upgrades
- Organisation-wide training and change management
- Security, privacy and compliance certification
The right-hand column is deliberate, not a gap. Those are real needs with real owners; pretending a build team covers them is how programmes end up with nobody accountable for any of it. We name them at qualification so they are somebody's job before go-live, not a surprise after.
What goes wrong
The failures we design against
We have seen each of these kill a programme that was technically fine. Naming them early is cheaper than discovering them late.
| Failure | How it shows up |
|---|---|
| The vanity metric | A KPI that looks commanding in the board pack and isn't actually moved by the agent. |
| The unverifiable baseline | "The industry average is thirty percent." If it wasn't measured in your system, it isn't a baseline. |
| Cost blind spots | Running cost modelled at pilot volume. Production volume turns a positive case negative. |
| Scope drift to the demo | Features that present well in a review and move no number. Re-anchoring to the target is a sprint ritual. |
| Launch and leave | Nobody reports the net value monthly, so the gains drift invisibly and the next budget cycle has no case. |
| Double-counted savings | The same saved hour claimed under two initiatives, inflating a total that later collapses under scrutiny. |
Fit
Who this is for
- You have pilots that impressed people and changed nothing
- The work runs at volume in a system with real history
- An executive owns a number they want moved this year
- Your engineers want to learn this, not outsource it forever
- Someone internally can grant real systems access
- You want a strategy deck with no build attached
- You want staff augmentation priced by the seat
- The goal is an announcement rather than an outcome
- The target metric belongs to a team outside the scope
- Access to real data is six months of paperwork away
About
Small on purpose
Applied AI FDE is a specialist practice, not an agency. The people who scope the work are the people who build it, and we take few enough engagements that this stays true. We would rather turn down a poor fit than staff it.
To fill in: your name, your background in a line or two, and why enterprise AI delivery specifically. This is the section buyers read hardest, and the one thing that can't be drafted for you.
Contact
Tell us what isn't shipping
A short description of the workflow and what's blocking it is enough to start. If we're not the right fit we'll say so, and point you somewhere better.