From Labor-First to Decision-First AI: How FDEs Build Reusable Decision Systems

From Labor-First to Decision-First AI: How FDEs Build Reusable Decision Systems

An enterprise can deploy dozens of agents and still fail to build a scalable AI operation.

The agents may summarize reports, copy data between systems, draft emails, and complete queues of tasks. Each one saves time. Yet every new customer, workflow, and exception can still require another integration, another prompt, and another layer of people keeping the automation alive.

The system is doing more work, but delivery is not becoming easier.

This is the difference between two directions for enterprise AI:

• Labor-first AI asks, “Which tasks can an agent perform?”
• Decision-first AI asks, “Which recurring business decision should become explicit, executable, governed, and reusable?”

These are not mutually exclusive. Agents remain useful workers inside a decision system. The difference is what the organization treats as the durable asset.

In a labor-first design, the asset is often the agent or workflow that completes a batch of tasks. In a decision-first design, the asset is the structured decision itself: its trigger, facts, constraints, options, authority, action, and audit trail.

That shift matters for Forward Deployed Engineers because the FDE’s most valuable contribution is not the amount of code or number of agents shipped. It is the ability to translate operational judgment into systems that can run, be inspected, and improve.

OpenAI currently describes Forward Deployed Engineering as sitting at the intersection of customer delivery and core platform development. Its technical deployment roles also emphasize moving from prototype to production and surfacing reusable patterns that shape the platform. The phrase “reusable patterns” is the key: field work creates leverage only when one engagement makes the next one easier.

Why task automation often scales linearly

Imagine a distributor that wants to automate replenishment.

A labor-first implementation may begin by creating agents for separate tasks:

1. one agent reads the inventory report;
2. one checks recent sales;
3. one looks for incoming shipments;
4. one drafts a replenishment recommendation;
5. one sends the recommendation to a regional manager;
6. one creates an order after approval.

This can work. But the architecture hides the real problem across several workers.

What happens when:

• two systems use different product identifiers;
• one warehouse has an emergency safety-stock rule;
• the manager overrides the recommendation;
• a promotion changes expected demand;
• a supplier cannot deliver the normal quantity;
• the same decision is needed for another region;
• an auditor asks why an order was created?

Adding another agent can handle each exception, but complexity continues to grow with the number of tasks, rules, and handoffs. The organization is scaling automated labor rather than scaling shared judgment.

The more durable question is:

What exactly is the replenishment decision, and what must be true for the system or a person to make it responsibly?

Once that question is explicit, agents become implementation choices rather than the architecture’s center.

The decision is the unit of design

A useful decision model has seven parts.

Most AI demos stop around the fourth row: they produce a recommendation.

An operational decision system must continue through authority, action, and trace. Otherwise, it produces an answer without establishing who is accountable, whether the action is permitted, or how the organization can reconstruct what happened.

This is also why decision-first does not mean automation-first.

A low-risk, high-volume decision may be automated. A material financial, safety, employment, or compliance decision may require a named human approver. NIST’s AI Risk Management Framework explicitly treats governance as cross-cutting and calls for human oversight processes to be defined, assessed, and documented according to organizational policy.

The goal is therefore:

Automate what may be automated, support what requires judgment, and preserve responsibility in both cases.

From dashboards to governed action

Many enterprises already have plenty of data:

• reports and dashboards;
• data lakes and warehouses;
• BI systems;
• operational databases;
• analytics models.

Yet a dashboard showing “inventory risk” is not the same as a replenishment decision.

Between data and action sits a decision gap:

Data
→ shared business meaning
→ evaluated options
→ permitted authority
→ operational action
→ observed outcome

Organizations struggle to cross this gap for predictable reasons:

• different teams use different definitions;
• key rules live in experienced employees’ heads;
• no one owns the final decision;
• systems expose data but not allowable actions;
• overrides occur in chat or spreadsheets;
• the reasoning behind an action is not retained.

An FDE helps build the bridge. The work is not to create one more dashboard. It is to connect evidence to an executable, governed action.

The four-part domain model

The visual notes behind this article call this structure an “ontology four-piece set”: object, relationship, action, and rule. It is a practical way to begin, although ontology products and domain-modeling methods may use different terminology.

Palantir’s current Ontology documentation describes operational decisions through data, logic, action, and security. It also uses object and link types to represent the organization and action types to capture operator input or orchestrate decisions into existing systems.

For an FDE, the useful principle is broader than any vendor:

Model the business in terms the operation recognizes, then connect those terms to data, logic, permissions, and actions.

1. Objects: the nouns

Objects are the entities the business reasons about:

• Distributor
• SKU
• Warehouse
• Inventory Position
• Purchase Order
• Shipment
• Promotion
• Replenishment Decision

They should not merely mirror database tables. A useful object has business meaning, a stable identity, relevant properties, and clear ownership.

