The AI Was the Easy Part: What is a Forward Deployed Engineer for Supply Chain?
In 2012, the Harvard Business Review called the data scientist "the sexiest job of the 21st century."
Every company suddenly wanted one.
More than a decade later, the title everyone is chasing now is the Forward Deployed Engineer.
This engineer is embedded inside a company's operation to make AI models or optimisation algorithms actually work in their messy reality.
Unfortunately, few operations are messier than a supply chain.
I learned it the hard way when I became Supply Chain Data Scientist.
For example, imagine a shipment of luxury bags leaving a warehouse in Milan, passing through trucks, airports, and customs clearance before arriving at a store in Shanghai.
This chain involves several teams in multiple countries that use different systems (ERP, WMS, TMS) that were not designed to provide harmonised data.
Therefore, in most AI supply chain projects, the biggest challenge is implementing agents in this chaotic environment.
This was the case in the past for business intelligence and data science, and now even more with generative AI.
Why companies are now paying so much to have Forward Deployed Engineer to implements AI for Supply Chain operations?
In this article, I will share a project I conducted to illustrate the challenges FDEs face in this environment and the qualities they need to manifest.
This is a deployment of an AI-powered distribution chain monitoring tool that helps planners find the root cause of late store deliveries.
I have implemented this agentic orchestration in the logistics department of a fashion retailer based in Milan.
Their problem was their limited capacity to process complex data to detect and analyse failures in the distribution chain.
Logistics Director: "More than 35% of late deliveries are not explained."
They wanted an agent to conduct root cause analyses from the data alone, without biases, like the analysis below.
The interesting part of this implementation is not the agentic orchestration itself, but everything I had to build around it.
I will use it to go through everything the job actually requires:
- Reading systems with no documentation
- Getting teams to agree on a definition
- Letting the users test the tool before you trust it.
None of it is technical, and all of it is the job of a Forward Deployed Engineer.
If you are a data scientist looking at where the highest-paid roles are right now, this is the work behind the title, and the skills you would need to do it.
Deploying Claude Agents Connected to Supply Chain Systems
It started with a request from the logistics director: "I want AI to help my planners find the root cause of failures in my distribution chain."
A team of 12 planners manages store inventory.
They send orders to the warehouse, each with a requested delivery date, and monitor shipments until they reach the store.
Because of delays in the warehouse, a routing change, or a hold at customs, some orders arrive late.
Store managers complain to the director because a late delivery means lost sales.
Monitor shipments using timestamps
Fortunately, each step is recorded in a system:
- Warehouse operational teams that will prepare and load the goods in a truck, using a Warehouse Management System (WMS)
- Transportation teams organise the pickup at the warehouse, air freight and the last-mile delivery, using a Transportation Management System (TMS)
These systems generate the timestamps used to track orders across the entire distribution chain.
A team of analysts manually crunch data in Excel to explain past delays and flag future ones.
This is slow and inefficient. The analyses usually arrive too late, and the teams still do not have enough to pinpoint the root cause.
So the discussion turns into an argument, each team pointing at the other.
As I like to say, the most complicated task in supply chain management is dealing with humans.
Hiring Claude as a Super Analyst
That is why we built a Claude agent, connected to their data through an MCP server, to run this analysis regularly and help analysts act on it.
The agent can query the data to answer any request in natural language, helping planners find the root causes of failures in the distribution chain.
Reports with interactive visuals, like the one above, can be generated by analysts in seconds without writing a single line of code.
The six analysts now produce more root cause analyses than before, and they arrive in time to act on them.
Analysts can now automatically schedule flash reports to each team (warehouse, road freight, air freight), and conduct deep root cause analysis in less than 5 minutes, and use the agent a performance copilot.
This was not an easy task though.
The biggest challenge here was not the design, but the implementation.
The rest of this article is about what it took us to get there, because the deployment was the hard part.
If you want the details of the solution itself, they are in this short video:
I will go through the biggest obstacles and challenges I faced when trying to implement Claude in this messy environment.
Like many analytics projects, the first problem was getting access to clean, harmonised data.
The clean table is the output, not the input
The visual below is a sample of the dataset used by Claude, via MCP implementation, to answer analysts' questions.
In a single table, we have all the timestamps covering the distribution chain from order creation to store delivery, sourced from multiple systems.
Each field is described to Claude, with the operational context, so it can query the data to answer any question.
For example, airport_on_time is FALSE if the truck reached the airport after its cut-off.
When I started the project, nothing was connected.
Indeed, these three systems have their own schema, field definitions and formats.
It was my role as a Forward Deployed Engineer to understand how to extract the right information, clean it and store it in a harmonised table.
Let me share two examples.
Example 1: No explicit field to extract the right information
In an ideal world, you connect to the Snowflake tables and pick the right field based on its name.
My reality was different.
When I asked the IT infrastructure manager where to find the order creation date, he pointed me to this table.
The field names are not explicit.
The last two columns come from a custom development by an engineer who left the company four years ago.
PLNORDis the order number in the planning toolCRINDis an attribute defining if the order is created by a human or automaticallyHEUR_DTSandMANU_DTSare the two fields we need to take to get the order creation date and time
In this kind of situation, the best reflex is to get users and the infra team around the same table.
My question: "Which field should I take?"
Unfortunately, no one was able to give me a complete answer.
I used multiple examples of orders, and compared what planners have on screen with the data in the table.
That way, I discovered that order_creation_date is a formula that depends on CRND
ORDER_CREATION_TS = HEUR_DTS when CRIND = 'A'
MANU_DTS when CRIND = 'M'Nothing about this was explicit, and with no documentation, confirming the formula took days.
This kind of detective work is essential: it is what makes the tool reliable, and reliability is what earns the customer's trust.
So here is the first skill the job requires: get your hands into the systems, and bring the operational users in with you.
The people who run the process every day know what the fields mean, even when nobody wrote it down.
Example 2: Five workshops to define one boolean
This second example shows how you will have to reconcile operational reality with the data available in the systems.
After the planners create them, the orders are sent to the warehouse.
Once the warehouse team has prepared them, they are loaded onto trucks.
Sometimes the truck is not loaded on time, and the delay cascades through every step that follows.
There are two scenarios for a delayed loading:
- The truck is here, but the pallets are not ready, so the warehouse is responsible
- The pallets are ready, but the truck is not here, so transport is responsible
That is what the warehouse manager told me.
Experience told me nothing is ever that simple in logistics, so I double-checked with the transport manager.
He gave me a third scenario nobody had mentioned.
Transport Manager: "If the truck is sent by the freight forwarder, it is not my responsibility."
At this stage, I had to juggle all the edge cases to extract the right information from the WMS and the TMS.
After five workshops with both teams, we agreed on a formula that satisfied everyone and reflected the operational reality as closely as we could.
LOAD_ONTIME = LOAD_END <= 19:00 # the milestone fact, same for both scenarios
# responsibility, only when LOAD_ONTIME is False:
if CTRL == 'SHP': # Scenario 1: our own truck is always there
CAUSE = 'WAREHOUSE' # warehouse owns readiness AND loading
elif CTRL == 'FWD': # Scenario 2: forwarder pickup
if PACK_END <= PU_ETA: # goods were ready by the booked slot
CAUSE = 'FORWARDER' # truck came late, warehouse is a cascade victim
else:
CAUSE = 'WAREHOUSE' # goods not packed in timeThere is no need to go into the details of the formula. What matters is that it took a week to agree on it.
The real bottleneck
I expected to work on bringing a better algorithm.
Finally, I was there to build the definitions that the algorithm needs to exist at all.
That is the second skill the job requires: do not accept the first definition you are given.
Ask the same operational question until every team gives you the same answer, then write it down.
Definitions are part of the deliverable.
And once those definitions exist, the real question is how to get an agent to use them in a way planners will actually trust.
Turning definitions into tools
Once the formulas existed, the AI part was almost easy.
I connected Claude Opus to a set of tools to query the tables containing the transactional data.
The customer did not want to provide too much information to Claude, only the basic minimum to understand the data.
Logistic Director: "We want the agent to provide unbiased root cause analysis and assess each team's performance."
Instead of building a dashboard for every scenario, we gave the agent access to tools to query a dataset, which includes flags and lead times, and let it compose the analysis itself.
In the MCP implementation, we provide a plain-language description of what the tool returns and what the underlying operational rule means.
As a first test, we asked Claude to explain the tools it has on hand.
It came back with a correct interpretation of every flag that was validated by planners.
The agent understood the data because a Forward Deployed Engineer had finally sat down with two teams and decided what it meant.
The second test was harder: how would it use the flags to assess performance?
It proposed comparing flag-based attribution against actual durations, which is exactly the distinction that made the results in the opening possible.
That was the moment I knew the approach would hold.
What remained was getting it into the team's hands.
User Acceptance Test: making sure that the tool will be used
A demo proves the builder can make the tool work. It proves nothing about whether the team can.
So, I asked the planning team for something else: come with the analyses you already do every week, and we run them against the agent.
Because these planners had spent years producing the same recurring reports by hand, they knew what the answer should look like before the agent said anything.
If it drifted, invented a number, or missed a nuance they always check, they would spot it immediately.
That is what makes them better testers than me: I could verify that the tools returned the right rows, but only they could tell me whether the answer was useful.
One test in practice
A planner asked for an analysis he runs every Monday:
Please prepare me an analysis of the delays due to flight time for the last week of the scope.
The first thing to check was whether the agent had answered the question the planner actually meant.
The request was vague, and the agent could easily have answered something out of context.
But it understood that the planner meant the orders delivered last week, and it separated the delays that cost a day from the ones that did not.
The model proved it could understand the context, challenge the request, and give the planner what he actually needed.
This is exactly what the logistics director asked for.
Each recurring report is a unit test
In a classic IT project, you write a specification, build against it, and test that the build matches the spec.
Here, there was no specification because nobody could write one before seeing the tool in action.
What they had were years of recurring analyses instead, and those turned out to be a better test suite than anything I could have specified up front.
How to become a great Supply Chain FDE?
Looking back at this project, we can split my contribution into two parts.
There was the job of the data scientist or AI engineer: building an MCP server with a set of tools to query and describe the data with docstrings.
This part took less than 5 days.
And there was the rest that made sure we had a tool deployed and usable by teams that took weeks, a dozen short meetings, and long working sessions.
This looks more like my old job as a continuous improvement engineer than an AI engineer deploying agentic workflows.
How to develop these skills as a software engineer or data scientist?
My point here is not that one job replaced the other. In this environment, you need both.
If you want to build these skills, I walk through a methodology using the case studies on this blog:
The capability is no longer the bottleneck: you are, and that is the good news.
About Me
Let’s connect on LinkedIn and Twitter; I am a Supply Chain Engineer using data analytics to improve logistics operations and reduce costs.
