The Forward-Deployed Playbook

A TechFabric Field Notes Deep Dive — Part 3 of 3

The Piece That Makes It Work

In Part 1 of this blog series, we laid out how AI infrastructure flipped the build vs. buy decision. Custom development that took six months now scopes at four weeks. The economics changed, and the 76% of enterprises still defaulting to vendor solutions are operating on outdated math.

In Part 2, we went further. The same economics are making detailed upfront planning viable again. When implementation takes weeks instead of months, investing in getting the architecture right on the first pass, it’s the obvious play. Senior engineers are designing production-grade data models and shipping them in the time it used to take to deliver an MVP.

But both of those shifts depend on an assumption that's easy to gloss over: the people doing the planning actually understand the problem they're solving. Not the version of the problem that made it into the requirements document. The real one — the one that lives in your operations, your data, and the heads of the people who've been working around system limitations for years.

This is where the model either works or falls apart. And it's why we deploy the way we do.

Why 80% of Enterprise AI Fails at the Integration Wall

We keep coming back to this number: 64% of organizations have moved fewer than 30% of their AI experiments into production. Execution is where initiatives stall.

We call it the "integration wall." Getting an AI demo working in a sandbox is maybe 20% of the job. The other 80% is navigating enterprise SSO, legacy ETL pipelines, data residency requirements, the politics of getting production credentials from your security team, and the dozens of undocumented business rules that nobody mentions because they've become invisible through habit.

We've watched traditional consulting teams hit this wall repeatedly. They're smart people working from the outside — reading your documentation, attending your discovery sessions, building against a requirements document that captures maybe 40% of the actual problem. The remaining 60% lives in the operational context that nobody writes down.

This is why we're seeing 15-person teams billing $300K per month spend six months and deliver a system that technically works but never gets fully adopted. They built what was specified, not what was actually needed.

What Forward-Deployed Actually Means

Palantir popularized this model, and their results speak for themselves — 137% revenue growth in U.S. commercial operations, driven by embedding engineers directly in client environments. But the concept is spreading fast. Salesforce is adopting it for Agentforce deployments, ServiceNow is investing in it, Anthropic is scaling its FDE team fivefold, and job postings for forward-deployed engineers are up 800% year-over-year.

The principle is straightforward: instead of engineers working from your documentation at arm's length, they embed in your operations and work from firsthand understanding.

What this looks like in practice at TechFabric:

A senior engineer joins your team not as staff augmentation filling a seat at a desk, but as someone operating inside your systems, your data, and your daily workflows. They attend your operations standup. They observe how your team handles exceptions. They surface constraints that never made it into documentation because your team stopped recognizing them as constraints years ago. They’re simply “how things work.”

Two weeks in, that engineer understands your operational reality better than the last consulting team understood it after three months of discovery sessions. Not because they're smarter — because they're closer. The gap between documentation and reality only closes through proximity.

Context Is the Multiplier

In Part 2, we described the shift toward investing in upfront specification rather than iterating through multiple refactors. That shift only works if the specifications are grounded in operational truth. A beautifully detailed spec written by someone who doesn't understand your business produces the same failure mode as 1990s Waterfall — an expensive system that misses the actual problem.

We see this play out on every engagement.

A carrier selection project we recently delivered:

A spec based on the requirements document would say: evaluate carriers by cost, transit time, and reliability score. Clean problem. Any team could build it.

An engineer embedded in operations for two weeks discovered the real system: three carriers with negotiated volume commitments where missing minimums triggers rate increases across the board next quarter; two lanes with unwritten preferences based on receiving dock relationships; reliability scores eight months out of date. The spec described 40% of the actual optimization problem.

That embedded engineer doesn't just build a better system. They write a better specification. And when that specification feeds into AI infrastructure that can execute it in weeks instead of months, you get the ideal system — the one that accounts for the real constraints — built in the time and budget that used to buy you a compromised MVP.

The Team Structure

We detailed the economics in our first article: a traditional 12-15 person consulting team bills $250-400K per month. The productive engineering output comes from maybe 3-4 people. The rest is coordination infrastructure, management overhead, and organizational scaffolding the vendor needs to run their own engagement.

Our model strips that scaffolding:

Three senior engineers. Each one averages fifteen years of enterprise experience. Each one capable of architecting the entire system alone. Each one embedded deeply enough in your operations to understand the problem at the level that matters.

