How We Do Forward Deployed Engineering at SIEL

Forward deployed engineering earns its keep in one situation: something technically complicated gets handed to people who are not technical and never intend to be. That is every engagement we take. We deploy into companies that do not have an AI team and will not have one after we leave.

Who We Actually Deploy Into

Our clients are manufacturers, distributors, healthcare providers and professional services firms. Real operations, real budgets, nobody whose actual job is AI. There is almost never an engineer on the other side to hand the system to. The people who will live with what we build are an operations lead, a finance manager, an IT generalist who already owns four systems and did not ask for a fifth. If they cannot understand it, run it and change it, we have not delivered anything. We have rented them a dependency.

The Audit Decides What Not to Build

Every engagement opens with a two-week workflow audit, and its most useful output is a shorter list than the one we walked in with. The first thing we ask for is not system access. It is a seat next to whoever handles the mess. We map what happens, not what the process document claims. The work lives in the exceptions, and so does the cost. Candidates get scored the same way every time: time saved, error rate, volume, strategic value, implementation risk. The last one kills more good-looking ideas than the other four combined.

Before anything gets built, the baseline and the target go in writing. This case takes three hours today. If it takes twenty minutes and the error rate holds, is that success? A qualified answer means we are not ready to build.

At one distributor, invoice matching was the workflow everyone pointed at. The clean path was already fine. The cost sat entirely in the invoices that did not clear, where a single mismatch waited days on the one person who knew the supplier history and happened to be on leave. We rebuilt the exception path and left the clean path alone. Three other workflows on that list we recommended not touching for a year.

Every system we ship lands on a team with no slack in it. Naming the workflows to leave alone is the harder half of the job, and it earns the right to build the rest.

We Build on What Is Already There

We wire agentic systems into ERPs, CRMs, document stores, the shared drive everyone pretends is not load bearing. Nobody who spent years getting onto their current stack will migrate off it for an AI project, and nobody should be asked to. What we do not let happen is an AI project quietly becoming an infrastructure migration, which is how engagements lose their sponsors in month three.

The same pieces surface every time. Exception routing, approval gates, cost ceilings, audit trails, tests that prove a workflow behaves before it reaches production. First time we build it for the client, second time we build it to be reused, and there is no third time we write it from scratch. Only workflow logic and integrations stay client-specific. Rebuild the foundations on every engagement and each deployment adds permanent maintenance nobody has the headcount to carry.

Legibility Is an Architectural Requirement

Because of who maintains it afterwards, we make choices that read as conservative. Fewer moving parts, even where a cleverer design exists. Every decision leaves a trace a non-engineer can read. Cost ceilings are hard limits rather than alerts. Anything consequential stops and asks a person. None of that is caution. It is what keeps a system alive once we are gone.

The redesign has to clear two bars at once: different enough from the old process that the return is real, close enough that the team still recognises their own work in it. We learned the second one expensively. An early build handled more of a workflow than the client's team was ready to supervise, and within weeks it was quietly bypassed. Nothing failed. People stopped trusting an output they could not check, so they checked it by hand anyway. The system was working perfectly the whole time it was being ignored.

The Handover Is the Deliverable

We are not finished when the system works. We are finished when it works without us. The client's own people build alongside us from the first week, because the team that watched a system get built is the only one that can change it later. That makes the last stretch deliberately boring. Runbooks. Failure modes in plain language. Their people running it while we watch and stay quiet.

The part we have not solved is people. The sponsor moves on. The generalist we trained takes another job. Documentation survives that. Judgement does not, and we are still learning how much of ours to write down.

The Work We Turn Down

We turn down work scoped as extra hands. A headcount gap has no outcome attached, so there is nothing to prove at the end and no reason to keep the thing running. One question settles it: who on your side is working on this with us? No answer means a staffing request wearing a project's clothes. The open-ended retainer goes the same way. Without an end date there is no forcing function, and a system that never has to stand on its own never learns how.

The Measure

None of this is exotic. It is the unglamorous version of forward deployed engineering, shaped by clients who never wanted to run an engineering function and are not about to start. The measure is one they can check without us. Six months after we leave, is it still running, and can they change it without calling us?