Concepts
The agent
Loop's agent does the work: diagnose, segment, draft, ship, measure. You describe an outcome; it finds the cause, builds the segment, drafts the fix, proposes the experiment, and reports the lift. It never takes a step that reaches your users without a human saying yes first.
This page has no API on it, on purpose.
The agent's endpoints are not documented yet. Rather than print a shape that might be wrong, this page describes only what is structurally true of how the agent is allowed to behave. The API reference lands in the next round.
Colour names the actor
Across Loop (the console, the emails, these docs), clay means the agent acted and blue means you did. They never cross. A serif is the agent speaking; the sans you are reading now is interface chrome; mono is events, keys and queries. You should never have to ask who did something.
Clay: the agent acts
A drafted guide, a proposed segment, a diagnosis. Always a proposal until you approve it.
Blue: you act
Approve, edit, ship, stop. Every control that changes something for a real user is blue.
What holds it in place
- Human approval on anything user-facing. The agent can draft and propose all day. Sending, showing and shipping are approvals, not suggestions it can talk itself into.
- Guardrails live in code, not in the prompt. Consent, frequency caps and spend limits are enforced server-side on every request. A model that asks to bypass one is refused by the same code path as anything else.
- Every action is logged and replayable. A run records what it saw, what it decided and what it changed, so you can read back exactly why something shipped.
- Your event data is untrusted input. It is filtered and delimited before it reaches the agent's context, and it is never treated as instructions. An event name typed by one of your users cannot tell the agent what to do.
- Spend is capped per organization, with a cheap model for bulk work and a frontier model for reasoning.