Seller War Room

What it does

Seller War Room audits a marketplace seller's store (Ozon, Wildberries and Yandex Market) for money leaks: prices below the target margin, ads still running on out-of-stock items, ad spend far above the target DRR, overstock paying storage, returns, and late-shipment penalties. Three analyst agents audit the three marketplaces at the same time and post findings to a shared board. A Critic agent recomputes every number from the raw export before it reaches the report. Wrong numbers are rejected and sent back for one retry, and duplicate posts are blocked by an interception gate. The output is a ranked list of verified leaks in ₽, each with a concrete fix, plus a full trace: per-agent loops, tool calls, tokens, cost and a timeline. The LLMs decide what counts as a leak and what to do about it; a deterministic engine checks every ₽. It runs with no API key in mock mode (`npm install && npm run demo`) or with a real LLM through OpenRouter (`npm run demo:live`, about $0.03 per run). The demo uses a synthetic shop with 6 planted leaks, and `npm test` checks that all of them are found and verified.

How the agents run concurrently

Everything runs in one Mozaik runtime (`defineRuntime<WarRoomState>()`). A custom RuntimeState is the shared board. The Operator (a human participant) publishes one `audit.requested` event. The three analyst agents' SituationSpecification handlers all react to it, and each starts its own `runLoop` with a fresh ModelContext, so the three loops run in parallel against the same state. Every `post_finding` tool call adds to the shared board and publishes `finding.posted`. The Critic reacts to each of these events with a separate loop, so several verifications run in parallel while the analysts are still working. In the sample mock run, 3 analyst loops overlap with up to 9 Critic loops at once, giving about ×5 agent-time parallelism over a 7.5 s wall time. The Critic's `finding.rejected` event triggers a retry loop in the authoring analyst. A FindingGate InterceptionHandler blocks invalid or duplicate `post_finding` calls before execution and redirects the agent with a `GATE:` message. A Trace Observer participant listens to the runtime events (inference.completed, function_call.started, model.answer) to track each agent, and it detects when the board has settled: every finding is verified or rejected and no loop is still running. Agents never call each other. They coordinate only through events and the shared state.