The product is a team of AI agents that operate a business. This page covers how an agent run works, how agents act on the outside world, and the safety gate that sits in front of anything risky.
An agent is a purpose-scoped worker — a strategist, a site builder, a support responder, a billing handler, an operations watcher, and so on. Each agent has a role, a model routing policy, and a set of tools (connectors, internal APIs) it's allowed to use. Agents read shared context and produce actions and deliverables.
Support and operations are context-first, not a self-service funnel. A shared journey ledger is the spine: an anonymous visitor's journey is captured, then stitched to their identity on login, and handed to agents as machine-readable context. An agent answering a customer already knows what that customer did, saw, and asked — it isn't starting cold.
Agents don't reach out to the world ad-hoc. Effects flow through an action queue:
This indirection is what makes agent behavior auditable and reversible-ish: every external effect is a recorded queue item, not an invisible side effect.
Any action that touches money or the outside world in a high-risk way carries
requires_approval. Those actions wait in the queue until the owner
approves them. Low-risk reads and routine actions flow through; refunds, sends,
and destructive writes pause for a human.
Each connector's capability manifest declares, per operation, its risk level and whether it needs approval — so the gate is data-driven, not hardcoded per agent. You can see this directly on any connector page.
Agents don't all use one model. A routing layer chooses a model per purpose (with override hooks and a budget meter), so cheap/fast work and high-stakes reasoning land on appropriately-sized models, and paid-tier budget is metered and capped.
Agent execution that spends paid model budget is never exposed over unauthenticated HTTP. The free intake phase runs on free-tier providers; paid build/run execution is gated behind payment (enforced by the Stripe webhook) and behind a fail-closed internal key plus an agent allowlist. In short: you can't trigger a paid agent run by curling an endpoint.
While the platform is pre-revenue, agent runs are largely test runs. Agents are not retired or penalized on success-rate or run-count; the policy is to fix agents, not cull them. This is an operational stance, not a code constraint — worth knowing if you're reading run metrics.