How We're Building the Command Centre: Multi-Agent Orchestration for Ecommerce

Most AI tools in ecommerce are single-purpose: a chatbot here, an ad optimizer there, a copywriter somewhere else. Each sees one slice of the business and optimizes in isolation, so the support bot does not know your ad performance, the email tool does not know your inventory, and the analytics dashboard triggers no actions at all.

The Command Centre is our answer to that fragmentation: a multi-agent orchestration system where specialist AI agents coordinate through a central orchestrator. This is the engineering approach behind it, the design decisions, the architecture and the trade-offs. What is live today is the free store audit; the autonomous platform is in active development, and this post describes how it is being built, not a finished product running stores.

Why a multi-agent architecture

A single monolithic model cannot effectively run an entire ecommerce business. The domains are too different: understanding ad attribution takes different skills than writing email copy or forecasting inventory demand. The system needs specialists, not one generalist.

The clearest analogy is a well-run team. A company has a marketing manager, an ad specialist, an email marketer, a support lead and an operations person. Each owns a domain, but they coordinate through a chief of staff who keeps everyone aligned. The architecture mirrors that: a team of specialist agents coordinated by an orchestrator that acts as the AI chief of staff.

Architecture overview

The system is designed in four layers.

1. Chat interface. Natural-language input from the seller, from a diagnostic question about why ROAS dropped to a request to draft a winback email for lapsed customers.
2. Orchestrator agent. It reads the request, decides which specialists are needed, builds an execution plan, and coordinates the work, decomposing complex queries into subtasks routed to multiple agents.
3. Specialist agents. Each has a focused domain, specialized prompts, domain-specific tools and access to the relevant data. Examples include ad performance, email campaigns, support resolution, inventory forecasting and financial analysis.
4. Execution layer. Background workers designed to carry out agent decisions, sending emails, adjusting bids, creating tickets, generating reports, with every action logged and reversible.

Model routing: balancing cost and quality

Not every task needs the most powerful model. A router selects the right tier by task complexity.

• Fast tier (Haiku-class). The routine majority of requests, on the order of 70%, for support replies, data extraction, classification and summaries, at the lowest cost.
• Balanced tier (Sonnet-class). Roughly a quarter of requests, for email copywriting, ad analysis and strategic recommendations, at moderate cost.
• Power tier (Opus-class). A small share, around 5%, for complex orchestration, multi-step planning and financial modeling, at the highest cost.

Routing most requests to the cheapest capable model is designed to cut AI cost by more than half versus running everything on the top tier. The insight behind it: most ecommerce tasks are pattern-matching, not open-ended reasoning.

Cross-agent coordination

The real leverage in a multi-agent system is not the individual agents, it is how they coordinate. The system is designed to run cross-function workflows like these.

• Inventory and ads. When the inventory agent detects low stock on a top seller, it tells the ad agent to ease spend on that product so it does not sell out mid-replenishment.
• Support and email. When the support agent sees a spike in "where is my order" tickets, it prompts the email agent to send proactive shipping-delay notices to affected customers.
• Analytics, ads and email. When the analytics agent detects a ROAS drop, it flags the ad agent to audit recent changes and the email agent to lift retention campaigns to offset weaker acquisition.

Reliability patterns

AI systems fail: models hallucinate, APIs time out, rate limits get hit. The design includes several reliability patterns.

1. Circuit breakers. If an agent fails repeatedly in a short window, the circuit opens and routes to a fallback, a simpler model or a cached response.
2. Idempotency. Every action carries a unique key, so a retry never sends a duplicate email or makes a duplicate ad change.
3. Rate limiting. Commerce-platform API calls are batched and queued with exponential backoff to avoid throttling.
4. Human in the loop. High-stakes actions, spend above a threshold or large customer sends, require human approval before execution.
5. Audit logging. Every decision, API call and action is logged with its reasoning chain, for debugging and accountability.

Design principles guiding the build

1. Start with the cheapest model that works. Routine tasks belong on the fast tier; reserve the powerful models for the small share of work that genuinely needs open-ended reasoning.
2. Agent boundaries matter more than agent count. Overlapping agents create errors. Clear domain boundaries with explicit handoff protocols keep the system predictable.
3. Prompt caching is essential at scale. Many ecommerce queries are near-duplicates, so caching system prompts and common queries is designed to cut both latency and cost as volume grows.
4. Background processing is the right default. Sellers rarely need instant ad adjustments; a short queue-based delay is more reliable than forcing everything to run synchronously.

The value is not in any single agent, it is in an orchestrator holding the whole store context and coordinating specialists under reliability and approval controls.

Key takeaways

• A multi-agent architecture mirrors a human team: specialist agents coordinated by an orchestrator.
• Tiered model routing is designed to cut AI cost sharply by sending routine work to cheaper models.
• Cross-agent coordination is what enables system-level intelligence that isolated tools cannot reach.
• Reliability patterns such as circuit breakers, idempotency and rate limiting are essential for production AI.
• Clear agent boundaries and explicit handoffs reduce errors more than simply adding more agents.

Frequently asked questions

Why not just use one large model for everything? A single model cannot hold deep expertise across a dozen business functions at once. Specialist agents with focused prompts and tools tend to outperform a generalist on domain tasks, and routing simple work to smaller models is far cheaper than running everything through the most capable one.

How do you prevent agents from making conflicting decisions? The orchestrator is designed to hold a shared context that all agents read. Before executing, an agent checks for conflicts, and high-stakes actions pass through a coordination step where the orchestrator resolves conflicts before anything runs.

What happens when the AI is wrong? Actions are designed to be logged, reversible and gated by guardrails. High-stakes actions require human approval, and the system is built to escalate to human review when confidence drops and to fall back to simpler automation rather than doing nothing.