Skip to content

Scenarios

The Tech section explains how the platform is built; the Scenarios section answers a different question: what does it actually do?

Three scenarios, each illustrating a different piece of the platform’s surface:

Order triage is the platform’s flagship demonstration. It exercises every Phase 1 capability: multi-agent delegation (triage → refund_decision → communication), long-term memory (refund history per customer), custom tools (shopify_get_order_by_email), event emission (human_review, shopify_actions queues), and the YAML agent definition format. It runs end-to-end against real Cloudflare D1, Vectorize, queues, and Anthropic — verified in the end-to-end demo runbook.

Weekly merchandising is the platform’s first deployed automation. It’s deliberately simple — one agent, no delegation, no long-term memory, no event emission, no async coordination. Just an LLM, three read-only tools, and a Markdown report. This is what shipping looks like at the start; complexity gets added when scenarios demand it, not before.

The B2B SaaS hypothetical exists to make the two-layer architecture claim concrete. The platform isn’t an “e-commerce agent platform” — it’s a general agent platform whose first business pack happens to be e-commerce. The hypothetical demonstrates what a different business pack would look like: three agents, two custom tools, two event topics, all expressible as YAML + Markdown prompts on the same Platform Core.

Each scenario page follows the same shape:

  • The setup — what’s the business problem, what triggers it
  • The agents — what each agent’s role is, what it can do
  • The flow — step-by-step walkthrough of a real example
  • The artifacts — the actual YAML files and prompts (real for order-triage and merchandising; mock for the B2B SaaS hypothetical)
  • What this demonstrates — which platform features are exercised and how

The artifacts are the most important part. Everything else flows from them; if you only read one section per scenario, read that one.