Domain experts start closer to the workflow, constraints, exceptions, and outcomes that enterprise AI must serve. Learn when that advantage can become forward-deployed capability, what engineering depth is still required, and how to build credible evidence without pretending domain knowledge replaces production engineering.
The Best FDE May Already Work Inside the Business
Domain experts start closer to the workflow, constraints, exceptions, and outcomes that enterprise AI must serve. Learn when that advantage can become forward-deployed capability, what engineering depth is still required, and how to build credible evidence without pretending domain knowledge replaces production engineering.
The Best FDE May Already Work Inside the Business
When an enterprise wants to put AI into a real workflow, it often starts by looking outside.
It hires an AI vendor, a consultancy, or a technically strong engineer and asks that person to learn the business quickly. The assumption is understandable: the technology looks difficult, so begin with the person who already understands the technology.
But the hardest part of forward-deployed work is rarely technology in isolation.
The system has to fit a living operation:
- which problem is worth solving;
- who performs the work today;
- which data can be trusted;
- which exceptions matter;
- what must never be automated;
- who can approve an action;
- how failure is detected and reversed;
- and what outcome would justify changing the workflow.
The people closest to those questions may already work inside the business.
This leads to a useful but easily exaggerated idea:
The best FDE for a domain may be a domain expert who learns enough engineering to own the solution.
That is not a law. Domain expertise does not turn someone into a production engineer, and modern AI tools do not erase software, security, data, or operational responsibility.
It is a career and team-design hypothesis worth testing.
Why outside-in deployment is difficult
A Forward Deployed Engineer is expected to operate close to the customer, translate business outcomes into technical scope, build or coordinate working systems, take them into production, drive adoption, and feed reusable field patterns back into the product.
Public role descriptions make the breadth clear. OpenAI's FDE roles combine workflow discovery, technical scoping, system design, full-stack delivery, production rollout, customer coordination, and product feedback. Palantir describes FDSEs as engineers who work directly with users, configure and extend platforms, implement solutions, and iterate against immediate operational feedback.
An external engineer can learn a domain. Strong FDEs do it repeatedly.
The problem is that domain knowledge is not a static document that can be downloaded during onboarding.
It lives in:
- informal workarounds that are absent from process diagrams;
- exceptions handled by experienced operators;
- incentives that shape what users report;
- policy language whose operational meaning differs from its literal wording;
- data fields everyone uses but no one trusts;
- seasonal or market changes;
- and judgment formed through years of seeing what fails.
An outsider must discover these facts while also delivering.
That creates a dynamic difficulty: the target keeps moving while the learner is trying to catch it.
The domain expert starts with a different asset
A domain expert does not merely "know the requirements."
The expert may already know:
- which outcome matters and which metric is decorative;
- where the current workflow really breaks;
- which users have authority and which only appear to;
- which edge cases can create financial, legal, clinical, or reputational harm;
- which sources are authoritative;
- how people respond when a system becomes inconvenient;
- and what a useful intervention would look like at the moment of work.
This is more than subject-matter knowledge. It is problem ownership.
That ownership changes the delivery loop.
external delivery
business user → requirements → translator → engineer → system → user feedback
domain-led delivery
domain owner → explicit workflow and rules → engineered system → direct feedback
The second loop can reduce translation loss. The person who feels the problem can test the solution, recognize a false assumption, and correct it without waiting for several layers of handoff.
But shorter communication does not guarantee a better system. If the domain expert lacks engineering discipline, the result may be a fragile personal automation that no team can safely operate.
The key asymmetry: dynamic domain knowledge and more stable engineering principles
The original argument behind "the domain expert may be the best FDE" rests on an asymmetry.
A software engineer entering an unfamiliar industry must acquire two things:
- domain understanding;
- the specific engineering patterns needed for the solution.
A domain expert entering technical delivery already owns the first and must build the second.
The two learning problems are not equal.
Domain knowledge is often highly contextual and continuously changing. Engineering tools also change, but many underlying principles are more stable:
- separation of concerns;
- interfaces and contracts;
- data models and provenance;
- identity and least privilege;
- deterministic control around probabilistic models;
- testing and evaluation;
- observability and rollback;
- failure isolation;
- and clear ownership.
Learning a framework is not enough, but architectural judgment can compound across projects.
This is why a domain-led path can be attractive: the learner is not trying to reproduce an entire computer science degree. The learner is building enough durable engineering judgment to convert known workflows into governed systems.
Where the thesis breaks
The phrase "business is primary, technology is secondary" can be useful as a design principle: architecture should serve the workflow rather than chase novelty.
It becomes dangerous when interpreted as "technology is easy."
Domain expertise does not automatically provide:
- production-grade software design;
- data engineering and migration discipline;
- authentication and authorization;
- privacy, security, and threat modeling;
- reliable integrations and distributed-system behavior;
- evaluation of probabilistic outputs;
- capacity, latency, and cost management;
- release engineering, observability, incident response, or rollback;
- or the ability to maintain a system after its original builder leaves.
Some workflows are also too consequential for one hybrid operator to own alone. A clinical support system, financial approval engine, critical infrastructure workflow, or regulated decision system needs explicit separation of duties and specialist review.
The strongest conclusion is therefore conditional:
Domain experts have a powerful FDE starting advantage when they add real engineering capability and work with specialists at the boundaries of their competence.
The goal is not to replace engineering teams. It is to place better judgment at the point where business intent becomes technical action.
Five responsibilities a domain-led FDE must still own
The work can be summarized in five responsibilities.
1. Discover the real need
Do not begin with "Where can we add an agent?"
Map the current workflow:
- trigger;
- actors;
- inputs;
- decisions;
- systems;
- exceptions;
- handoffs;
- delays;
- and outcome.
The domain expert's advantage appears only when tacit knowledge becomes explicit enough for others to inspect.
2. Build a bounded solution
Turn the problem into a system with a clear boundary.
Specify:
- what the solution will and will not do;
- what data it reads;
- what actions it may take;
- where human approval is required;
- what happens when confidence is low;
- and which result counts as acceptable.
3. Land it in the real environment
A useful prototype is not yet an operational system.
The solution may need identity, permissions, APIs, databases, audit logs, deployment environments, monitoring, support, and change approval. The FDE must either implement these pieces or coordinate them with accountable specialists.
4. Enable other people to operate it
If the system only works when its creator is present, it is not finished.
Users need training. Operators need a runbook. Owners need escalation rules. Engineers need architecture and interface documentation. The organization needs to know who accepts risk.
5. Learn and iterate
The first release is a hypothesis.
Observe real use, classify failures, compare outcomes with the baseline, adjust rules or architecture, and decide whether to expand, stop, or redesign. This is where domain knowledge produces ongoing value: the expert can recognize whether the system is improving the work or merely producing activity.
Two capabilities are central—but not sufficient
The visual notes correctly emphasize two durable abilities.
Architecture thinking
Architecture thinking means organizing a system so that it can change without becoming unsafe or incomprehensible.
It includes:
- dividing responsibilities among modules;
- defining data and API contracts;
- deciding where state lives;
- separating model judgment from deterministic rules;
- identifying trust boundaries;
- choosing what must be logged;
- and designing for failure, replacement, and growth.
This ability develops through real projects, review, debugging, and maintenance—not through memorizing diagrams.
Solution selection
Solution selection asks what should be built and which approach fits the constraints.
It includes decisions such as:
- workflow redesign before automation;
- rules versus machine learning;
- retrieval versus fine-tuning;
- one model call versus an agent loop;
- build versus buy;
- synchronous versus asynchronous processing;
- full automation versus decision support;
- and generic platform versus narrow domain application.
Selection is where domain experience and engineering judgment meet. The expert knows which errors matter; the engineer knows which design changes the error profile.
These two abilities still depend on implementation literacy. A domain-led FDE must be able to inspect code, data, tests, logs, permissions, and deployment behavior deeply enough to own the result.
A practical capability stack
Do not try to "learn all of AI." Build a stack around one workflow.
Layer 1: workflow and outcome
- describe the user and current process;
- establish a baseline;
- identify the decision or action being improved;
- define an owner and a measurable outcome.
Layer 2: software and data foundation
- one primary language such as Python or TypeScript;
- APIs, SQL, Git, testing, and debugging;
- data models, validation, provenance, and error handling.
Layer 3: AI application patterns
- structured model outputs;
- retrieval and citations;
- tool use and workflow orchestration;
- evaluation sets and failure analysis;
- guardrails and human review.
Layer 4: enterprise controls
- identity and access;
- secrets and sensitive data;
- auditability;
- deployment environments;
- monitoring, rollback, and incident ownership.
Layer 5: delivery and adoption
- solution scoping;
- stakeholder alignment;
- documentation and training;
- operational handover;
- outcome review and reusable patterns.
AI coding assistants can accelerate implementation across these layers. They cannot decide which outcome is legitimate, which risk is acceptable, who has authority, or whether the generated system is safe to operate.
Choose the right collaboration model
Not every domain expert should become a solo builder.
| Situation | Better model |
|---|---|
| Low-risk internal workflow, bounded data, reversible actions | Domain expert builds with engineering review |
| Moderate integration or sensitive data | Domain-led pair: domain owner plus experienced engineer |
| High-risk decisions or regulated workflow | Multidisciplinary team with security, compliance, data, and human approval |
| Platform used across many teams | Dedicated engineering ownership with domain experts embedded in product decisions |
| Early exploration with unclear value | Domain expert leads discovery before substantial engineering investment |
The best structure preserves the domain expert's direct judgment without pretending one person should own every specialist responsibility.
Build evidence with one domain-native project
A credible domain-led FDE project begins with a workflow you genuinely understand.
Examples might include:
- a lawyer organizing evidence and drafting a review queue;
- a clinician retrieving approved guidance with explicit escalation;
- a supply-chain planner analyzing shortages before a human releases an order;
- a finance operator reconciling exceptions with an audit trail;
- a support lead triaging cases while preserving agent override;
- or a research team converting protocol constraints into a governed workflow.
Do not claim production impact before you have production evidence.
Use the following project contract.
Problem
- Who performs the workflow?
- What event starts it?
- Where does time, quality, or control break down?
- What baseline evidence exists?
Boundary
- What is included?
- What remains manual?
- Which data and systems are available?
- Which risks stop the project?
Decision
- What options were considered?
- Why is AI appropriate?
- Why was this architecture selected?
- Who approves the approach?
Validation
- What representative cases form the evaluation set?
- What does success mean?
- Which failures are unacceptable?
- How will users override or escalate?
Production gap
- What is missing in identity, security, reliability, monitoring, cost, support, and handover?
- Is this a simulation, prototype, pilot, or production system?
Evidence
- workflow map;
- architecture diagram;
- working repository or sanitized code sample;
- evaluation and failure report;
- Demo focused on the workflow;
- risk register;
- runbook;
- and retrospective.
The artifacts matter because they let another person inspect your judgment.
A 90-day domain-to-FDE experiment
Days 1–15: select the decision
- Choose one workflow you understand firsthand.
- Interview two or three additional users to challenge your assumptions.
- Capture the current process, exceptions, owners, and baseline.
- Define a narrow outcome and stop condition.
Days 16–35: build the foundation
- Refresh one programming language, APIs, SQL, Git, tests, and debugging.
- Create a simple data model and integration boundary.
- Write the first architecture decision record.
- Set up basic logging and repeatable local execution.
Days 36–55: build and evaluate the solution
- Implement the smallest end-to-end workflow.
- Create representative tests and an evaluation set.
- Add explicit failure handling and human review.
- Compare at least two solution options instead of accepting the first working Demo.
Days 56–75: test operational readiness
- Review permissions, sensitive data, observability, cost, and rollback.
- Pilot with a small user group if authorized.
- Record where the system changes the workflow and where it adds friction.
- Keep the project label honest.
Days 76–90: package the evidence
- Publish a sanitized architecture and project narrative.
- Write the evaluation and failure report.
- Record a short workflow Demo.
- Create a runbook and production-gap list.
- Ask an experienced engineer and a domain peer to review different parts of the work.
At the end of 90 days, the goal is not to declare yourself an FDE.
It is to answer a more useful question with evidence:
Can I turn domain judgment into a bounded, testable, governable technical system—and explain where I still need help?
Final judgment
The best FDE is not automatically the strongest programmer or the most experienced business operator.
It is the person—or tightly coupled team—that can keep three truths connected:
- what the business actually needs;
- what the technology can responsibly do;
- what the organization can operate over time.
Domain experts begin with a valuable advantage: proximity to the problem and responsibility for the outcome.
To convert that advantage into forward-deployed capability, they must make their tacit knowledge explicit, acquire durable engineering judgment, respect production boundaries, and prove the result through inspectable work.
Business is not a substitute for technology.
Technology is not a substitute for business judgment.
Forward-deployed work exists because the value appears only when the two become one delivery loop.
Related learning
- Learning Hub Chapter 2: The FDE Mindset
- Learning Hub Chapter 3: The FDE Competency Map and Learning Roadmap
- Learning Hub Chapter 8: From Business Problems to Technical Solutions
- Learning Hub Chapter 12: System Architecture for Enterprise AI
- Learning Hub Chapter 16: Requirement Discovery and Solution Design
- Learning Hub Chapter 19: The Last Mile of Deployment
Sources and further reading
- OpenAI — Forward Deployed Engineer, San Francisco
- OpenAI — Technical Deployment Lead, Forward Deployed Engineering
- OpenAI — Forward Deployed Software Engineer, San Francisco
- Palantir — A Day in the Life of a Forward Deployed Software Engineer
- Palantir — A Day in the Life of a Deployment Strategist
- NIST — AI Risk Management Framework
Related Next Steps
Keep building the skills, evidence, and market context behind this topic.