# Meet the Retail Engineer
> A Retail Engineer is the human owner of an AI agent deployment in retail operations. The role maps the retail process, agrees a business KPI and an evaluation standard with the customer, designs and builds the retail agents, and stays accountable for the result after go-live, running the DIPE loop of Design, Implement, Prove and Evolve. At CommerceClarity the Forward Deployed Engineer is a separate human seat on the same engagement, owning the integrations, transformations and pipelines at the edge of the customer’s stack.
One person owns an AI agent deployment in retail, from the first business question to the live catalog. This is what a Retail Engineer does, and where the forward deployed engineer fits.
**Published at:** 2026-09-01T09:00:00Z
Enterprise software has been sold as a triangle for most of the time any of us have been working in it. The customer sat at the top. Service ran down one side: consultants and integrators paid to make the system fit. Software ran down the other: the vendor, the licence, the roadmap.
The gap between the two sides had a name everyone in retail has heard. Not my scope.
Service could point at the product. Software could point at the implementation. The customer was left holding the deadline and the operating result.
We built our delivery model to remove that gap. The person who holds it together is called a Retail Engineer, and this is what the job actually is.
## What is a Retail Engineer?
A Retail Engineer is a customer-facing engineering role for AI delivery in retail operations. One person maps the process with the retailer, defines the business result, [designs the retail agents](/platform/agents), sets the [evaluation standard](/platform/governance), builds the agent workflow and stays on the account after go-live.
Same person from the first call to the live customer. That is the rule we run on, and it is the whole point of the title. Business translator, agent engineer, coder, operations builder, and sole owner of the result.
We start from the catalog because that is where retail processes meet. Supplier data, attributes, categorisation, content and channel requirements all pass through the product record. Our [catalog foundation](/solutions/catalog-foundation) is built on the same fact: every downstream workflow reads what the catalog says first.
## Why the role exists now
The work used to be split across several people: a consultant who understood the process, a solution engineer who configured the product, a development team that wrote the code. Every seam between them was a place for the result to fall through.
AI is changing the cost of those seams. An agent can be adapted to a new category, policy or channel in days. One person can now change a prompt, a rule or a service and see the score move the same afternoon, without opening a project that runs a quarter. The amount of a customer outcome a single person can carry went up, and the roles are catching up to it.
The titles have not caught up. Forward deployed engineer, GTM engineer, marketing engineer, solutions architect: every company putting AI inside somebody else’s operation has invented a name for the person who does it, and none of them mean quite the same thing. Marketing got there first, hiring people who build the systems the commercial motion runs on instead of writing a brief and waiting.
It is one shape, and it appears wherever the operation and the tooling used to sit with different people. Retail Engineer is that shape pointed at retail operations, catalog first.
## And the Forward Deployed Engineer?
We have that seat, and it is a human one, hired separately from the Retail Engineer and sitting on the same engagement.
The Retail Engineer owns what correct means for this retailer. The Forward Deployed Engineer makes sure the data can get there. On a large account you need both, and neither one is a version of the other.
## How the work runs: DIPE
Every engagement runs the same four phases, and we call it DIPE.
**Design** ends with two numbers agreed with the customer, and with the boring question answered: how the data gets in, and how the result gets back out. **Implement** builds the agent on the customer’s real data, not on a sample. **Prove** runs it at production scale until the numbers hold on the full catalog, in front of the customer. **Evolve** does not end, because a catalog does not stand still.
### The two numbers
One part of Design is worth stopping on, because everything after it is judged against it.
The KPI says whether the business got enough: products published, attributes completed, time to market, cost per product, whatever the live operation is actually measured on.
Neither number substitutes for the other. A workflow can be fast and wrong. It can also be accurate on a small sample and irrelevant to the operating target.
Nothing ships as done because the agent runs. It ships when both numbers reach target on the full catalog and the customer has looked at them, failures included.
## The three hard parts
Everything difficult about those four phases collects into three problems.
### Agree what right means
A language model is not deterministic and a retail catalog is a very wide input space. You cannot judge the output by reading a few good examples.
The evaluation set has to come from the retailer’s own rules and edge cases. What is correct for a pharmacy is wrong for a fashion retailer. What passes on one marketplace fails on another. An eval that works for one customer is not authorised for the next one: each customer owns its own set.
Once the evaluation set exists it is the only thing that says whether a change helped. Every prompt or rule edit gets the eval run again and the score read. Never tune by feel.
### Get the data in and the result back out
This is the unglamorous half, and it decides whether anything reaches production. Product data arrives as supplier feeds, ERP exports, spreadsheets and half-filled PIM records. The result has to land in the system the retailer already runs, in the format that system will accept.
A correct product record that cannot enter the customer’s environment has no operating value. This is the half where the Forward Deployed Engineer work sits, and on enterprise accounts it is most of the calendar.
Which is why it is mapped before anything is signed: import, attribute configuration and export, all three understood in Design. If the data cannot support the agent and cannot be fixed, we say no up front instead of promising around it. A broken import is a no-go, not a risk to manage later.
### Keep it right in month six
Catalogs do not stand still. New suppliers arrive, categories move, marketplace rules change, and an agent left alone gets worse on its own. A score proved once erodes if nobody watches it.
So the eval keeps running after go-live, and the customer gets both numbers in the same monthly report, the business KPI beside the correctness score. Reading one without the other is how a quiet regression survives a quarter.
Nothing goes onto a live tenant without a dry run against a snapshot and a look at the diff. A new objective is not a tweak, it is a new agent, and it starts again at Design. And when the score moves, somebody named owns the response. That is the part a title cannot fake.
## What the work feels like
A morning can start with a merchandising team explaining why a launch takes six weeks. By the afternoon the same person is inside taxonomy rules, prompts and the exceptions that actually block the flow.
No requirements document, no handover. They change the workflow, test it, and bring the result back to the people who run it. That proximity is the job.
Retail operations holds knowledge that never makes it into a clean specification: an approval that happens only for one category, a naming rule that lives in one person’s head, a marketplace exception buried in an old email. The role turns that into something an agent can run and an eval can check.
## Who becomes a Retail Engineer?
The strongest profiles come from solution consulting, solution delivery, ecommerce operations or retail technology. They know how to read a process, hold a customer room, and find the real problem under the request.
They also have a technical side, and they want to use it. They would rather build the workflow than write a ticket for it and wait. AI coding assistants make that shift cheap in a way it was not three years ago, but they do not replace the judgment. The hard part is still understanding the operation well enough to know what to build and what counts as correct.
Inside a lot of retailers, somebody is already doing part of this job without the title, holding the business rules and the systems together in their head. Retail Engineer gives that work a method.
## Where this goes
The title only matters if the accountability sits with one person. Ours does, and that person can show the two numbers that say whether the work is finished.
If this is the work you already do, the Retail Engineer roles are open in [Milan](/careers/retail-engineer-italy) and [London](/careers/retail-engineer-uk), and the Forward Deployed Engineer roles in [Milan](/careers/forward-deployed-engineer-italy) and [London](/careers/forward-deployed-engineer-uk). Everything else is on our [careers page](/careers).
## Author
## Questions
### What is a forward deployed engineer?
A forward deployed engineer is a customer-facing software engineer who turns a platform into a stable production system inside the customer’s own environment. The role usually owns integrations, custom services, data pipelines and technical reliability, working alongside the customer’s teams rather than from behind a roadmap.
### What is the difference between a Retail Engineer and a Forward Deployed Engineer?
They are two seats, hired separately, working the same engagement. The Retail Engineer owns the account and the method: the business goal, the KPI and eval, the agent design, the result after go-live. The Forward Deployed Engineer owns the code at the edge: integrations, transformations and pipelines inside the customer’s stack. At CommerceClarity both are human roles and both are open.
## Entities
- Retail Engineer · Thing, about
- DIPE · Thing, mentions
## Sources
---
Canonical: https://commerceclarity.com/blog/meet-the-retail-engineer
Every page of this site is available as markdown: append `.md` to its path. Index: /llms.txt
](https://cdn.sanity.io/images/xd4hrbt2/production/bd90c83632b56cf962cff520f4baa00c5eacb2f1-3200x2600.png?auto=format){kind=link}
](https://cdn.sanity.io/images/xd4hrbt2/production/b216566ad769d4f6d96e6853bcde1c7148e56490-3200x2600.png?auto=format){kind=link}
](https://cdn.sanity.io/images/xd4hrbt2/production/e104cff0f76b087dc6ef7139be5a4fcf2ca9a2e7-3200x2600.png?auto=format){kind=link}
](https://cdn.sanity.io/images/xd4hrbt2/production/de2a5b5c40346be29d339f23b666685f9ff12a29-3200x2200.png?auto=format){kind=link}
](https://cdn.sanity.io/images/xd4hrbt2/production/c57975409a419ade2b36bb09e9963bc489d37819-2048x1152.png?auto=format){kind=link}
](https://cdn.sanity.io/images/xd4hrbt2/production/b88cff1f0c12d8e049bdd680bacea87c086e3284-1600x1000.jpg?auto=format){kind=link}