What forward deployed engineering means

Work usually arrives as one of three things. We’re seeing this. We want to see this. We need a thing here.

All three are a result somebody wants, with a route to it already worked out. My job is to ask why that’s the right route and what got you there. Not to doubt it. Retracing it out loud is the cheapest test that plan will ever get. Usually it’s the business that spots the gap, not me.

Where the term comes from

Who named it and what it describes

“Forward deployed” is borrowed from the military: a unit stationed close to where things happen rather than back at base. Palantir used it first for engineers working inside a customer’s business. OpenAI and Anthropic now use the same title.

Strip the branding and it means something ordinary. An engineer in your meetings, on your systems, with the people who do the work, rather than taking a description of the problem away and returning with something. I’ve worked this way for twenty years. The industry has only recently given it a name, which is useful, because it’s hard to ask for a thing that doesn’t have one.

Why it works

Spotting the sticking plaster before you build it

What a plan worked out in-house carries is everything that went into it, assumed rather than stated. Every plan does that; it’s how thinking works. It does mean the assumptions underneath have never had to survive being said out loud to somebody who doesn’t share them.

I don’t know your business, so it all gets explained to me. Explaining it changes the language people use about it. Once the issues are in plain terms they get weighed differently. You’ll spot things. I just keep asking. There are no silly questions at that stage, because I’m the one who doesn’t know anything.

It’s also the cheapest way to test a solution. What usually surfaces is whether the thing being asked for is a fix or a cover for something further down. Often it’s a cover. Often it’s still worth building.

Without knowing which, the quick fix gets wired into everything around it. Replacing it later means replacing the lot.

A conversation costs very little. Building blind costs whatever it costs. Then it costs again when it has to come out.

Why it needs the room

The team joins in

The people who do the work know where the awkward bits are. In my experience nobody has asked them before, so the first session tends to turn into them telling each other things.

You know how the work actually happens, whether that’s food-safety records or anti-money-laundering checks. I know what software can do about it. It takes both.

Three things follow from being in the room rather than on a call:

1. 01

   Questions get answered when they come up

   Not at a weekly call four days later, by which point I've either guessed or stopped. The people who have to live with a decision are the ones making it, which suits an SME where the owner is still elbows-deep in the work.

2. 02

   There's no change-control to go through

   When what we learn changes the answer, the software changes. There's one person to tell and one person to do it. On a fixed scope that same discovery becomes a variation to negotiate. The usual outcome is that it doesn't happen.

3. 03

   You watch it being built

   The software runs on your own data, in front of the people who'll use it, while it's still cheap to change. Most of the useful corrections come from somebody watching over my shoulder saying that's not how we do it.

How the work is sized

One process at a time

The commitment people worry about is open-ended time. Reasonably. So the work is cut into pieces small enough to judge.

Pick one process: whatever is costing you most, in hours, money or people’s patience. Usually it’s obvious within a day of asking. It’s rarely the thing in the brief. Build that one thing and put it in front of the people who do the job. Then measure whether it saved what we expected it to save.

That last step is the one that gets skipped everywhere. It’s also the only one that tells you whether to carry on. If a process took four people two hours a week and now takes one person twenty minutes, that’s a number you can hold up. The confidence to keep going comes from evidence rather than from a plan written before anyone knew anything.

Where it matters most

Giving AI the freedom to act

Most people have used AI to answer questions, write content or analyse information. Agentic AI goes a step further. It can actually do things.

It might respond to customer enquiries, update records, prepare quotes or manage routine tasks. Instead of asking someone to do the work, you’re giving software permission to do it.

But how much freedom should it have?

Can it send an email without your approval? Change a customer’s order? Issue a refund? And what happens when it gets something wrong?

These aren’t really questions about AI. They’re questions about how your business operates, what you’re comfortable automating and where you want to keep control. Nobody answers them from outside, which is why this is the work that most needs somebody in the room.

You don’t need to train your own AI model.

That matters, because training one is not a small job. It needs a volume of labelled examples almost no business has. The budget is a research project’s.

Instead we use existing AI models alongside clearly defined business rules, permissions and safeguards. The agent knows what it can do, what it can’t do and when it needs to ask someone. Those rules are visible, testable and can change as your business changes.

I use this approach in my own software.

M7SEO is an agentic platform I’ve built to research websites, identify opportunities and prepare improvements. It uses existing AI models, with structured rules and checks controlling what happens next. It records its predictions and compares them with actual results, which is how I improve it.

That’s the approach I take when building AI into business software. Start with a useful job, establish the boundaries and give the system more responsibility as it proves itself.

You can read more about the practical considerations in what AI integration involves.

Proof

Three that worked this way

• A paper process, understood from the floor

  The brief was to digitise HACCP paperwork. Mapping the recipes and methods with the production team turned it into a system that manages production itself, guiding people through each stage while it captures the measurements and checks. The records are a by-product of doing the work now. The production knowledge is written down rather than carried by whoever has been there longest.

  HACCP compliance →

• A live platform, modernised without stopping

  artAML had businesses depending on it, so there was no version where the work paused for a rewrite. Being inside the team meant sequencing it against what they could absorb: the frontend and runtime moved forward with more than 1,200 tests kept green.

  artAML →

• One business, several different problems

  Vii Dohtem arrived as separate jobs: selling food, running a sharpening service, managing food-safety production. Treated as three projects it would have been three disconnected systems. Treated as one business it became one connected platform.

  Vii Dohtem →