Case study: store stockout → inter-store transfer

This case study shows how a retail chain uses Odin to build several Managed Agents with clearly divided responsibilities, handling the kind of operational problem that requires reasoning across six systems: POS, WMS, ERP, e-commerce, suppliers and CRM. The data, Agents and governance gates in this case study are already built and published in a real demo project. They are not mockups.

Scenario

Sunday evening, POS end-of-day finishes running. 信義旗艦店 (Xinyi Flagship) has just 6 units of a co-branded vacuum flask left against a safety stock of 40, having sold 45 that day, nearly four times its usual velocity. The cause was an influencer unboxing video driving attention, compounded by a half-price-on-the-second-item promotion running on e-commerce. The distribution centre (DC) is down to 30 units as well, below its safety stock of 100, and standard replenishment lead time is 14 days. On the normal course of events the flagship store runs out by noon the next day, the shortage spreads across every channel, and a transfer order typically waits for the store manager to report on Monday and the operations team to meet, arriving two days later.

In this case study, four Managed Agents complete all the querying and analysis overnight: confirming the stockout risk, scanning inventory across every channel to find stores able to transfer, comparing standard against expedited purchasing, and quantifying how the promotion is drawing down stock. But the four actions that actually change system data (creating the transfer order, issuing the expedited purchase order, adjusting the promotion and replying to the store) all stop at a governance gate, waiting for the operations manager to approve them together the next morning.

The Agents involved

The project publishes five Managed Agents, each covering one stretch of reasoning or one system's write permission:

• 門市營運 Agent (store operations): detects store stockout risk, decomposes abnormal sales velocity into its components (influencer effect versus promotion uplift, for example), and assembles the handling plan for the store along with the impact on members.
• 跨店調撥 Agent (inter-store transfer): scans inventory across every channel, calculates how much each store can transfer without draining its own safety stock, and produces a transfer plan.
• 補貨採購 Agent (replenishment purchasing): compares lead time and cost between standard and expedited replenishment, and prepares the purchase order.
• 促銷分析 Agent (promotion analysis): quantifies how much stock the running promotion is pulling through, and simulates the change in velocity from adjusting the promotion rules.
• 商品洞察 Agent (product insight): handles analytical requests about markdown pricing for slow-moving stock (covered in a separate case study, ranking inventory coverage days).

Each Agent's Prompt states plainly that it is a tool-centric enterprise system operator rather than a general chat assistant. Its capability boundary is querying through database semantic models (read) plus changing data through system tools (write), and any write action first explains which figures it rests on, its scope of impact and its risks, then waits for governance-gate approval.

A closer look at one Managed Agent's configuration, using the inter-store transfer Agent

The inter-store transfer Agent's Prompt has four sections, each mapping to a real capability boundary rather than vague role-play text:

• Persona: you are a retail chain's inter-store transfer Agent (Enterprise System Agent), not a general chat assistant and not merely an analytical assistant that looks things up, but a tool-centric enterprise system operator that helps users complete whole operational tasks from query and analysis through to writing data into systems, using database semantic model queries (read) and system tools (write).
• Task: lists the core principles, stating plainly that the capability boundary is querying operational data through database semantic models (read) plus changing data in systems through system tools (write), and that anything it has no matching capability to do correctly must not be claimed as possible or faked in text.
• Context: enumerates the capabilities this Agent actually has, including read (querying store and distribution centre inventory and sales data through database semantic models) and write (creating inter-store transfer orders through system tools, after approval).
• Format: requires replies in Traditional Chinese as used in Taiwan, formatted in Markdown; the conclusion first (total transferable quantity) followed by each store's transferable quantity in priority order and arrival timing, with every figure traceable to its data source; and before any write action, an explanation of what is being changed and how, which figures it rests on, its scope of impact and its risks.

On-boarding Settings defines two Custom Sample Questions, shown below a new conversation box so users know how they might ask this Agent:

• 信義旗艦店那顆明天就要斷貨的聯名鈦保溫瓶（SKU-8801），哪些門市有多餘庫存可以調撥？各能撥多少？
• 在不掏空支援門市的前提下，最多能調撥多少件給缺貨的旗艦店？

Below that are the resources this Agent actually mounts. MCP Servers holds only the distribution centre write toolset, matching the single action it has permission to write (creating inter-store transfer orders). Skillsets holds inter-store transfer optimization, used to calculate transfer quantities. Semantic Model holds two, the POS store semantic model and the WMS distribution centre semantic model, each with independently switchable Allow Query and Allow Write, and an Allowed Cubes setting to restrict queries to specific tables (leaving it blank means everything is open). Both of this Agent's Semantic Models have only Allow Query enabled, with write actions left entirely to the Automation Tool covered in the governance gate section below, so the Agent never writes to the database through a semantic model.

The query side: seven Semantic Models

Each of the six systems (POS, WMS, ERP, e-commerce, suppliers, CRM) has a Semantic Model, plus one data warehouse (OLAP) semantic model for cross-system reporting queries, all published to Data Insight (Mimir). During the reasoning stage, Agents query these Semantic Models in natural language and never need to write SQL.

Governance gates: seven data-changing Automation Tools

Every action that actually writes to a system is built as an Automation Tool, defining its input parameter schema as a Workflow. The tool for creating an inter-store transfer order, for example, takes input parameters including the product SKU, the supporting (shipping) store code and the short (receiving) store code. The Agent can only raise a transfer request matching that schema, and submission still stops at an approval step.

The decision flow

The four Agents complete the following reasoning in sequence, ending in a single decision package:

1. The 門市營運 Agent scans POS end-of-day, finds 信義旗艦店 below safety stock with velocity far above baseline, judges the stockout risk to be extremely high, and raises an event.
2. The 門市營運 Agent decomposes the abnormal velocity into its components (baseline velocity plus influencer effect plus promotion uplift), and queries CRM to confirm how many members registered for restock notifications.
3. The 跨店調撥 Agent scans store inventory across every channel, identifies stores able to support a transfer without draining their own safety stock, and calculates the total transferable quantity and arrival timing.
4. The 補貨採購 Agent queries distribution centre inventory and in-transit purchase orders, comparing lead time, quantity thresholds and premium between standard and expedited replenishment.
5. The 促銷分析 Agent quantifies how fast the current promotion is drawing down online stock, assesses whether keeping it running would exhaust the transferred quantity early, and proposes adjustments.
6. The four Agents' conclusions come together as one decision package (transfer plan, expedited purchasing plan, promotion adjustment recommendation, explanation for the store), stopping at the governance gate for the operations manager to approve.

What this case study demonstrates

• One operational problem spanning six systems takes two days to coordinate a plan for by hand. Several Agents with clearly divided responsibilities can finish the reading and reasoning overnight.
• Queries go through Semantic Models (natural language into queries), so no Agent needs to know SQL or the underlying table structure.
• Every action that actually changes system data goes through an Automation Tool defined as a governance gate with an explicit input schema, and an Agent cannot bypass approval to write directly.
• Each Agent mounts only the Semantic Models, Skillsets and MCP Servers its responsibilities require, keeping permission boundaries clear.

The same retail demo project also holds a customer service scenario built on a Flow Agent, covered in AI customer service answering order enquiries in real time.

The same scenario can also be viewed from a Sindri user's perspective: how a business colleague asks a single question in the chat window, has Sindri delegate to the inter-store transfer Agent here, produces a plan and approves it at the governance gate. See Store stockout → inter-store transfer (user perspective).