OKFDE FIELD NOTES · #001｜The Model Isn’t the Bottleneck. The Enterprise Is.
Why frontier AI still struggles in production—and how Forward Deployed Engineering closes the gap between model capability and business reality.
OKFDE Research · Published October 2026 · ~11 min read
KEY TAKEAWAY
Enterprise models rarely drop out of production because they can’t reason. They stall because the company around them is a mess of forgotten VPNs, brittle internal APIs, unwritten business rules, and terrified middle managers trying to duck liability. Forward Deployed Engineering (FDE) exists because fixing that boundary is an engineering job, not a slide deck.
/COLD OPEN
Six people are still trapped inside a glass-walled conference room.
The CEO has just concluded a sweeping presentation on the company's "AI transformation." The pitch deck is immaculate: gradient accents, clean typography, and a final slide declaring in bold sans-serif: AI FIRST.
Then enterprise reality enters the room:
Operations: "Our procurement workflow is nowhere near as standardized as that diagram."
Enterprise Architecture: "The legacy ERP has no modern REST API. There is an undocumented SOAP endpoint that times out under load."
Legal & Compliance: "Customer PII cannot leave our private VPC under current contractual covenants."
Frontline Staff: "That flowchart bears zero resemblance to how we actually execute the work."
AI Engineering Lead: "Be that as it may, our model achieved 94.7% accuracy on the evaluation benchmark."
The room goes quiet.
If you have deployed enterprise AI, you recognize this impasse immediately. Everyone at the table is completely right at their respective layer of the system. The model is capable. The compliance risk is existential. The legacy infrastructure is genuinely brittle. The frontline team is describing operational truth.
Everyone around the table is technically correct. And because everyone is correct, nobody can ship.
The weights were never the hard part. The hard part is the company.
01 / THE LAST MILE
AI Learned to Reason. Then It Met the Company.
For much of the SaaS era, the technology sector operated on the cleanest economic engine in history: Build once, sell many times.
Product teams shipped software, sales reps closed contracts, implementation teams configured instances, and end-users conformed their behavior to the software's interface. It was a predictable, highly scalable model.
The moment AI entered mission-critical enterprise workflows, that neat separation broke down.
Enterprise AI cannot simply demand that an organization conform to its interface. The highest-value enterprise workflows sit inside operational territory that is deeply idiosyncratic, cross-functional, heavily permissioned, exception-dense, and only partially documented.
Consider an autonomous procurement workflow for a mid-market industrial manufacturer. On an executive slide, the pipeline looks embarrassingly straightforward:
Requisition ➔ RFQ ➔ Quote Comparison ➔ Approval ➔ Purchase OrderSpend forty-eight hours on the operational floor, however, and the real pipeline looks fundamentally different:
Requisitions originate across three disconnected legacy systems, accompanied by an untracked stream of unstructured email.
Long-standing suppliers operate on historical pricing agreements negotiated years ago over coffee, recorded nowhere in the database.
New supplier risk criteria are scattered across compliance PDFs and personal inboxes.
Orders exceeding $50k mandate executive sign-off, but the approver is traveling without an assigned delegate.
The legal entity name inside the ERP fails to match the entity specified on the master service agreement.
"That order is an exception," the business lead explains.
"How frequently do exceptions happen?" the forward deployed engineer asks.
"Roughly 30% of our daily volume."
The workflow includes its exceptions. Shipping it requires engineering through the people, corrupted data, legacy infrastructure, access boundaries, and unwritten rules that surround the model. A benchmark score alone cannot show that the business process functions.
Real work does not exist in an abstract vector space. It lives at the friction-heavy intersection of organizations, and organizations segment themselves by functional departments; business problems never do.
02 / FORWARD DEPLOYED
Moving Engineering Responsibility to the Problem
Forward Deployed Engineering is not a speculative new title. Palantir pioneered it over a decade ago as a product-development paradigm in which engineers work embedded directly inside customer operational realities, feeding battlefield discoveries back into the platform.
What is new in the generative AI era is how central this operating model is becoming across the industry:
OpenAI established a dedicated Forward Deployed Engineering organization whose scope spans discovery, technical scoping, systems design, production rollout, customer adoption, and core product feedback loops.
AWS formalized a Partner-Led FDE initiative in 2026 focused on production agentic systems, governance guardrails, and reusable delivery harnesses.
Salesforce organizes FDE roles around designing and deploying enterprise-grade Agentforce workflows directly inside customer IT environments.
The common principle matters far more than the corporate label: engineering responsibility moves directly to the point where the business problem actually exists.
Dimension | Traditional Enterprise Delivery | Forward Deployed Engineering |
Workflow Trajectory | Serial handoffs across 5+ specialized departments | Single-owner feedback loop directly at the problem boundary |
Context Decay | High. Business context is repeatedly filtered, compressed, and lost | Near Zero. Builders preserve raw operational nuance |
Definition of Done | Feature shipped, Jira ticket closed, milestone signed off | Measurable business adoption, reliability, and P&L impact |
Product Feedback | Delayed, filtered through customer advisory boards | Field failure modes directly inform core primitives and platform design |
In a conventional delivery pipeline, every arrow represents a handoff. Every handoff strips away context.
The client says: "Our order approval turnaround is crippling our supply chain." Four handoffs later, core engineering receives a Jira ticket:
PROD-8120: Add REST endpoint for order approval status.The endpoint ships. The ticket closes. The sprint retro celebrates another on-time release. Six months later, leadership asks the only question that truly mattered: Did our order approval cycle actually accelerate?
The ticket does not answer that question. Ownership has to extend to the operational outcome.
03 / DISCOVERY
Discovery Isn't Pre-Work. It’s the Job.
An FDE engagement rarely starts in an IDE. If you open VS Code on day one, you’ve already lost.
You start by asking questions that make business leads slightly uncomfortable:
Who actually takes the blame when this workflow silently corrupts data? Where does the paper trail go when an order stalls?
What are the unlogged upstream inputs and downstream manual workarounds?
Which system holds source-of-truth status, and who controls write access?
What are the undocumented exception paths—the ones that never appear in standard operating procedures (SOPs)?
If this pipeline accelerates by 50%, what is that economically worth to the balance sheet?
This is why we treat Discovery as an analytical engineering discipline, not administrative overhead.
In most enterprises, AI discovery currently resembles a ritual: hold six Zoom calls, take scattered meeting notes, email an executive summary that nobody reads, and have engineers ask the exact same questions three weeks later during staging.
At OKFDE, structured discovery means building a verifiable model of organizational reality: capturing raw operational evidence, isolating tacit business heuristics, validating edge conditions directly with frontline operators, and establishing a build-ready baseline before committing architecture.
Most enterprise AI initiatives fail weeks before the first line of code is written. The goal of discovery is not to produce better notes; it is to eliminate structural ambiguity before ambiguity becomes code.
04 / PRODUCTION
Production Changes the Definition of "Working"
The agentic era introduced a sharp architectural asymmetry: the cost of prototyping an impressive demo collapsed, but the cost of achieving production reliability remained largely unchanged.
This contrast reframes the technical objections voiced in that midnight conference room:
The lead architect’s timing-out SOAP endpoint is not a colorful edge case; it is the baseline reality of enterprise infrastructure.
Legal’s objection to data egress is not bureaucratic friction; it is a rigid architectural boundary that system design must accommodate.
In production, the base model’s parameter count doesn't matter nearly as much as five basic plumbing questions: Identity, authorization, idempotency, audit trails, and who holds the emergency kill switch.
If a model hallucinates a purchase order, nobody sues the vector database. They look for the engineer who wired the write permission to an unvetted service account.
05 / PRODUCTIZATION
Custom Code Is Gravity: Escaping the Services Trap
Forward deployment solves the last-mile delivery problem, but immediately risks creating an organizational failure mode.
When engineers sit close to business problems, they can solve almost anything with brute force. Missing an API? Write an ad-hoc screen scraper. Idiosyncratic business exception? Hardcode a conditional branch. Fragile spreadsheet? Build a bespoke parser script.
The deployment succeeds. The client is relieved. Sales books the revenue.
One year later, the software company wakes up with 40 enterprise customers, 75 divergent code repositories, hundreds of brittle configuration overrides, and an unmaintainable monolith:
# DO_NOT_TOUCH_FINAL_v27
# Last updated during an emergency midnight deployment
def procurement_override(order):
if finance_override_sheet.column_g_is_blank:
return "bypass"
return process_normally(order)If that workaround is never productized, column G stays manual forever.
This is the Services Trap: every enterprise deployment creates localized value, but the knowledge remains trapped inside custom professional services debt.
The defining discipline of an FDE organization is Reverse Productization—systematically asking at the conclusion of every engagement: What survives this deployment?
Did the deployment leave behind brittle client-specific patches, or did the team extract reusable integration patterns, deterministic circuit breakers, and production evaluation suites?
A mediocre services organization leaves its learning behind in the client’s codebase. An elite FDE organization compounds that learning back into the core platform.
06 / CONTEXT
In the Era of Cheap Intelligence, Context Compounds
Inference costs are falling exponentially. Token economics are trending toward zero. Code generation is compressing the distance between an architectural idea and a functional prototype.
Yet there is an indispensable asset that a foundation model cannot synthesize out of thin air: how your organization actually runs.
Why finance produces an undocumented auxiliary workbook on the 25th of every month.
Why a critical procurement approval must clear a specific desk before anyone updates the ERP.
Why the formal standard operating procedure lists three sequential steps, while the actual production workflow requires seven.
Why executive leadership identifies Metric A as their primary corporate objective, while frontline teams spend four hours every afternoon troubleshooting Metric B.
Who retains the authority to intervene when automation encounters an unhandled exception.
This institutional knowledge has a precise name: Enterprise Context.
Context is not an unstructured repository of documents dumped into a vector database. It is a living, high-resolution graph of workflows, people, systems, data, constraints, permissions, exceptions, and the evidentiary paper trail supporting them.
This is why Forward Deployed Engineering is ultimately an operating model rather than a title:
DISCOVER ➔ SCOPE ➔ BUILD ➔ INTEGRATE ➔ DEPLOY ➔ OPERATE ➔ LEARN ➔ PRODUCTIZE ↺The decisive element in this loop is the feedback arrow. Operational failure modes, schema mappings, evaluation criteria, and deployment heuristics discovered on the enterprise floor must systematically flow back into the core platform.
Otherwise, an AI company is not compounding intelligence; it is merely accumulating disconnected projects.
07 / RETURN TO REALITY
For the past several years, the tech industry’s defining question was: How smart can we make the model?
Over the next decade, the decisive engineering question will be: How does that intelligence safely cross the chasm into production?
Into logistics hubs, manufacturing assembly plants, financial institutions, heavily regulated back-offices, and twenty-year-old internal ERPs.
Tomorrow morning at 9:07 A.M., someone on the logistics team will sit down, open a 14-tab spreadsheet, run a query against a legacy endpoint that hasn't been patched since 2018, and hit the exact same unlogged edge case.
No benchmark scores will save that run. No keynote will help.
The only question that counts is whether your code survives that morning without page duty going off.
That is where Forward Deployed Engineering starts.
NEXT / FIELD NOTES · #002
What Does an FDE Actually Do?
A practical breakdown of Forward Deployed Engineering versus Solutions Engineering, Implementation, Management Consulting, Customer Engineering, and AI Engineering—and where the functional boundaries blur.
SOURCES & EVIDENCE
This document separates industry evidence from OKFDE synthesis. The company references below illustrate how forward-deployed operating models are expanding across enterprise AI; the overarching analytical frameworks reflect OKFDE methodology:
[1] Palantir Technologies — Architecture Center: Forward Deployed Engineering. Palantir defines FDE as an integrated product-development paradigm that embeds engineers directly at operational problem sites to feed frontline discoveries back into the platform.
[2] OpenAI — Forward Deployed Engineering Roles & Deployment Operations. OpenAI’s dedicated FDE teams explicitly span discovery, technical scoping, systems design, production rollout, customer adoption, and core product feedback loops.
[3] AWS — Partner-Led Forward Deployed Engineering (2026). AWS formalized its Partner-Led FDE initiative focused on enterprise-grade agentic production deployments, governance guardrails, and reusable delivery harnesses.
[4] Salesforce — Forward Deployed Engineer, Agentforce Operations. Salesforce deploys FDE pods to architect, integrate, and operationalize enterprise-grade agentic workflows directly inside customer IT environments.
ABOUT OKFDE
OKFDE is a research, engineering, and talent platform focused on Forward Deployed Engineering for enterprise AI. We turn lessons from real-world deployments into practical methods for delivering, operating, and improving AI systems.
OKFDE
Train. Build. Deploy.
For enterprise deployment inquiries, workshops, or field research: