Forward-Deployed Engineering

Engineers and agents, deployed inside your organisation, until the defined work runs in production, with your people deciding the exceptions.

A named senior engineer arrives with a team of agents, builds one workflow against your real records, cuts it over to real traffic and leaves. The agents stay. The system stays. Your people decide the exceptions.

A model of the engagement: the system that stays, with the engineer's station docked on it.
Engagement
One workflow, six weeks
First pull request
Day seven
Fee
Fixed before week one
After handover
The agents stay. We leave.

The last mile

The model was never the hard part.

What we usually find

  • 01A pilot that impressed the steering group and never touched the system of record
  • 02A model that answered well on last quarter's export and never saw a live case
  • 03Nobody who can say whether it is right, because there is no evaluation set
  • 04No one on your side with the keys, the context and the time to finish it
  • 05Several of these, in several departments, and not one in production

Forward deployment is the name for closing that distance from inside.

What goes forward

One engineer. A team of agents. Everything needed to leave.

You meet the engineer before you sign and the same person stays until handover: senior, one engagement at a time, in your repository and your standups. The agents come with them: coding agents that write the connectors and the tests, evaluation agents that score every candidate, operations agents that watch the system once it runs. And the kit that makes leaving possible from day one.

On site for scoping and the first days of embedding; wherever your team runs after that.

  • The engineer

    Senior. Named before you sign. One engagement at a time.

  • The agents

    Build, evaluate, operate. They stay when the engineer leaves.

  • The kit

    Connectors, an evaluation harness, a review desk, a runbook: patterns we have brought before, so nothing starts from scratch.

The first workflow

Six weeks, assembled in front of you.

Every week ends in something you hold. The parts arrive in this order on every engagement, whatever the workflow.

  1. W0Scope

    One page: the workflow, the metric that will judge it, the person who owns it, the exit gate. Signed before anyone starts.

  2. W1Embed

    Access granted, repository cloned, the first pull request merged by day seven. That merge is how both sides know the access is real.

  3. W2Golden set

    Real cases with known answers, agreed with the people who do the work. From here on, nothing is judged by a demonstration.

  4. W3Connect

    The connectors to your systems of record, written by the coding agents and reviewed by your reviewers, behind a feature flag.

  5. W4Review desk

    The exception path: what the agents hand to a person, who that person is and what authority they have. Staffed before cut-over, not after.

  6. W5Cut over

    Real traffic at real volume, rollback armed, monitoring live, the golden-set score as the argument for going ahead.

  7. W6Hand over

    Your engineers release, roll back and retrain it with ours in the room and off the keyboard. The runbook is signed when that goes cleanly.

Current week: W0 Scope

After week two, every run is against your records.

The exception desk

Autonomous where the rules are clear. A person where they are not.

Most of a workflow is routine, and routine is what the agents take. The rest goes to a desk: a few of your people with the context and the authority to decide, and an audit line for every case that reaches them. The desk is designed in week four and staffed before cut-over, because the exception path is where automation fails when it is an afterthought.

Three rules the agents work under

  • 01Nothing reaches a user that has not been scored against the golden set.
  • 02Nothing is merged that your reviewers have not approved.
  • 03Regulated decisions stay with the accountable person. A diagnosis, a payout, a denial, a hire: we automate everything around them, never them.

What reaches the desk is telemetry. A recurring exception becomes next month's automation.

The day we leave

The engineer leaves. The system stays. Then the next one.

Handover is the engagement's purpose, not its end. When your team has run the system without us, the engineer's access is revoked and what remains is yours: the agents, the code, the evaluation suite, the runbook, the decision record.

What stays, in your accounts

  • The agents

    Running under your account, each with an identity, scoped permissions and an audit log.

  • The repository

    Every commit yours from the first, reviewed by your reviewers, intellectual property assigned before week one.

  • The evaluation suite

    The golden set and the harness, wired into your pipeline so a regression fails the build.

  • The runbook

    Deploy, roll back, retrain, rotate, escalate; executed by your engineers before it is signed.

  • The context layer

    How your organisation decides, written down for the next workflow and the next model, portable across vendors.

  • The owner

    One person on your side who has released, rolled back and retrained it without us in the room.

  1. One workflow

    Six weeks. One system on your floor. Your desk decides its exceptions.

  2. One department

    Workflow after workflow, each with its own agents and its own exception path. The engineers gone; one desk for the department.

  3. The organisation

    Department by department.

No one is replaced by a slide. Each step is a workflow in production, counted.

2027–2028

Where forward deployment is going. We are building for what comes after it.

What the next two years change about this work, and what we already do about each.