Purpose-built AI infrastructure. Not "we use Copilot." Infrastructure trained on how our engineers actually work, handling the implementation throughput that used to require junior developers. Each engineer directs that infrastructure to produce what used to require 4-5 additional people.

Zero coordination tax. The architect and the builder are the same person. No project managers translating requirements between engineers and clients. No sub-teams that need synchronization meetings. No handoffs where context gets lost. The person who discovered the constraint in your operations at 7 AM is the same person encoding it into the system at 9 AM.

The output: production-grade systems shipped in weeks, at a fraction of the cost of a traditional engagement, with fewer defects because every decision is made by someone who holds the full context.

How an Engagement Actually Works

Weeks 1-2: Embedded Discovery

Our engineers join your environment. They get access to your systems, your data, and most importantly, your people. They sit with your operations team, your data engineers, and your business analysts. They map the real constraints, the actual workflows, and the business logic that lives in people’s heads rather than in documentation.

This isn’t the kind of “discovery” that produces a PowerPoint deck. It produces a complete system specification grounded in operational reality, not documentation, as described in Part 2.

Weeks 3-6: Build

With a specification grounded in real context, our engineers build. Senior judgment directs AI infrastructure at implementation speed. The data model is designed for the long term, not a “good enough for now” MVP schema that requires seven migrations over eighteen months. The integration architecture reflects your actual system constraints, not the idealized version in the API documentation.

Every line of code is reviewed by someone who understands the full system and the full business context. Every architectural decision is made by someone who's seen what happens when you cut that corner at scale.

Weeks 6-8: Production and Handoff

The system goes live in your environment, running against your real data, handling your actual operational load. You get clean documentation and full knowledge transfer, and the engineers who built it are available for support because they're the same people from day one — no handoff to a maintenance team that's never seen the codebase.

The Trust Architecture

Forward-deployed doesn't mean unsupervised. A common concern: "You're embedding engineers in our operations. How do we maintain control?"

These engineers report to you. They work on your priorities. You have weekly visibility into what's shipping, why decisions were made, and what's coming next. They're embedded enough to understand context but accountable enough to deliver outcomes on your terms.

We’ve found that trust is built through demonstrated competence, not contractual terms. When the engineer embedded in your operations identifies a constraint three previous consulting teams missed and builds a system that accounts for it, the question shifts from “Can I trust them?” to “Why weren’t we doing this before?”

When This Works — And When It Doesn't

We've been direct about this throughout the series: the forward-deployed model isn't right for everything.

It works when:

The problem is complex, context-dependent, and requires deep judgment — intelligent automation that needs to encode real business logic, legacy modernization with undocumented constraints, or integration projects where the real requirements aren't written down anywhere. These are the situations where proximity to operations is the difference between shipping something that works and shipping something that technically passes testing.

It doesn't work when:

The problem is well-defined with clear requirements and no operational ambiguity — a standard CRUD application, a straightforward data migration with complete documentation, or a project where the spec is genuinely the spec. For those, we've found that a well-managed traditional team works fine.

The honest signal: if your last team delivered exactly what was specified and your operations team started routing around it within a month, you have a context problem that more engineers won't solve. You need fewer, better engineers who are closer to the work.

The Enterprise AI Shift: A Three-Part Series

The three shifts we've described in this series are interconnected:

The build vs. buy calculus flipped. AI infrastructure made custom development faster and cheaper than vendor workarounds. The 80/20 problem — vendors solving 80% while you build workarounds for the critical 20% — now resolves in favor of building.

The planning-execution tradeoff inverted. When implementation takes weeks instead of months, investing in getting the architecture right upfront isn't a gamble. Senior engineers are designing production-grade systems and shipping them in the time that used to produce compromised MVPs.

The delivery model that makes both possible is forward-deployed. All the speed and cost advantages of AI infrastructure are wasted if the team building the system doesn't understand the real problem. Embedded context — engineers who operate inside your operations, not outside them — is what turns faster execution into better outcomes.

The consulting industry is built on headcount economics: more people equals more revenue. AI infrastructure is dismantling that equation. A model that sends fifteen people to build what three could build better is now selling organizational scaffolding.

We’re watching the future take shape: small teams of senior engineers embedded where the work happens, equipped with AI infrastructure that operates at implementation speeds that redefine what’s possible. Small, senior, and close to the problem is now faster, cheaper, and more accurate than the alternative.

Your next major initiative doesn't need a bigger team. It needs the right team, in the right place, with the right infrastructure.‍

Schedule a conversation with an engineer who works this way.

‍