When we started Whitetower back in 2014, clients came to us for websites. A few years later the brief changed and everyone wanted “digital transformation.” Get the business online, put in a proper CRM, wire up some dashboards, get off the spreadsheets. It was good work and it was necessary work. But looking back, most of it was really one thing – getting digital. Getting the house in order.
That was stage one. And a lot of businesses are still sitting in it.
The label has since moved on. The work that used to get sold as digital transformation is increasingly being called Forward Deployment Engineering, and the rename actually means something. The model Palantir built over a decade ago – put an engineer inside the customer’s environment, give them full ownership of the outcome, let them build in the real stack and keep iterating after launch – has gone mainstream. In the last 18 months OpenAI, Anthropic, Databricks and a long tail of AI companies have all stood up forward-deployed teams (OpenAI even spun theirs into a named “deployment” group). Job postings for the role grew somewhere north of 700% year on year. It’s no longer a niche title.
The reason it exists is simple and a little uncomfortable. MIT’s 2025 research found that roughly 95% of enterprise AI pilots produced no measurable return. The models aren’t the problem – everyone has access to the same models now. The problem is the last mile: getting that capability to actually work inside a real business, with real data, real processes and real constraints. A strategy deck can’t cross that gap. An engineer sitting in your stack can. That’s the whole shift – from consultants who tell you what to do, to engineers who embed and build it with you.
Which is great, except for one thing most people skip over.
You can’t forward-deploy onto nothing.
When an engineer embeds to build agentic workflows or automation into your business, they need something to build on. And for most businesses, stage one – the digital transformation foundation – was never actually finished. So before anyone starts deploying, this is the groundwork that has to be real.
Define your SOPs
You can’t put an agent on top of a process that only lives in someone’s head. Half the “automation” projects that fail, fail here – the business never wrote down how the work actually gets done (eg. how a refund really gets approved, what makes a lead qualified, who signs off on what and when). If a human can’t follow the SOP, an AI definitely can’t. Writing these down isn’t admin. It’s the spec sheet for everything you automate later.
Build out the platform
Then there’s the data layer. This is the unglamorous work we’ve done for years – consolidating fragmented systems (CRMs, legacy apps, custom platforms) into a single source of truth, with clean transformation layers underneath so the numbers are actually trustworthy. An agent is only as good as the data it can reach. If your data is scattered across six tools that don’t agree with each other, no amount of clever prompting saves you. The platform is what a forward-deployed build plugs into.
Sort out security, governance and sovereignty
This is the part that gets waved off until it’s a problem, and it’s the part the FDE world takes seriously – enterprise teams routinely run models inside their own infrastructure rather than piping everything out to a public API. Two questions matter most here.
Data sovereignty: where does your data physically live, who is allowed to touch it, and are you comfortable with where it goes the moment an AI tool gets pointed at it? For some businesses that means keeping inference close to home (eg. private cloud or on-prem) instead of sending customer data to whoever’s API is cheapest this week.
Reporting vs raw data: decide what an agent or an LLM actually gets to see. There’s a real difference between exposing a clean reporting layer (aggregated, governed, safe to query) and handing a model your raw tables. Most of the time you want the former. Getting this boundary right early is what lets you say yes to AI later without opening a hole in the business.
Start your Obsidian second brain
Foundations aren’t only enterprise data warehouses – some of it is just you, capturing what’s in your head before it’s useful to anyone else. This is where a second brain comes in. Pick something like Obsidian and start putting your SOPs, decisions, process notes and reference material into it. It’s plain markdown, it’s linked, and it lives on your machine – which, conveniently, is data sovereignty at a personal level. You own it. And it becomes the thing an agent can one day read and act on. The teams who’ll move fastest when they forward-deploy are the ones who already wrote everything down.
None of this is the exciting part. The exciting part is the AI sitting on top. But the businesses that get real returns out of that layer won’t be the ones with the best strategy deck – they’ll be the ones whose foundation was ready when the engineer showed up. Digital transformation didn’t go away. It just stopped being the finish line and became the price of entry.
So if you want to be ready for what’s coming – define the SOPs, build the platform, lock down the governance, and start the second brain now. Do the boring groundwork while it’s still cheap. That’s what makes you deployable.
