Deep Dive into the FDE Role: Ontology-Driven vs. Scenario-Driven Approaches

What Is FDE: More Than Just Project Delivery

FDE (Forward Deployed Engineer) is a role that has emerged in recent years alongside the explosion of demand for real-world AI deployment. The core working model is straightforward: an FDE team sends one or more engineers directly into a client's organization to build a complete, customized AI system or solution from the ground up.

On the surface, this looks a lot like traditional "on-site project staffing." But there's one critical difference — productization. If an FDE engineer has to start from scratch with every new client, with no way to reuse what was built before, then it's essentially the same as outsourced staffing. A true FDE takes a repeatable AI transformation framework for a specific industry (say, finance) and turns it into a reusable product. When they arrive at a new client, they only need to adjust parameters, environment, and variables to deploy quickly.

In other words, the value of FDE isn't just "delivering solutions that fit the client" — it's that every delivery feeds back into the product and builds transferable capability. That's the defining line between a genuine FDE practice and a glorified outsourcing shop.

Two Schools of Thought: Ontology-Driven vs. Scenario-Driven

After nearly six months of hands-on practice and exploration, the author has distilled the FDE landscape into two distinct approaches:

Ontology-Driven (The Palantir School)

This school, exemplified by Palantir, starts by building a unified data ontology — abstracting an enterprise's people, processes, assets, and relationships into a structured semantic model, then building applications on top of it. The strength here is strong data consistency and solid enterprise-grade governance. The downside is that upfront modeling is expensive and time-consuming.

Palantir is a US data analytics company founded in 2003, originally serving US government and intelligence agencies before expanding to enterprise clients. Its flagship product, Foundry, is built around the concept of an "Ontology" — a term borrowed from philosophy (referring to a systematic account of existence) that in data engineering means defining all the entities within an enterprise (employees, orders, equipment, processes, etc.) and their relationships as a unified structured semantic graph. This approach allows data from disparate business systems to "speak the same language," enabling AI applications to operate on a consistent semantic layer rather than working in silos. Palantir's FDE teams (internally also called "deployment engineers") use this methodology to help clients with enterprise-wide data governance and AI system construction — individual engagements often span quarters or even years.

Scenario-Driven (The AI Worker School)

The other path is scenario-driven, which the author calls the "AI Worker school." The idea is to break down a company's AI transformation into many discrete Workers (AI agents or bots), each one solving a specific, well-defined business pain point. This approach is fast to deploy, delivers tangible results quickly, and is better suited for smaller teams that need to validate ideas rapidly.

These two schools aren't opposites — they map to different company sizes and deployment rhythms. Large enterprises often need an ontology foundation first, while fast-moving business scenarios benefit from getting AI Workers up and running quickly.

Scenario-Driven in Practice: From Learning Assistant to Resume Assistant

The author uses their own education platform as a case study to illustrate what the AI Worker model looks like in practice.

The Learning Assistant is a typical Agent: users can ask it questions or request a "summary of my learning activity over the past seven days." It automatically aggregates course progress, study records, and other data. Under the hood, this works by connecting an AI Agent to the Java-based microservice backend of the learning platform. Course videos are uploaded manually, spot-checked for quality, and then indexed into a Milvus vector database for retrieval.

Following the same logic, new Workers can be added continuously:

• Resume Assistant: Upload top-tier reference resumes, and the AI quickly analyzes the gap between a student's resume and the gold-standard samples, then combines teacher input to suggest targeted improvements.
• Lesson Prep Assistant & Supervision Assistant: Support teaching and student management workflows.
• Enrollment Screening & Service Assistant: Automatically handles enrollment assessments, data entry, course follow-up reminders, and other service tasks.

When a company's AI Workers grow from 10 to 20 to 50, a qualitative shift occurs. The author notes that with AI tooling and the learning platform, a single person can now independently launch an entirely new course — for example, a technical deep-dive into giant humanoid robots. Just record or organize technical content, then use AI to assist with lesson planning, delivery, and knowledge breakdown. One person can now "run" a full business scenario.

Milvus is an open-source vector database designed specifically for AI applications, developed by the Chinese team Zilliz and open-sourced in 2019. Unlike traditional relational databases that retrieve by exact field matching, vector databases store high-dimensional numerical vectors — generated by AI models (such as text embedding models) from unstructured content like text, images, and audio. Retrieval works by calculating cosine similarity or Euclidean distance between vectors to find semantically similar content. This is the core infrastructure behind RAG (Retrieval-Augmented Generation): course materials, video transcripts, and other knowledge documents are pre-vectorized and stored in Milvus. When a user asks a question, the most relevant knowledge fragments are retrieved in real time and passed to a large language model to generate a grounded, accurate response — anchored in domain-specific knowledge rather than the model's general training data.

Clearing Up a Misconception: AI Deployment ≠ Cost Reduction

The author pauses to correct a widespread misconception: AI deployment is not about cutting costs — it's about solving pain points.

The reason AI in China is so often tied to "cost reduction and efficiency" is largely because many businesses haven't yet expanded to compete in wider markets. The author's example: if an AI solution deployed at a traditional furniture company costs relatively little but meaningfully boosts sales, revenue, and market presence — why would that company focus on cutting costs? Cost-cutting only becomes a priority when the business isn't making enough money in the first place.

The author doesn't rule out that some companies will use AI purely to cut headcount: if one person with AI skills earns ¥50K/month but does the work of five people (who each cost ¥20K × 5 = ¥100K) and does it better, then naturally only one person stays. But underlying this is a more fundamental principle — survival of the fittest. Technology has always advanced, with new tools replacing old ones. That logic has held since the beginning of human history.

Advice for Aspiring Entrepreneurs

For developers looking to strike out on their own, the author believes exploring FDE architectures is a viable path. If you have coding skills, communication skills, and the ability to coordinate across stakeholders, you can absolutely build a complete, productized solution for a specific vertical — such as a full education system covering public courses, VIP programs, learning products, and supporting services.

Combine AI with a lean team, and your total cost stays low while your delivery capacity can cover work that once required a much larger team. This is the real-world value of FDE product thinking: using reusable AI capabilities to unlock service businesses that were previously impossible to scale.

A note of caution: the perspectives in this article come primarily from one practitioner's hands-on experience. The framework presented here (ontology-driven vs. scenario-driven) is a personal, exploratory model — treat it as a useful lens, not an industry-standard definition.