Showing 2026

  1. 2026
  2. 2027
  3. 2028
  1. Agents do more of the deployment every year

    Today the engineer arrives with agents. Soon the agents write most of the integration and the engineer's job is judgement: what to automate, what counts as right, when to cut over. We already run it that way.

  2. The deliverable becomes context, not code

    Code is generated. What is scarce is how your organisation decides, written down so any model can act on it. The context layer you keep is yours and moves with you between vendors.

  3. Outcomes, not hours

    Hours pay for approaching a result. We price a workflow against an agreed outcome, fixed before week one, and invoice at the gate, not the date.

  4. Operations is the second half

    Releases gated on evaluations, drift watched, model swaps regression-tested, cost per completed case known. Running agents is becoming a discipline with a pager. Your team inherits the instruments, or we run it until they do.

  5. Every agent carries an identity

    Scoped permissions, a named owner, an audit log: the same as a person with a badge. Regulators in several markets are moving to require it. We ship it now.

  6. Sovereign by default

    Your cloud, your premises, or no network at all. The oversight roles, the logs and the stop procedure that high-risk rules will demand are part of the handover, not an add-on.

  7. The engineer fades. The desk remains.

    The industry expects the human forward-deployed engineer to shrink to a sliver of each deployment within a few years. We design for it: what stays is your exception desk and your own people, able to run and extend what we built.

  8. Physical AI arrives on the floor

    The next forward deployment is a robot fleet: policies fine-tuned on your floor, an engineer on site while the fleet learns, the same handover at the end. We deploy for physical work the same way.

Dates and rules move; the direction does not. Ask us what changed since this was written.

Two scales

One autonomous solution, or a programme across departments.

Forward-deployed engineering means our engineers work with your teams, inside your systems and on your data, on site, remote or hybrid as the work needs, until a defined piece of work runs in production. It comes at two scales.

  • AMost engagements

    Autonomous AI solutions

    One function, one workflow or one department: agents do the defined work; your people decide the exceptions.

    Task-specific agents, generative AI applications, knowledge systems and document workflows, each connected to the applications and data it needs. Each one ships with human approval where the work requires it, a log of every action and an evaluation against real cases. The offerings on this page are the ways in.

    Find your starting point
  • BActive development direction

    Enterprise AI transformation

    Departments, systems and data connected through governed agents, in phases.

    A programme for organisations that want more than one solution: discovery across departments, integration with the systems they already run, then governed agents department by department, each phase evaluated before the next one starts. It is a direction we are actively developing, described as a programme, never as a finished result.

    How the programme is phased

Need one capability rather than an embedded team? Our services are scoped, built and handed over one at a time.

Where to start

Pick the starting point. The plan reconfigures.

Every engagement is the same system in a different configuration. Choose where you are; the shape changes to match and the offerings that fit are listed.

You know the work and the date it matters by. Six weeks from a signed scope to real traffic.

OfferingShapeLeaves you with
  • 02

    Six weeks, one named engineer

    A system in production, its evaluation suite and its runbook

  • 07

    Runs inside every engagement

    An evaluation suite, monitoring and the thresholds that page someone

  • 08

    The last two weeks of any engagement

    A team that runs the system without us

All eleven offerings
OfferingShapeLeaves you with
  • 01

    Readiness & Scoping Sprint

    Two weeks inside your systems; one workflow scoped in writing.

    Two weeks, one engineer

    A scoped workflow, a success metric and a fixed price

  • 02

    Production Sprint

    One workflow from prototype to production in six weeks.

    Six weeks, one named engineer

    A system in production, its evaluation suite and its runbook

  • 03

    Embedded Engineering Pods

    A pod inside your repository and your standups, quarter by quarter.

    Quarterly, two to three engineers

    A shipping cadence your team keeps after the pod leaves

  • 04

    Pilot-to-Production

    A stalled pilot hardened, integrated and put in front of real users.

    Eight to twelve weeks

    A pilot in production, with go-live criteria met and recorded

  • 05

    Integration & Data Onboarding

    Your systems of record connected, your data modelled and governed.

    Scoped per system

    Connectors, a data model and retrieval with access walls intact

  • 06

    Regulated & Secure Deployment

    Inside your perimeter: your cloud, your premises or no network at all.

    Scoped per environment

    A deployment with zero data egress and an audit trail

  • 07

    Evaluation & Observability

    A golden set, a harness and dashboards, so a regression is caught before a user is.

    Runs inside every engagement

    An evaluation suite, monitoring and the thresholds that page someone

  • 08

    Handover & Enablement

    Runbooks, decision records and a trained team, at a dated exit gate.

    The last two weeks of any engagement

    A team that runs the system without us

  • 09

    Managed Operations

    We keep running what we built, at a flat monthly fee, until you take it.

    Monthly, after handover

    Uptime, monitoring and iteration, reported monthly

  • 10

    Engagement Models

    The shapes we work in, how long each takes and what we do not do.

    Reference

    The terms before the first call

  • 11

    The Engineers

    Senior only, named before you sign, one engagement at a time.

    Reference

    Who turns up on day one

Every shape has a fixed fee agreed before week one and a written end.

TermsScope, timing, staffing and commercial terms are agreed per engagement, in writing.

Questions

Twelve questions, answered before the call.

Start

Start with the workflowthat matters most.

A thirty-minute call with an engineer. You leave knowing whether the workflow fits, what it would take and what it would cost.