2. Relationships: how the nouns connect

Relationships make isolated records interpretable:

• Distributor places Purchase Order
• Purchase Order contains SKU
• Warehouse holds Inventory Position
• Shipment replenishes Warehouse
• Promotion affects demand for SKU
• Decision uses evidence from Inventory Position

These relationships allow a system to answer operational questions without rebuilding joins and terminology for every application.

3. Actions: the verbs the business may execute

Actions describe permitted changes:

• create a replenishment order;
• initiate a stock transfer;
• request approval;
• reject a recommendation;
• adjust a forecast;
• escalate an exception.

An action is more than an API endpoint. It should state who may invoke it, what inputs it needs, which validations run, what system is changed, and what record is created.

4. Rules: judgment and constraints

Rules encode the conditions surrounding a decision:

• projected stock after lead time must remain above safety stock;
• orders above a threshold require procurement approval;
• restricted SKUs cannot be transferred across a border;
• a forecast with low confidence requires manual review;
• an override must include a reason.

Some rules can be implemented as policy as code. Open Policy Agent, for example, provides a declarative policy language and APIs that separate policy evaluation from application code. But “policy as code” is not a requirement to encode every piece of human judgment in Rego or another rules engine.

The right boundary is:

• use deterministic rules for explicit, testable constraints;
• use models for probabilistic estimates or interpretation;
• use people for accountable judgment where context and risk demand it;
• make escalation between the three visible.

When these four parts are connected, the experienced operator’s judgment begins to become a system capability rather than tribal knowledge.

A worked example: automatic distributor replenishment

Consider a Monday-morning replenishment run.

Step 1: trigger the evaluation

The decision is evaluated weekly and whenever projected stock drops below an agreed threshold.

The trigger creates a decision instance with:

• decision ID;
• distributor, warehouse, and SKU;
• trigger type;
• timestamp;
• policy and model versions.

Step 2: assemble facts

The system retrieves:

• trailing sales;
• committed orders;
• on-hand and available inventory;
• in-transit stock;
• supplier lead time;
• active promotions;
• forecast and confidence;
• data freshness and quality status.

The FDE’s job is not only to connect the APIs. The FDE must establish common meaning. “Inventory” might mean on-hand stock to one team and available-to-promise stock to another. If definitions remain ambiguous, automation only makes disagreement faster.

Step 3: apply constraints

Deterministic controls are evaluated:

• safety stock;
• maximum order quantity;
• approval thresholds;
• restricted products or regions;
• budget availability;
• stale-data cutoff;
• exception policies.

Each result should be inspectable. A user needs to know whether an option disappeared because it was economically unattractive, operationally impossible, or prohibited.

Step 4: generate feasible options

The system could produce:

An AI model may summarize the evidence or explain trade-offs. It should not invent an option that violates an enforced constraint.

Step 5: assign decision authority

The authority model could be:

• automatically execute low-value, policy-compliant orders;
• require a regional manager for medium-value orders;
• require procurement for higher-value or exceptional orders;
• escalate uncertain or contradictory evidence to an analyst.

“Human in the loop” becomes meaningful only when the loop names the person, decision rights, response time, override capability, and escalation path.

Step 6: execute the action

After approval, the system:

• creates the purchase order or transfer request;
• returns the external system identifier;
• reports partial or failed execution;
• prevents duplicate submission;
• exposes a safe retry or compensation path.

This is where an answer becomes operational value.

Step 7: retain the trace and learn

The decision record should retain:

• evidence used;
• data timestamps;
• option set;
• applied rule and model versions;
• recommendation and confidence;
• decision maker;
• approval or override reason;
• action result;
• later business outcome.

The final field matters most. Without the observed outcome—stockout avoided, inventory accumulated, service level changed—the organization cannot improve the decision.

The FDE capability map: what grows at each level

Decision-first delivery requires more than technical depth. It also changes how FDE maturity should be assessed.

The following matrix turns the source material into six capability tracks across five levels. It is not a universal certification standard; it is a practical self-assessment model.

The key transition is from L1 to L2:

L1 proves you can complete a task. L2 proves you can independently own a decision from ambiguity through acceptance.

L3 and L4 are not simply “more coding.” They require governance, reuse, and the ability to make multiple projects benefit from the same decision assets.

What should become reusable?

Not everything in a customer engagement should become product code.

A useful reuse hierarchy is:

Level 1: evidence

• workflow maps;
• baseline metrics;
• user research;
• failure cases;
• acceptance results.

Level 2: decision specification

• trigger;
• required facts;
• constraints;
• option schema;
• authority model;
• actions;
• audit requirements.

Level 3: technical components

• connectors;
• object and relationship definitions;
• action contracts;
• policy modules;
• evaluation datasets;
• observability dashboards.

Level 4: delivery assets

