Notebook / Engineering / 13.09.2026
Forward-deployed engineering: work inside the process.
The difference is not another tool. It comes from bringing engineering closer to the place where decisions are made, exceptions appear and work changes hands.
From an abstract brief to real work
An automation project often begins with a broad request: “we want to use AI”, “the ERP needs connecting” or “this should happen automatically”. None of these describes the process yet. Useful engineering starts by seeing what enters, who decides, which information goes missing and what happens when a case does not fit.
Palantir made the Forward Deployed Engineering method visible. Its documentation describes engineers working close to demanding operational environments and feeding what they learn back into the product. A smaller company can use the principle without adopting that platform: reduce the distance between the people building and the people operating.
Three moves, one responsibility
Kenea translates that proximity into three moves. We first enter the process and build a shared map. We then configure existing software or develop the missing layer. Finally, we test the route with representative cases, document limits and make the owner of each exception visible.
The result may use Microsoft 365, SharePoint, Power Automate, n8n, Odoo, a custom service or an AI model. The choice comes after reviewing permissions, data, APIs, operating cost and maintainability.
AI also needs an operating environment
Agentic systems show why the method matters. Palantir's AI FDE documentation separates intent, context, actions, observation and review, while limiting tools and data according to permissions. The general principles travel well: a useful agent needs a bounded objective, authorised tools, an action record and a way to validate change before production.
Autonomy still requires control. In a real process, acting also means being able to explain what happened, which information was used and which output needs human judgement.
What the client should receive
- A written scope with inputs, outputs and exclusions.
- A visible operating route, including exceptions.
- Tests with authorised examples and acceptance criteria.
- Enough documentation to understand permissions, dependencies and limits.
- A next milestone based on evidence rather than a demonstration.
This connects forward-deployed engineering with Service as Software: the service produces a system, and the system retains what the work has taught us.