Every enterprise wants an AI agent. Almost none can say who it’s for, what it must answer, or whether the answer even exists yet. That gap, not model quality, is where most agentic AI implementations quietly die. Forward deployed data engineers (FDDEs), embedded inside the business function they serve, close that gap with three moves before a single pipeline gets built.
Start With One Role, Not Twenty
An agent built for “supply chain” serves no one. Before any architecture conversation, name a single persona whose decisions the agent will change, not a department, a person with a workflow.
In supply chain, that precision looks like: the Site Materials Planner (MRP Controller) who owns inbound cadence, safety stock, and reorder policy at one factory. The FG Deployment & Replenishment Planner who sets stock-cover policy for finished goods across the distribution center (DC) network. The Distribution Capacity Planner who makes the overflow call before a breach becomes a fire drill. The Network & Transportation Planner who owns ZIP-to-DC assignment under hard direct-to-consumer constraints.
Notice the vocabulary: cadence, stock cover, usable capacity, lane cost. If you can’t describe the persona in their own domain language, you don’t know them well enough to build for them. One role per release. The rest queue behind it, that’s discipline, not neglect.
Figure 1 — One named role per release; the rest queue behind it.
Lock the Top Three Questions
With the persona named, extract the three questions they most urgently need answered, written in their words, not IT’s. For the Site Materials Planner:
- “What delivery frequency should each material run at, and what does the change save per month and per year?”
- “How much working capital and carrying cost is tied up at today’s cadence, by material and in total?”
- “If I tighten material X’s cadence, what happens to truck utilization, stockout risk, and total cost?”
Three, not thirty. Then each question gets three PASS/FAIL acceptance statements, binary, testable exactly as written. A question counts as answered only when all three pass. Nine statements total: that’s the agent’s contract. The persona signs it, the FDDE builds to it, and scope creep now has to argue with a signature.
Figure 2 — Three questions, nine acceptance statements: the agent’s contract.
Classify Every Question: Retrieval or Inference
Now the step almost everyone skips. For each question, ask one thing: does the answer exist anywhere today?
If yes, it’s retrieval. The answer is sitting in SAP, Snowflake, a spreadsheet, or a dusty BW cube. Even if a gnome guards it inside a legacy system and releases it only once a year under a full moon, it still counts as retrieval. Retrieval is an access-and-plumbing problem: pipelines, governed data products, a semantic layer.
If no, it’s inference. The answer must be generated. It’s June and the planner wants September sales; there are no September actuals anywhere on Earth. That’s a forecast, an optimization, a simulation, and it ships with error bars, a MAPE, and validation gates, not a lookup.
The split is brutally diagnostic. In one recent four-MVP persona mapping, eight of twelve priority questions were inference, two-thirds of what active users needed sat beyond what static reporting could ever serve. Lay that split against your team’s actual skills and your data estate, and you know before building whether you can deliver on the business partner’s request, at what accuracy, and by when.
Figure 3 — One diagnostic question splits every request into retrieval or inference.
The Payoff: Alignment as an Engineering Artifact
Role, questions, retrieval-or-inference. Skip the sequence and you’re running through the jungle blind, hoping you don’t hit a tree or drop into a river. Run it, and expectation alignment stops being a soft skill and becomes an engineering artifact, versioned, testable, signed. Agents rarely fail because the model was weak. They fail because nobody agreed, in writing, on the question.