Process — Forward Deployed Engineering

The last mile
is the product

Most AI projects do not fail on the model. They fail on the last mile. The demo works — but between demo and real work sit SAP customizing, Excel, EDI, proprietary interfaces, permissions, bad master data and systems that have grown for 20 years. For us, this last mile is no necessary evil. It is the product.

Talk to us

Engineers in the field Measured in work done 0 → productive · 14 days

01 — The role

This is where
forward deployed engineering begins

Forward deployed engineers work deep inside the customer's operations and carry what they learn in the field back into the product. What was long unusual is becoming the delivery model for enterprise AI — because the models are strong enough and the last mile remains the bottleneck.

The role is coming into focus. The FDE is neither a classic consultant nor a solutions engineer nor an outsourced software developer. The FDE turns technology into a productive system.

02 — The measure

We push outcomes,
not agents

An agent is not an outcome. An agent that explains how an order should be created has not done any work — and ten agents talking to each other are still no business value. What we care about is what ends up in the system: Was the order created correctly? Was the exception resolved? Was the case closed? How many cases ran through without human intervention?

That is why we do not primarily measure chats, agent runs or tokens. We measure work done.

No-touch rate Cycle time Error rate Completed transactions

The agent is a tool. Not the product promise.

03 — The terrain

The complexity sits
between the systems

For complex industries in particular — manufacturing, machine building and the like — this model is indispensable for us. A business process there rarely belongs to a single system: sales, ERP, purchasing, planning, production, logistics and finance interlock. SAP meets MES, MES meets proprietary machine software — plus DMS, EDI, Outlook, Excel, in-house builds and databases that are decades old. And almost every company is different.

An FDE cannot say: “There is no API for that.” The FDE has to ask: How is this work actually done today? Whether the answer is REST, RFC, SQL, EDI, SFTP or CSV is secondary.

Heterogeneity is no edge case. Heterogeneity is part of the product.

04 — The ecosystem

We do not fight
third-party vendors

We do not want to replace every existing piece of software with our own — the opposite is more interesting: we want to make existing systems and specialist vendors more holistic. An SAP consultant knows SAP and should keep working with SAP. But why should their view of a process end at the SAP system boundary? If their task needs information from a DMS, CRM, MES or an email, that context should be just as available.

That is what our Enterprise Context Protocol is for: it integrates systems and third-party vendors into our platform. An isolated SAP agent becomes a participant in a company-wide process — a specialized tool does not suddenly have to do everything, it gets the context and capabilities that sit outside its own system boundary. We do not replace the existing ecosystem. We make it interoperable.

+ in-house systems
via MCP server

05 — The responsibility

Read broadly.
Write narrowly

With this reach comes responsibility. A system may read context from ten or twenty sources — write permissions still have to stay precise. Autonomy does not mean an agent may do everything. Autonomy means defining clearly which work a system can reliably be trusted with.

Create

An order may be created — within defined limits, idempotent, validated.

Change

A price maybe not. Write permissions are granted per action, never wholesale.

Escalate

A defined deviation always goes to a human — automatically, with full context.

Prove

Audit logs, permissions, validations, evals and observability belong to the product like models and prompts.

06 — The loop

Every integration we have ever built
is working today

Forward deployed engineering must not turn into bespoke project business. Behind every engagement sits a system built from all the ones before: every integration, every business rule, every resolved exception and every understood system has made the platform better — and makes the next engagement faster.

F/01

Adapter

A customer-specific problem becomes a reusable adapter — the next connection ships faster.

F/02

Capability

A resolved exception becomes a capability — available to every agent on the platform.

F/03

Platform knowledge

A deployment becomes platform knowledge — every field learning flows back into the product.

Field work compiled into product IP: with every integration we get better and faster. That is why we will be unbeatable in speed and impact.

07 — The engagement

We start at the outcome
and work backwards

We do not start with: which agent can we build? We start with: what result should end up in the system? Then we work backwards — through processes, integrations, third-party vendors, legacy and edge cases. Until AI becomes real work. On site, in your systems, with a baseline and sign-off:

Day 1–3

Read-only access, systems connected, mapping with your team.

Day 4–6

Policies set: approvals, limits, role profiles, audit.

Day 7–10

First agent in shadow mode against your history, fine-tuning.

Day 11–14

Sign-off and go-live of the first process. Baseline set, measurement running.

After that

Process by process, in your order. Every learning makes the platform better.

The last mile is the product

This is where forward deployed engineering begins

We push outcomes, not agents

The complexity sits between the systems

We do not fight third-party vendors

Read broadly. Write narrowly

Every integration we have ever built is working today