# Meet the Retail Engineer > The Retail Engineer is the role CommerceClarity is introducing for retail operations in the agent era: one person, half retail consultant and half engineer, who owns a customer outcome end to end. The work runs on the DIPE method (Design, Implement, Prove, Evolve) and signs two numbers with the customer: a business KPI and an eval score on an evaluation set. Most people who fit come from 3 to 6 years in solution or business consulting. CommerceClarity is hiring Retail Engineers in Milan and London. A new title for retail operations: what the Retail Engineer is, how the work runs on DIPE, and why one person owns the outcome end to end. **Published at:** 2026-08-23T17:00:00Z A sporting goods retailer publishes 200 product pages a week. The number we signed says 400, sustained for 8 weeks, with every mandatory attribute filled. The AI agent already writes correct pages, and we can prove it: 96% correctness on an evaluation set of hand-worked examples built with the customer. Getting from 200 to 400 on the live catalog, without that 96% slipping, is a different job. In most companies it is nobody’s job. At CommerceClarity it has a name: the Retail Engineer. This post explains what the role is, why it did not exist 3 years ago, and what makes it hard. ![The Retail Engineer sits where retail consulting meets coding with AI, built on the CommerceClarity platform](https://cdn.sanity.io/images/xd4hrbt2/production/b216566ad769d4f6d96e6853bcde1c7148e56490-3200x2600.png) ## A job that did not exist three years ago Every technology era creates its own engineers. The growth era produced the growth engineer, the marketing engineer and the go-to-market engineer, people who understood the funnel and could write the code that ran it. Enterprise AI produced the forward deployed engineer. None of these was a rename. They exist because splitting the person who understands the process from the person who builds it stopped paying for itself. The agent era creates the next one, and at CommerceClarity we are introducing it: the Retail Engineer, the engineer of retail operations. One person who sits with the retailer to understand how their operations actually run, defines the KPIs that count as success, designs the agent setup, writes the prompts and the code, integrates with their systems, and owns the run. Half retail consultant, half engineer, fully accountable for the outcome. Today the work starts from the catalog, because [the catalog is where retail processes connect](/solutions/catalog-foundation): assortment, pricing, content and channels all pass through the product record. It is one room in a very large house, and the room everything else runs through. The role is built for the house. Why retail? Because retail is where we come from. We have spent our careers inside it, building retail companies and scaling retail operations, and we know its gap from the inside: the industry is full of people who understand the business, full of engineers, and almost empty of people who can hear a business need and implement it themselves. Retail operations needs exactly that person now. And there is a second reason. We believe AI agents will deliver results on their own, and [on our customers they already do](/customers). We also believe the technology is at the start of its curve. This is the internet in 1995: real, working, and still growing into what it will become. Inside a complex enterprise, AI alone does not reach all the value yet, because the processes are more human than people think: exceptions, approvals, knowledge that lives in someone’s head. So right now the result takes a person who walks the transformation with the customer, until the agents run in production end to end and carry the numbers on their own. That is the Retail Engineer. ## The triangle For 30 years enterprise software was sold as a triangle. The customer sat at the top. Down one side ran service: the consultancy, the integrator, the people you paid to make the thing fit your business. Down the other side ran software: the vendor, the license, the roadmap owned by someone else. It worked as long as nothing broke. Software being software, something always broke. Service explained, with regret, that the problem lived in the product. Software explained, with equal regret, that the problem lived in the implementation. Both were a little bit right, which is the most dangerous kind of right, because it meant no one was wrong enough to have to fix it. Every project had a name for the space between what the business wanted and what the software did. It was called not my scope. It is where deadlines slipped, and where pilots sat for a year after the applause. ![The enterprise software triangle, with the gap between service and software labelled not my scope](https://cdn.sanity.io/images/xd4hrbt2/production/bd90c83632b56cf962cff520f4baa00c5eacb2f1-3200x2600.png) The Retail Engineer collapses the triangle into a point. One person who hears the goal in the customer’s own words on the first call, tunes the agent to their operation, writes the code where the product runs out of road, proves the result against the customer’s own standard, and stays. One line of accountability, from the business goal down to the line of code and back up. ## Why now The triangle was a rational answer to a real constraint. Bending a product to one retailer’s operations was slow, manual, expensive work. So you bought a rigid product and hired an army to wrap it. Two things changed at once. AI made the software adaptable: the same agent points at a new retailer and a new goal, and takes its shape in days where it took quarters. And AI made custom code cheap and safe to write: the script that bends the product to one customer’s reality, once specialist work with a 6 week test cycle, is now a prompt, a test and an eval. When adaptation shrinks from an army to [one person working on a platform](/platform), the role takes a new shape. Ours is the Retail Engineer. ## How the work runs Every engagement runs on the same method. We call it DIPE: Design, Implement, Prove, Evolve. ![The DIPE loop: Design, Implement, Prove, Evolve, with the eval running around the whole cycle](https://cdn.sanity.io/images/xd4hrbt2/production/e104cff0f76b087dc6ef7139be5a4fcf2ca9a2e7-3200x2600.png) Design is where we earn the right to build. We fix two numbers with the customer before any agent exists. The KPI says whether the business got enough: pages published, attributes filled, time to market, cost per product, measured on the real catalog. [The eval says whether the work is right](/platform/governance): a correctness percentage on an evaluation set of hand-worked examples, scored against the customer’s own rules. One never stands in for the other. An agent that ships fast but [breaks a brand rule or a regulatory rule](/solutions/compliance-quality) is worse than no agent at all. ![Two cards: the KPI, 400 product pages a week, and the eval, 96% correct on the evaluation set](https://cdn.sanity.io/images/xd4hrbt2/production/de2a5b5c40346be29d339f23b666685f9ff12a29-3200x2200.png) Implement is the build, on the customer’s real data, with the eval on at every change. We rerun it on every prompt and every configuration change, and iterate until the agent clears the agreed threshold. Never by feel. Prove is the phase that gives the method its spine. [The agent works the whole catalog](/platform/gridview), we move the KPI from its starting value to the signed target, and the eval keeps running as a safety net so we never buy volume by letting correctness slip. Then we show the customer the numbers. Not a demo, the numbers. Evolve never stops. An AI agent degrades on its own: new products arrive, categories move, the data drifts. We rerun the evaluation set every month, track correctness over time, and retrain when the score falls. When a new goal shows up it becomes a new agent, and the loop starts again at Design. ## The hard parts Three questions follow a Retail Engineer through every engagement. ### How do I know the agent is right? A language model is not deterministic, and a retail catalog is close to an unbounded input: tens of thousands of SKUs, dozens of categories, each with its own rules. You cannot check the output by reading it, and you cannot tune by feel. The answer is the eval, built with the customer before the build starts and rerun on every change. And an evaluation set never transfers. What counts as correct for a pet retailer is wrong for a pharmacy, so every customer owns their own. ![The CommerceClarity grid view over a retailer’s catalog, rows flagged for review and an issue note giving the reason a description was rejected](https://cdn.sanity.io/images/xd4hrbt2/production/656b5b1857404166861df58c97f4aa03287dc5c2-2880x1920.jpg) ### How does the data get in, and how does the result get out? This is the unglamorous half of the craft, and it decides everything. Product data arrives as supplier feeds, ERP exports, spreadsheets and half filled PIM records. The result has to land in whatever the customer runs: [a PIM, a CMS, a marketplace](/solutions/channels-markets), an ERP that wants its own XML. A correct product page the customer’s system cannot read is useless. So we study [import, attribute configuration and export](/platform/context) obsessively, before signing, because a broken import is a no-go before agents are even worth discussing. ### How do I keep it right in month six? Shipping is the start. Catalogs move: new suppliers, new categories, a marketplace that changes its requirements. The correctness you proved in month one erodes quietly if nobody watches it. So the evaluation set runs every month, the customer gets a report carrying both numbers, business KPIs and eval score, and when the score drops we retrain before anyone downstream notices. ## What the work feels like A morning can be discovery with a merchandising team, hearing in their own words why a product launch takes 3 weeks. The afternoon is prompts, taxonomy and a Python script where the product runs out of road, with an AI coding assistant turning what used to be a sprint into a prompt and a test. The consulting half you were already good at stays: the room full of stakeholders, the account that trusts you because you are the one who heard what they actually meant. What you gain is the other half. You build the thing yourself, the same week, in front of the customer, and when a number moves you go and change whatever produced it. There is one more thing. [We run our own company on agents](/blog/ai-native-company-three-layers), internal operations included, so a Retail Engineer here learns agent engineering by living inside it every day. It is a faster education than anything you could sign up for. ![Two people at work over a laptop, caught mid-motion](https://cdn.sanity.io/images/xd4hrbt2/production/c57975409a419ade2b36bb09e9963bc489d37819-2048x1152.png) ## Who becomes a Retail Engineer Most of the people who fit have spent 3 to 6 years in solution consulting or business consulting at a retail software vendor or a consultancy. They read business processes for a living, they own the customer, and almost all of them have a technical side they were never given room to use. The configuration screen ended exactly where the interesting part started, and everything past it went to a development team on another continent. Here nothing goes to another continent. The person who designs the workflow is the person who builds it. And you do not need to arrive as a software engineer. That is what the platform is for. We build it so that [agents are designed, changed and run in one place](/platform/agents), AI coding assistants write the code alongside you, and the eval proves every change before it ships. You bring the judgment: reading a business process and hearing what the customer actually means. The engineering weight sits on the platform, and the craft grows on the job. And inside every large retailer there is already someone doing a version of this job without the name: the person who holds the business and the systems together, who talks to merchants in the morning and engineers in the afternoon. A Retail Engineer who does not yet know they are one. ## The name comes before the noise Every discipline that matters was named before the market was ready for it. DevOps was a word before it was a job. Growth was a word before it was a team. Retail operations is next, and we are naming the person who runs it on agents. We are writing the playbook and building the platform they build on. If this sounds like the job you have been doing without a name, or the one you want next, we are hiring Retail Engineers in [Milan](/careers/retail-engineer-italy) and [London](/careers/retail-engineer-uk). ![Somebody climbing a flight of concrete steps marked with yellow nosings, caught mid-stride.](https://cdn.sanity.io/images/xd4hrbt2/production/b88cff1f0c12d8e049bdd680bacea87c086e3284-1600x1000.jpg) ## Author [Daniele Vella](/author/daniele-vella) · Co-founder, CommerceClarity ## Sources - [Meet the AI agent engineer](https://sierra.ai/blog/meet-the-ai-agent-engineer) · Sierra - [Forward Deployed Engineers](https://www.latent.space/p/forward-deployed-engineers-aiewf) · Latent Space - [From LAER to DARE: Why the AI Era Demands a New Customer Engagement Model](https://www.tsia.com/blog/laer-to-dare-ai-new-customer-engagement-model) · TSIA - [Services: The New Software](https://sequoiacap.com/article/services-the-new-software/) · Sequoia Capital --- 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