Everything in the API reduces to four concepts. Read these and the reference will feel obvious instead of arbitrary.
[ 01 ]Y0 — where runs happen
The runtime is the execution engine. You give it a run — a prompt, optional context, a model, and a hard ceiling on steps — and it plans, executes, and returns a result with a complete trace. Two models exist today: y0-fast for low-latency shallow plans, y0-deep for multi-step reasoning.
Two properties matter more than the feature list. Runs are bounded: max_steps is enforced, so a run cannot wander or rack up unbounded cost. And runs are inspectable: every plan, fetch, and step is recorded in a replayable trace. If you cannot see why a run did something, that is a bug in our product, not a mystery in yours.
[ 02 ]memory — so you never re-explain yourself
The context graph is the memory layer: documents, calendar events, tasks, and finance signals indexed into one graph a run can draw on. When a run asks to 'prepare Thursday', the graph is what knows Thursday has a client deadline, an unpaid invoice, and a half-finished draft attached to it.
Context is attached per run, not ambient. A run sees only the context sources you name in the request — calendar, documents, finance — and each fetch is recorded in the trace with the item count and the scope used. The graph compounds: the longer you use the product, the less you have to say to get the right thing done.
[ 03 ]permissions — small enough to reason about
Between every run and your context sits the trust kernel. It is deliberately small: scopes in, allow-or-deny out, audit line written. A scope is a named permission — calendar:read, documents:read, finance:read — and a run can only touch context its scopes allow.
The kernel is why traces can be honest. Every context fetch in a trace names the scope that authorized it, and every access lands in an audit log whether the run succeeded or not. We treat trust as load-bearing infrastructure, not a settings page: if the kernel cannot verify an access, the access does not happen.
[ 04 ]sequence — why the API is this small
The product map has eight lanes — intelligence, work, communication, finance, and onward — and they are entered strictly in sequence. Y0 and this API live in the first lane. The next lane opens when this one proves retention, not when a roadmap slide says so.
This is why the API surface is small and stays small: one resource done thoroughly beats eight done plausibly. If you are wondering where some endpoint is — billing automation, messaging, scheduling — the honest answer is usually 'a later lane'. The sequence is the strategy, and the API is the sequence made concrete.
[ 05 ]Apply it
Concepts are cheap until you run one. The reference shows the exact shapes.