How We Built the Command Centre: Engineering Multi-Agent Orchestration

Most AI tools in ecommerce are single-purpose: an AI chatbot here, an AI ad optimizer there, an AI copywriter somewhere else. Each tool sees one slice of your business and optimizes in isolation. The result is fragmented intelligence — your support bot does not know your ad performance, your email tool does not know your inventory levels, and your analytics dashboard does not trigger any actions.

We built StoreWiz to solve this. This is the engineering story behind our multi-agent orchestration system — how we designed it, what worked, what did not, and the architectural decisions that shaped the platform.

Why Multi-Agent Architecture?

A single monolithic AI model cannot effectively run an entire ecommerce business. The domains are too different — understanding ad attribution requires different skills than writing email copy or predicting inventory demand. We needed specialists, not a generalist.

Architecture Overview

The system has four layers:

1. 1.
   Chat Interface — Natural language input from the seller. “Why did ROAS drop this week?” or “Draft a winback email for customers who have not purchased in 60 days.”
2. 2.
   Orchestrator Agent — Analyzes the request, determines which specialist agents are needed, creates an execution plan, and coordinates the workflow. For complex queries, it decomposes the task into subtasks and routes them to multiple agents.
3. 3.
   Specialist Agents (29) — Each agent has a focused domain, specialized prompts, domain-specific tools, and access to relevant data. Examples: Ad Performance Agent, Email Campaign Agent, Support Resolution Agent, Inventory Forecast Agent, Financial Analyst Agent.
4. 4.
   Execution Layer — Background workers that execute agent decisions: sending emails, adjusting ad bids, creating support tickets, generating reports. All actions are logged and reversible.

Model Routing: Balancing Cost and Quality

Not every task needs the most powerful model. We built a ModelRouter that automatically selects the right model based on task complexity:

This routing strategy reduces our AI costs by approximately 60% compared to running everything on the most powerful model. The key insight: most ecommerce tasks are pattern-matching, not creative reasoning.

Cross-Agent Coordination

The real power of multi-agent systems is not in individual agents — it is in how they coordinate. Here are examples of cross-agent workflows:

• •Inventory + Ads: When the Inventory Agent detects low stock on a top seller, it notifies the Ad Agent to reduce spend on that product to avoid selling out during replenishment.
• •Support + Email: When the Support Agent sees a spike in “where is my order” tickets, it triggers the Email Agent to send proactive shipping delay notifications to affected customers.
• •Analytics + Ads + Email: When the Analytics Agent detects a ROAS drop, it alerts the Ad Agent to audit recent changes and the Email Agent to increase retention campaigns to offset lower new customer acquisition.

Reliability Patterns

AI systems fail. Models hallucinate, APIs time out, and rate limits get hit. We built several reliability patterns:

1. 1.Circuit breakers — If an agent fails 3 times in 5 minutes, the circuit opens and routes to a fallback (simpler model or cached response).
2. 2.Idempotency — Every action has a unique key. If a worker retries, it does not send duplicate emails or make duplicate ad changes.
3. 3.Rate limiting — Shopify API calls are rate-limited to prevent throttling. We batch and queue requests with exponential backoff.
4. 4.Human-in-the-loop — High-stakes actions (spending over a threshold, emailing more than 10K contacts) require human approval before execution.
5. 5.Audit logging — Every agent decision, API call, and action is logged with reasoning chains for debugging and accountability.

Lessons Learned

1. 1.
   Start with the cheapest model that works. We initially over-used expensive models. Moving 70% of requests to Haiku-class models cut costs dramatically with no quality impact on routine tasks.
2. 2.
   Agent boundaries matter more than agent count. Early versions had too many overlapping agents. Clear domain boundaries with explicit handoff protocols reduced errors significantly.
3. 3.
   Prompt caching is essential at scale. Many ecommerce queries are similar (“what is my ROAS this week?” vs. “show me this week's ROAS”). Caching system prompts and common queries reduced latency and cost by 40%.
4. 4.
   Background processing is the right pattern for most actions. Sellers do not need real-time ad adjustments. A 5-minute delay with a queue-based system is fine and far more reliable than trying to do everything synchronously.

Frequently Asked Questions

Why not just use one large AI model for everything?

A single model cannot maintain deep domain expertise across 10+ business functions simultaneously. Specialist agents with focused prompts and tools consistently outperform general-purpose models on domain-specific tasks. Additionally, routing simple tasks to smaller models is 10–20x cheaper than running everything through the most capable model.

How do you prevent agents from making conflicting decisions?

The orchestrator maintains a shared context layer that all agents can read. Before executing an action, agents check for conflicts (e.g., the Ad Agent checks inventory levels before scaling a campaign). Critical actions go through a coordination queue where the orchestrator resolves conflicts before approving execution.

What happens when the AI is wrong?

Every action is logged, reversible, and subject to guardrails. High-stakes actions require human approval. The system tracks accuracy over time and automatically escalates to human review when confidence scores drop below thresholds. We designed for graceful degradation — if an agent fails, the system falls back to simpler automation rather than doing nothing.