• discovery workshop;
• prototype template;
• deployment checklist;
• demo and acceptance plan;
• runbook;
• post-deployment review.

Level 5: product capability

• configurable domain module;
• reusable decision service;
• governed action library;
• cross-customer platform feature.

This hierarchy prevents a common mistake: declaring a pile of copied code to be a reusable platform.

Reuse requires explicit boundaries, documentation, configuration, tests, ownership, and evidence that the abstraction survives a second context.

The delivery flywheel

The source material describes an FDE delivery cycle as:

Enter → Embed → Exit → Return

This is more useful than a one-way project plan because a strong engagement should create the conditions for the next engagement.

Enter: establish trust and find the decision

The FDE enters through an operational problem, not a technology pitch.

The first objective is to identify:

• a high-value decision;
• the people who make and experience it;
• the current evidence and constraints;
• the cost of delay or error;
• the authority to change the workflow.

Embed: build and prove one slice

The FDE works closely with users to model the decision, assemble usable data, build the smallest end-to-end slice, and demonstrate it repeatedly.

A good slice crosses all critical boundaries:

facts → constraints → options → approval → action → trace

It is usually better to finish one governed slice than demo five disconnected agents.

Exit: transfer ownership and capture the asset

Exit does not mean abandoning the customer after launch. It means the system can operate without permanent dependence on the original builders.

Before exit, the team should confirm:

• named operational and technical owners;
• acceptance evidence;
• monitoring and incident procedures;
• permissions and policy ownership;
• documentation and training;
• known limitations and backlog;
• reusable patterns captured outside customer-specific code.

Return: use evidence to expand or productize

The next conversation begins with evidence:

• which decisions improved;
• where users overrode recommendations;
• which rules changed;
• which connectors repeated;
• which capabilities should become configurable;
• which adjacent decision is now worth solving.

Return is not automatically an upsell. It is a product and delivery learning loop. The next project should start with a thicker asset base and a shorter path to evidence.

The moat is not merely an ontology

It is tempting to conclude that the moat is an ontology, policy repository, or decision library.

Those assets can matter, but none is defensible by itself.

A durable advantage comes from the combination of:

1. domain semantics that users recognize;
2. decision logic that reflects real operating constraints;
3. governed actions connected to production systems;
4. outcome feedback from actual use;
5. delivery methods that repeatedly discover and improve the first four.

A static ontology can become another documentation project. A rule repository can encode obsolete policy. A template library can fill with components no one trusts.

The moat appears when the assets stay connected to field evidence and are continuously governed.

Anti-patterns to avoid

1. Building an enterprise-wide ontology before choosing a decision

Start with a valuable decision slice. Model only the objects, relationships, actions, and rules needed to operate it. Expand through proven adjacent use cases.

Palantir’s own ontology guidance warns against siloed design and recommends focused object types, collaboration across teams, and choosing actions for human or agentic decisions rather than using the same mechanism for every transformation.

2. Treating every judgment as a hard rule

Some constraints are deterministic. Some inputs are probabilistic. Some decisions require accountable human judgment. Conflating them creates brittle systems or false confidence.

3. Letting the model enforce policy

A language model can interpret or explain policy, but critical authorization and compliance controls should be enforced through testable system mechanisms.

4. Producing a recommendation with no action path

If users must copy an answer into another system, approvals are not captured, and outcomes are not linked back, the system remains a decision-support demo.

5. Automating without an owner

Every production decision needs ownership for policy, data quality, operation, incidents, and business outcomes. “The agent decided” is not an accountability model.

6. Calling the first customer implementation a platform

The second implementation tests whether an abstraction is reusable. Productization should follow evidence, not precede it.

A practical FDE decision canvas

Before building, an FDE can complete this one-page canvas with the customer.

If the team cannot complete the first ten fields, it is too early to add more agents.

The deeper shift

Labor-first AI can create immediate productivity. It is often the right starting point for a bounded, low-risk workflow.

But an enterprise cannot build durable operating leverage by measuring only how many tasks an agent completes.

Decision-first AI asks harder questions:

• Did the system improve a real decision?
• Are the facts and definitions shared?
• Are constraints explicit and enforceable?
• Is authority assigned?
• Does the action reach the system of record?
• Can the organization reconstruct and challenge what happened?
• Does the outcome improve the next decision?
• Does this delivery make the next delivery easier?

That is where FDE work becomes more than custom implementation.

The FDE does not merely deploy labor. The FDE helps the organization turn judgment into a governed capability—and turns field delivery into a learning system.

Sources and further reading

• OpenAI — Forward Deployed Engineer
• OpenAI — Technical Deployment Lead, Forward Deployed Engineering
• Palantir — Why create an Ontology?
• Palantir — Ontology overview
• Palantir — Ontology design best practices
• Open Policy Agent — Policy as code
• NIST — AI Risk Management Framework