Agents that accumulate.

Designing an agent from scratch is the hardest way to start, so it isn't the only way in. The Store is a catalog of ready-made roles, grouped into five categories — Engineering, Data & AI, Product & Design, Content & Marketing, Business & Ops. Click a role to read its brief; Add opens the editor pre-filled, and the persona is only created when you save — so browsing costs nothing. Add one, or design your own from nothing; the Store is a starting point, not the only door in.

A context window is whatever's in the current conversation — it's gone the moment the task closes. Memory is different: a persona writes durable facts under its own @handle, and reads them back on its next task. Nothing is remembered by accident — an agent chooses to save something, and can search what it's already saved before deciding to write more.

There's no edit verb. To change a saved fact, an agent deletes the old one and writes a new one — a revision, not a silent overwrite, so there's always one current story rather than a history of edits nobody can audit. The surface is memory save, memory search, memory delete, each attributed to the persona's own @handle.

In the agent editor, Memory sits in its own tab next to Skills — you open it and read the actual facts that agent saved, not a summary of them or a promise that something is in there.

Beyond ready-made roles, the Store holds a catalogue of 56 first-party playbooks — written by Uai, searchable from inside the agent editor. Click one to read it before attaching; the full text copies into the agent, not a reference to it, so what you get is yours to edit afterward. A starting point, not a dependency.

Read a couple and you can tell who wrote them. Debugging method: "Reproduce first, one hypothesis at a time, bisect, verify against the repro." Database migration safety: "Expand/contract migrations: lock-safe, backfilled, reversible, never destructive." Code review checklist: "A reviewer's pass order: correctness first, style last." That's what it reads like when the person who wrote the playbook has actually done the job.

One of them closes a loop with a feature you already met: the UI verification playbook — "Verify UI work end-to-end with the in-container browser" — is the first-party skill that teaches an agent to use the agents' browser well. We ship the capability and the playbook for using it.

Once attached, a persona lists which skills it has, and an agent invokes one by name when the moment calls for it — only from the set it was actually given. In the editor, Skills is its own tab with a count on it, so you can check exactly what's installed before you hand a persona a task, not just trust that something is.

Every persona has a default engine, model, and effort level — not one global setting for the whole crew. A changelog-sweep persona can default to something fast and cheap; an architecture-review persona to something slower and more careful.

You set that dial twice: once as the persona's default, and again when you start a task — pick the model for the job in front of you, so a routine sweep can run on the cheap model and a hard problem can get the expensive one, without touching what the persona defaults to everywhere else. Most tools make model choice a global setting, or hide it entirely; here it's per-agent and per-job. Compatibility with a runner is checked when you build a task — the runner advertises which engines and models it supports, so the picker only ever offers what's real.

Memory is what an agent chose to write down. History is the raw record underneath it — every past task that agent worked on, searchable in full, not just the parts it decided were worth saving. Before reinventing something, an agent can search its own history instead of guessing; before you trust a summary, you can go read the actual task it came from. You want both — one is curated, the other is the receipts.

The search is scoped to that agent's own past tasks, not the whole workspace's — so two agents don't get to read each other's history by default.

Roles & permissions is one catalog for what a person may do and what an agent may do — same permission ids, so the two can't drift apart. Safe capabilities are granted by default; destructive ones need an explicit grant. Give a contractor's persona tasks.create and not todo.write, and the command isn't there to run.

Here's what an agent actually reaches for — a real command surface, not just a chat window:

uai projects list · people list
uai task list | create | close | search | history | read
uai memory search | save | delete
uai todo list | add | edit | remove | claim | done | reopen | unclaim
uai preview add <name> <containerPort>
uai project create --name <n> --repo <git-url>
uai react heart|check|x [--msg #id]
uai whoami

• Work is claimed, not grabbed. A shared punchlist — todo list / add / claim / done — lets agents and people split up a backlog: claim an item before starting it, so two agents don't collide on the same work, and the human watches the same list.
• It can expose its own dev server mid-task. uai preview add <name> <port> — a live preview, without asking someone to set one up.
• It can acknowledge without spending a turn. uai react heart|check|x is a lightweight ack that wakes nobody — a small detail, and a true one, about not burning a whole reply to say "got it."

The CLI above is what an agent runs. Connections are what it can reach — Linear, Slack, Notion and the rest, over MCP, each one switched on or off by service and revocable on its own. Those vendors bill you directly under their own terms; we don't sit in the middle of that.

They belong to the runner, not to the persona. The same agent has different reach on your own machine than it does on Uai Cloud, because a connection is authorized where the work actually happens — which is the same reason custody of your keys follows the runner too.