Core principles.
One lens sits above all of it — customer value: value first, value fast, value at scale. Frontier AI and serious engineering behind it, never in front of it.
Doing things that don’t scale — at scale
Most software companies build one product and sell the same thing to everyone — that’s what scales. The forward deployed model does the opposite: a senior engineer goes and sits inside a single customer and hand-builds exactly what they need, one account at a time. It’s slow and manual — famously, it “doesn’t scale.”
The usual startup advice is to do that kind of hands-on work only at the very start, then stop and automate it away. The forward deployed model never stops: it runs that high-touch motion on purpose, customer after customer, market after market — because being in the room is the only way to find the problem actually worth solving.
Unscalable work, run as a repeatable system — and it compounds. Every hand-built solution feeds a shared platform: a general product built backwards from what the work on the ground actually needed. So each non-scaling engagement makes the next one easier, cheaper, faster, and more impactful. The hands-on motion never disappears, but the platform beneath it grows — and that’s how doing things that don’t scale becomes doing them at scale.
Gravel road → paved superhighway
The FDE builds a “gravel road” to where the product needs to go — the simplest, roughest path that solves this one customer’s problem.
The product and engineering team’s job is to look at that gravel road and work out how it should generalise to the next five-to-ten customers, turning it into a “paved superhighway.”
The paved road usually looks different from the gravel road, because it has to serve many customers further down the road.
Building backwards (“back-propagation”)
Nobody hands you a spec — the customer doesn’t have one either. So the first move is always to find it: the use case that’s genuinely valuable, the top priority worth betting on. And that never goes away — however much platform you’ve built, however much it accelerates the work, there’s still no spec. You always have to identify the thing worth building.
Then you build backward. Make it work for that one specific case first; then ask what the general version is, and build it backward from the specific. It accumulates into one coherent platform — a growing library of accelerators, components, and adapters. Combine the right ones and they harden into reusable solutions for a vertical or a use case; in time, those can grow into products in their own right. It’s a continuous loop — solve the specific, generalise it, integrate it back, reconciling the friction each pass — building backward and inductively, always with an eye on the reusable version.
Land and expand
You start by solving one of the customer’s top problems — a real one, not the easy one. Solve it well and you earn the right to the next problem, often a more valuable one, and the one after that. The question stops being “how do we ship the same thing to every customer?” and becomes “how do we land, then expand?”
The first problem has to be one of the CEO’s top-five priorities. Anything smaller and leadership won’t have the energy for the hard part — and the hard part isn’t building the software; it’s the change and adoption needed to put something new into how the business actually runs.
The three layers.
Every build runs through three layers: a sandbox where value is proven in days, a platform where what works becomes reusable IP, and the customer’s own environment where it lands. The gravel road gets built in the first, paved in the second, and laid inside the third.
Layer 1 — the AI engineering sandbox
Fast-moving tools for discovery, prototyping and model comparison. This is where we move fast: land at the account, find a valuable workflow, and build the demo in days — custom harness, retrieval, tools, frontier models — proving the workflow can change.
The sandbox optimises for speed, learning, demo value and iteration. It’s the kit on the hiring page: frontier APIs, realtime voice, instant deploys, tracing — live from day one, no procurement queue.
One discipline holds the whole model together: the sandbox demo is not automatically the pilot architecture. It is the value proof.
Layer 2 — the agent platform
The Kinetic IT-owned custom harness where the IP lives: agent loop, tool registry, memory, retrieval, evals, tracing, compaction, heartbeat, human approval, role-based access, tool permissions, error recovery, deployment templates, reusable adapters, domain patterns and workflow archetypes.
Everything is built through platform interfaces, so the implementation underneath can vary. The demo runs on the sandbox adapter; the pilot runs on the customer-approved adapter. Same agent, same tool contract, different deployment.
This layer optimises for owned IP, repeatability, portability and product leverage — it’s what makes each deployment of the same outcome faster than the last.
Layer 3 — the customer landing zone
Where the pilot and the production system live: the customer’s approved environment. For a Microsoft-heavy customer that usually means Azure, Entra ID, approved model endpoints, Key Vault, private networking and approved observability — with Teams and Power Platform as surfaces and integration points, not necessarily the core. For sovereign and critical-infrastructure customers, onshore data residency and approved model endpoints aren’t constraints bolted on later — they’re the starting conditions.
This layer optimises for security approval, enterprise adoption, production supportability and customer trust. No tech religion: when the customer’s platform is the fastest path to value, that’s what we ship.
Two clocks.
Every engagement runs on two clocks at once — speed and trust, in parallel rather than in tension.
Clock 1 — the value clock
The FDE clock. It asks one question: can we show by Friday that this workflow can materially improve? This is where the custom harness, rapid demos, frontier-model testing, retrieval, tools and product judgement live.
Clock 2 — the promotion clock
The enterprise architecture clock. It asks: if this works, exactly how does it enter the customer’s environment? Which cloud is approved, which model endpoints, what data classifications apply, who approves permissions, what a read-only pilot needs versus one that takes actions.
It starts on day one, and it never blocks the demo. We collect the answers while we build — so the security conversation never starts from a blank sheet after the demo. Speed earns the meeting; the promotion path keeps the trust.
Team structure & roles.
Where we sit
AI Engineering & Platforms is a newly formed unit inside the Transformation Office.
FDEs report to the Head of AI Engineering & Platforms, who reports to the Chief Transformation Officer.
We start as one delta team
At the start, the whole team runs as a single delta team — a small, elite group of founding engineers playing the forward deployed role.
FDEs deploy alone or in pairs to accounts, and own solution design all the way to production.
Pods form as we specialise
Over the following months, small pods form — each a specialisation around an industry, a set of use cases, or a product. A pod per vertical.
How you grow
As deployments accumulate, the platform compounds: each one makes the next better, faster, and more impactful.
As FDEs accumulate hard-won field experience, platform fluency, and domain knowledge, they earn a place in the product, platform, and industry pods.
From there the path forks — pod lead, for those with an aptitude for people leadership; principal and distinguished engineer, for those who keep growing on the technical track.
The teams around us
The AI engineering team works in partnership with — and is backed by — the account, solutioning, strategy, and change teams.
Deployment strategists and account executives are the commercial and strategic counterweight: they own change management, “seeing around corners,” and navigating large, multi-division accounts.
Forward deployed is a verb
It’s less about the forward deployed engineer and more about the verb — forward deployed engineering. We’re committing to building the product this way.
Cadences.
The customer rhythm
The sync cadence runs per use case — an account might have several use cases in exploration at once. A new one opens with daily syncs through discovery, holding them until it reaches cruising speed; they then ease to weekly syncs, and tighten back to daily as it approaches production.
Each pilot also books two reviews up front, straight into calendars — a mid-point review and a final one, each with a fixed date and time so they don’t quietly slip. The final review brings in all the customer’s stakeholders, wrapped up in person.
Beyond the pilot, quarterly business reviews add structure — a few minutes on what’s been done, most of the time on what’s next. Useful later, not an early-stage priority.
And it all runs on presence — being on site is what “forward deployed” means. An FDE is flown in about a week at a time, a few times a quarter per account, more around a go-live, and on site the night before a launch. Presence is what speeds up the deployment, the relationship, and the next opportunity.
The team rhythm
Weekly, the platform compounds: a standing sync between the field and the platform team. Thursday, FDEs write up the week — notes, blockers, and feature requests — and submit them asynchronously; Friday, a live session works through the biggest issues, and the platform team decides what gets built into the platform.
Monthly, the team steps back to the numbers — is the model compounding? Platform share of each deployment, outcomes delivered per account, and the trajectory of each engagement.
Quarterly, the horizon lifts to strategy: which verticals are real enough to form a pod around, what’s worth hardening into a reusable solution or product, and where to land and expand next — plus an honest retro on the model itself.