AI Agents in Production: How Three Registered Agents Execute Replenishment Suggestions

Why replenishment suits agent-assisted work

Replenishment is semi-structured knowledge work: the flow is stable (fetch → compute → adjust → order), but every step requires business context — which warehouse, which channel, how to tune coefficients during promotions. Pure automation breaks on context; pure manual work drowns in repetition. Agents fit the middle: business users drive a deterministic execution chain in natural language.

This article tears down the agent system currently live on the Qeasy smart replenishment platform. Everything below reflects shipped capability, not promises.

The four-layer pipeline the agents operate on

• A · Data detail: master data (warehouses, products, categories, suppliers, channels) plus business documents (purchase orders, sales orders, inbound/outbound, transfers), persisted under unified keys. The primary sources are 7 core Jikeyun open-platform APIs — erp.warehouse.get, erp.goodscate.get, erp.storage.goodslist, erp.vend.get, erp.sales.get, erp.purch.get, erp.stockquantity.get — supplemented by Excel adapters for manual ledgers.
• B · Fetch & process: declarative filtering, aggregation, time windows and multi-source in-transit merging, executed synchronously in a sandbox and returning dimension-aligned detail tables within 30 seconds.
• C · Compute: compute scripts consume layer-B output; fetch results are chunked into PENDING rows and fanned out through BullMQ at 500 rows per batch, with a 200k-row circuit breaker. Plans carry 6 states and rows 7 states (PENDING / DRAFT / ADJUSTED / EXCLUDED / CONFIRMED / ORDERED / FAILED).
• D · Plans & orders: parameters are saved as named plan templates; recomputation produces versioned batches with lineage. After row-level human adjustment (tune / exclude / confirm), suggestions split into replenishment orders by orderKey, with suggestion snapshots embedded for two-way traceability.

The three registered agents

• General assistant — master data, knowledge base and system capability queries; read-only tools, no writes.
• Fetch script engineer — atomic fetching via FetchScript; one business-language confirmation before a trial run.
• Compute script engineer — batch computation via ComputeScript plus plan templates; one confirmation before submitting a plan.

A hard rule governs all of them: every write action goes through the existing script + execution chain. Agents produce scripts and parameters; the sandbox and queues do the executing. That keeps the capability boundary auditable instead of handing an opaque model database access.

How the knowledge base grounds the agents

Retrieval combines vector + keyword hybrid recall, RRF fusion and MMR re-ranking over a 1536-dimension knowledge base holding replenishment rules, data calibers and historical plans. When an agent explains "why 200 units for this SKU", it cites the business's own rule documents rather than model speculation.

Three design lessons

1. Confirm upfront, not audit afterwards — a single business-language confirmation before trial runs and plan submissions beats retroactive log review.
2. Sandboxing and circuit breakers are what make agents shippable — dual-layer isolation (child_process + isolated-vm), read-only SQL, 200k-row breaker and 500-row batches bound the blast radius of mistakes.
3. Traceability before autonomy — every suggestion traces line by line to dimensions, raw variables, formulas and adjustments, with parentPlanId lineage on recomputation. Earn trust first, automate second.

The takeaway: in supply-chain scenarios, agent adoption hinges less on model strength than on deterministic execution chains, clear permission boundaries, and a human behind every write.