Autonomous AI agents that handle specific retail operations end-to-end, replenishment, returns, catalogue updates, pricing, and supplier communication.
Built for retailers and brands that need agents completing operational tasks, not just surfacing data on a dashboard.
Inventory replenishment agents that monitor stock levels, calculate order quantities, and submit purchase orders to suppliers
Returns processing agents that classify returns by reason, apply resolution logic, and route exceptions to staff
Product catalogue enrichment agents that generate descriptions, classify products, and populate attribute fields from source data
Pricing optimisation agents that monitor competitive price signals and surface repricing recommendations within set boundaries
RaftLabs builds autonomous AI agents for retail workflows, inventory replenishment, returns processing, product catalogue enrichment, pricing optimisation, customer service, and supplier communication. Unlike static rules-based automation, these agents reason over inventory data, supplier lead times, and customer return patterns to take multi-step actions within defined guardrails. Most retail AI agent projects deliver in 10-14 weeks at a fixed cost.
Recognition
Your buying team triggering supplier purchase orders manually from spreadsheet reorder points that go stale the moment demand shifts?
Customer returns processed by staff for routine cases that follow the same resolution path every time and don't need human judgment?
Product catalogue updates blocked in a merchandising queue because data tasks are sitting alongside decisions that actually require a person?
Companies we've built for
A retail dashboard flags when stock drops below the reorder point. An AI agent calculates the replenishment quantity, generates the purchase order, and submits it to the supplier. The operational difference is that the alert still requires a person. The agent does not.
We build retail AI agents with defined scope, explicit escalation rules, and integration into the OMS, ERP, e-commerce platform, and supplier systems your team already works in. Each agent handles one workflow well rather than many workflows superficially. Integration scope is confirmed during discovery, because that is where the real complexity in retail operations tends to sit.
The agent monitors stock levels across locations (warehouse, store, or 3PL) by pulling current quantity-on-hand from the OMS or ERP on the configured polling interval, comparing it against the reorder points and safety stock levels defined in the product master, and calculating the replenishment quantity using the economic order quantity formula adjusted for the supplier's minimum order quantities and case-pack constraints.
When stock drops to the reorder point, the agent generates the purchase order with the line-level quantities, unit costs from the current supplier price list, and the target delivery date based on the supplier's lead time. The PO is submitted to the supplier via the configured channel, EDI 850 purchase order transaction for suppliers on EDI, supplier portal via browser automation for suppliers without API access, or email with structured PO attachment for smaller suppliers. PO confirmation is matched back to the original order when the supplier acknowledges, and the expected receipt is written to the ERP so warehouse staff can plan inbound receiving.
The agent applies your replenishment rules: suppression for end-of-season SKUs flagged for markdown, exclusion of SKUs with active overstock flags, and minimum value thresholds per supplier to avoid placing POs below the supplier's minimum order value. Exceptions, SKUs where the calculated order quantity is outside a configured range, new suppliers not yet validated in the system, or SKUs with multiple eligible suppliers requiring price comparison, are routed to the buying team with the supporting data already assembled.
Stateful workflow management using LangGraph models the replenishment process, stock check, quantity calculation, PO generation, supplier submission, confirmation matching, as a directed graph with explicit state transitions. Human-in-the-loop checkpoints are configurable: you can require buyer approval for all POs above a value threshold, for specific supplier accounts, or for seasonal categories during the transition periods when reorder logic needs manual oversight.
The agent processes inbound return requests against the return eligibility rules defined in your return policy: return window (days since purchase), product condition required for return, non-returnable categories (personalised items, perishables, digital goods), and any customer-segment-specific return terms (extended return window for loyalty members, for example). Eligibility is checked against the order record in the OMS using the order number and customer identifier from the return request.
For eligible returns following a predictable resolution pattern, the agent completes the return without staff involvement: it generates the return merchandise authorisation (RMA), sends the customer a prepaid return label via the configured carrier API, updates the OMS with the expected return, and queues the refund or store credit (per customer preference and policy) to process on confirmed receipt. Receipt confirmation triggers the inventory update (return to sellable stock or flag for inspection depending on the stated return reason) and releases the refund through the payment gateway integration.
Return reason classification uses the stated reason from the customer combined with order history signals. A return of "wrong item" matched against an order with a picker error flag in the warehouse system gets a different resolution path than "wrong item" on a correctly fulfilled order, the agent applies the resolution logic that matches the actual situation, not just the customer's stated reason. Returns with reasons that suggest product quality issues (broken on arrival, not as described for multiple SKUs in the same product, defective) are aggregated by the agent and surfaced to the buying team as a structured quality signal rather than appearing only as individual return records in the OMS.
Staff involvement is limited to genuine exceptions: high-value returns above a configurable threshold, returns from customers with a flagged return abuse pattern, returns of items in categories requiring physical inspection before restocking, and return requests that fall outside the eligibility rules but where the customer has requested manual review. The agent provides the resolution recommendation and all supporting data for these exceptions so the staff member can make a decision in seconds.
The agent generates and populates product catalogue data from the structured inputs available in your systems: supplier-provided product data sheets, product images, existing attribute data in the PIM or e-commerce platform, and category-level templates that define the required attributes for each product type. The enrichment tasks it handles, description writing, attribute classification, SEO title generation, and missing field population, are the data tasks that currently sit in a merchandising or catalogue management queue alongside the decisions that actually require a person.
Product descriptions are generated using structured prompts that include the product name, category, available attributes (material, dimensions, colour, care instructions, features), and the brand voice guidelines configured for the agent. The generated description is formatted to the template used by the e-commerce platform (character limits, HTML formatting, bullet point structure). A human review step is available for categories where brand voice consistency is critical or where the product requires specialist knowledge to describe accurately.
Attribute classification handles missing or incomplete attribute data. When a product is loaded with partial attribute information, the agent applies a classification model trained on the existing product catalog to infer likely attribute values, colour family from image analysis, size range from dimension data, material category from product description text. Inferred values are flagged as agent-generated so the merchandising team knows which fields to verify during catalogue QA rather than checking every field on every product.
HS code classification, product category mapping, and size normalisation (converting supplier size labelling to the platform's size taxonomy) are included in the enrichment scope. The agent processes new product uploads in the order they arrive, so the catalogue QA queue contains enriched records rather than blank shells waiting for manual data entry.
The agent monitors competitive price signals from configured sources, price tracking services, competitor website scraping via authorised data partners, or marketplace price feeds, and compares them against your current prices at the SKU level. Comparison applies your pricing strategy rules: target price position (match, beat by 5%, price to margin floor), competitor set (which competitors' prices count for which categories), and any SKUs excluded from competitive pricing (exclusive products, private label, price-sensitive categories with different strategy).
When a competitor price change moves a SKU outside the configured pricing bounds, the agent generates a repricing recommendation with the current price, the competitor price, the recommended new price, and the margin impact at the recommended price. Recommendations within the pre-approved price change range (for example, changes less than 10% and above the margin floor) can be set to auto-apply to the e-commerce platform via the pricing API. Recommendations outside the auto-apply range, or for SKUs flagged for manual pricing review, are routed to the pricing team with the full competitive context already assembled.
The agent tracks repricing history by SKU: every recommendation generated, every auto-applied change, and every manual decision. This accumulates the data the pricing team needs to evaluate whether the competitive pricing rules are producing the intended margin and volume outcomes, without requiring manual aggregation of price change logs. Repricing reports are generated on the configured schedule (daily or weekly) showing price change volume, margin impact, and competitor price movement by category.
Price changes are applied to the e-commerce platform via the product pricing API, Shopify Price Rules API, commercetools Price API, or the OMS pricing table depending on your platform. Platform-specific staging and publishing logic is handled in the integration layer, so the agent applies prices in the sequence the platform requires without the pricing team managing platform-specific publishing steps.
The agent handles the customer service contacts that follow predictable resolution paths: order status queries, delivery date confirmation, return initiation, store credit balance enquiry, and product availability questions. It retrieves the relevant data from the OMS, loyalty platform, and inventory system via the configured APIs and responds to the customer with accurate, current information, not a scripted answer that may be out of date.
Order status responses include the current shipment status pulled from the carrier tracking API, the estimated delivery date, and the carrier tracking link, not a generic "your order is on its way" message. When the order is in an exception state (delivery delay, customs hold, address correction pending), the agent includes the exception status and the action required from the customer if any. This means the customer gets a useful answer on the first contact rather than a holding response followed by a follow-up.
Return initiation via the customer service channel follows the same eligibility and resolution logic as the returns processing agent. The customer service agent applies the return policy, generates the RMA, and sends the return label in the same interaction, the customer does not need to be transferred to a returns team or complete a separate returns portal flow.
Escalation to a human agent happens for contacts that require judgment: complaints about damaged goods requiring compensation decisions above the agent's configured authority, customer relationship situations where the agent's structured resolution is technically correct but commercially inappropriate, and contacts where the customer explicitly requests a human. The escalating agent transfers the full conversation history and all retrieved order data to the human agent, so the staff member has the complete context and does not have to ask the customer to repeat information.
The agent manages structured communication with suppliers across the order lifecycle: PO acknowledgement follow-up when a supplier has not confirmed within the expected window, advance shipping notice (ASN) requests for inbound shipments approaching the expected delivery date, and delivery discrepancy notifications when the received quantity differs from the PO quantity.
PO acknowledgement follow-up sends structured reminder messages to the supplier contact on the configured schedule (24 hours and 48 hours after PO submission) when no acknowledgement has been received. The reminder includes the PO reference, line-level quantities, and the delivery date required. If no acknowledgement is received after two reminders, the PO is escalated to the buying team with the full follow-up history so they can make a commercial decision, hold the PO, contact the supplier account manager, or source from an alternative supplier.
ASN requests are sent to suppliers 3 business days before the expected delivery date for shipments where no ASN has been received. The agent includes the PO reference, expected line quantities, and the warehouse inbound booking instructions. Receipt of the ASN updates the ERP with the expected receipt details and schedules the inbound receiving appointment via the warehouse management system API.
Delivery discrepancy notifications are generated when the received quantity (from the WMS goods receipt record) differs from the PO quantity by more than the configured tolerance. The notification to the supplier includes the PO reference, the ordered quantity, the received quantity by line, and the credit memo amount. Supplier responses are matched to the open discrepancy record; unresolved discrepancies past the resolution window are escalated to accounts payable for deduction processing.
All supplier communication is logged against the relevant PO record in the ERP, giving the buying and accounts payable teams a complete audit trail of every supplier interaction without requiring manual notes in the system.
An e-commerce automation rule executes a predefined action when a trigger condition is met: if inventory drops below 10 units, send an email alert. The rule is fast and reliable but it only handles the exact condition it was written for. An AI agent reasons over variable inputs and takes multi-step actions: it checks stock across all locations, calculates the replenishment quantity accounting for supplier lead times and open POs, generates the purchase order to the right supplier at the right price, and submits it, all without a rule written for every SKU and supplier combination.
The difference matters most in workflows where the exception surface is large. A replenishment rule fires when stock hits the threshold. It cannot tell the difference between a SKU that is genuinely undersupplied and one that is in planned markdown clearance and should not be reordered. An agent applies that context if it is available in the system, a clearance flag in the product master, a markdown schedule in the pricing system, and suppresses the PO appropriately.
Returns processing is another clear example. A rule can close returns that meet every criterion automatically. It cannot classify a return reason that suggests a product quality issue and route it to the buying team as a quality signal. The agent applies the same eligibility logic as the rule, and additionally reasons over the return data to identify patterns that warrant a different action from a routine resolution.
We integrate with e-commerce platforms that expose management APIs. Shopify exposes the Admin REST API and GraphQL Admin API for orders, inventory, products, and pricing. Commercetools exposes a full REST API for all commerce objects. Salesforce Commerce Cloud exposes the OCAPI and SCAPI for order management, product, and inventory. BigCommerce, Magento 2 (Adobe Commerce), and WooCommerce all expose REST APIs for order and inventory management.
For ERP and OMS integration, we integrate with NetSuite (SuiteScript and REST Record API), SAP S/4HANA (OData APIs), Microsoft Dynamics 365 (Dataverse API), and standalone OMS platforms including Fluent Commerce and Manhattan Active Omni. Inventory management platforms (Brightpearl, Cin7, Linnworks) expose REST APIs for stock level and purchase order management.
For supplier communication, EDI integration using the standard retail transaction set (EDI 850 for purchase orders, EDI 856 for advance shipping notices, EDI 860 for PO change, EDI 810 for invoices) covers the majority of larger supplier relationships. For suppliers without EDI capability, email with structured attachments and supplier portal automation via browser-based integration are the fallback paths.
Integration scope is confirmed during discovery. The variance in what different platform configurations expose, particularly for inventory management and multi-location stock, is large enough to change the project scope. We scope integration explicitly so the estimate reflects your actual stack.
A focused retail AI agent, one workflow (for example, an inventory replenishment agent for one product category and one supplier set, or a returns processing agent for one sales channel), defined escalation logic, and standard platform integration, typically runs $20,000--$55,000 and delivers in 10--14 weeks. This includes the LangGraph workflow implementation, OMS and platform API integration, human-in-the-loop checkpoint UI, and the audit trail.
A multi-agent system covering inventory replenishment, returns processing, and catalogue enrichment with OMS write-back, supplier EDI integration, and a product pricing API connection typically runs $55,000--$120,000. The higher end applies when the supplier mix includes a large number of EDI trading partners requiring individual mapping, or when the catalogue enrichment scope includes image-based attribute classification requiring model training on your product data.
Cost is driven by the number of platform integrations, the supplier EDI scope, and the number of product categories the agent needs to handle. We scope and price every project before starting. The scoping document defines the workflow state machine, the integration points, the escalation logic, and the acceptance criteria so both sides know exactly what is being built.
Multi-location inventory replenishment requires the agent to reason over stock levels across all locations simultaneously, not just the central warehouse. The agent retrieves location-level quantity-on-hand from the OMS or inventory platform, applies the replenishment logic at the location level (each location has its own reorder point and safety stock), and generates POs directed to the appropriate supplier and delivery location.
For retailers with a distribution centre that supplies stores (rather than direct-to-store supplier delivery), the replenishment logic operates at two levels: the DC monitors stock at store level and generates internal transfer orders to replenish stores from DC stock, while separately monitoring DC stock and generating supplier POs to replenish the DC. The agent handles both levels with the appropriate lead times, store replenishment from DC is faster than DC replenishment from supplier, so the safety stock levels are set correctly for each location type.
Allocation logic for constrained supply situations (supplier can only partially fill the PO) is configurable: allocate by location sales velocity, allocate proportionally to reorder quantity, or allocate to the locations closest to stockout first. The agent applies the configured allocation rule and generates the adjusted transfer or receipt quantities with the rationale logged in the audit trail. Buying team review is triggered for constrained supply situations where the allocation decision has a material commercial impact.
What clients say
Three-year average engagement. Founders and operators describing the work in their own words. No marketing varnish.
IrelandRaftLabs was outstanding at addressing our complex platform needs, delivering a stable, high-performance loyalty application that has been genuinely loved by the customers.
Tell us the workflow you want to automate, your e-commerce platform, and your OMS. We will scope what an agent can handle and give you a fixed cost.