Overview

The agent platform is a runtime for AI agents that perform business operations autonomously. It’s the substrate on which you build a fleet of specialized agents — for marketing, customer service, operations, technical work — that collaborate on real tasks with real consequences.

It’s not a chatbot. It’s not a “wrap GPT in an API” service. It’s the infrastructure underneath: how agents reason, what they know, what they’re allowed to do, how they hand off work to each other, and how the whole thing stays observable, debuggable, and safe in production.

The problem it solves

Today, the bottleneck for any business that runs a lot of repetitive operations isn’t ideas — it’s the labor of execution. A small e-commerce brand spends hours every week:

• Triaging customer refund requests one at a time
• Writing weekly performance reports by hand
• Updating product descriptions across hundreds of items
• Manually deciding who’s a VIP customer and who isn’t

A larger one — say, a brand doing ten thousand orders a day — hires teams to do this. Those teams do work that’s mostly procedural: read context, check records, apply policy, take action, write a summary. The kind of work an LLM can do well — if it has the right context, the right tools, and the right boundaries.

The agent platform is the thing that gives an LLM all three.

What you get

The platform provides four primitives. Build a business operation out of these and you have a working agent.

1. Agents

An agent is a YAML definition: who it is, what it can do, what constraints it operates under. One file per agent. Today there are three agents in the order-triage scenario (triage, refund_decision, communication) and one in the merchandising scenario. Adding another agent is editing a file.

2. Tools

Tools are the things an agent can do. Some are built into the platform (recall a memory, store a memory, emit an event). Some are business-specific (look up a Shopify order, draft a reply, make a refund). Each tool is a typed function with input validation and structured outputs — agents can’t break out of the toolset they’re given.

3. Memory

Each agent has up to six layers of context, in priority order: core (the immutable system prompt), characteristics (personality and decision style), shared context (read-only data from other agents), delegated context (per-task input from a parent agent), working memory (the current conversation), and long-term memory (persistent vector search). Long-term memory is what makes agents remember — a refund-decision agent knows about a customer’s prior refunds because it stored them, semantically searches for them when asked, and reasons over what it finds.

4. Events

When an agent decides something has to happen — escalate to a human, refund an order, update inventory — it emits an event. Events get queued and processed asynchronously. This is what keeps the platform safe: the agent never does the thing directly; it emits a structured intent that a separate handler (possibly with human approval) carries out.

Who it’s for

Engineers building automation for a business with significant operational volume. The platform is opinionated: it makes the hard architectural decisions (security boundary on context, delegation chain, memory subsystem, event bus) so you can focus on the business logic — what the agents do, not how they work mechanically.

Operators at businesses that want their team’s expertise encoded as something that runs without them. A senior customer- service rep’s judgment about when to refund and when to escalate isn’t a process you can write down as a flowchart. But you can encode it as an agent definition: tone, decision style, constraints, the kinds of memory it should consult, the kinds of events it should emit.

Investors and decision-makers evaluating the multi-agent category. The platform is designed to scale to tens or hundreds of agents per business; the order-triage scenario is one demo, not the product. The product is the substrate.

What’s NOT the platform

• It’s not a chatbot framework. (Use Anthropic’s or OpenAI’s APIs directly for that.)
• It’s not a workflow engine. (Use Temporal, n8n, or Cloudflare Workflows for that.)
• It’s not Shopify-specific. (E-commerce is the first vertical because of momentum; the platform itself is business-agnostic.)
• It’s not a UI. (UIs come later; today it’s an HTTP API plus a cron worker.)

Where to go next

• Core concepts — agents, tools, memory, events explained without code
• Tech section (commits 2–4) — code architecture, packages, ADRs, deployment topology
• Scenarios section (commits 5–7) — three concrete walkthroughs: order-triage, weekly merchandising, and a hypothetical B2B SaaS customer-success project that uses every platform feature