Agents

This is the docs page for agents as they work. For the argument behind the design, see the product page; for the tools an agent actually calls, see MCP.

Creating one

A workspace admin creates an agent in workspace settings. What it needs is a handle - the name it is mentioned by - and a description of what it is for. Everything else has a default worth keeping until it does not:

What an agent may do

Every agent gets a token carrying eleven capabilities, and the list is written out rather than derived from anything:

code:read      issues:read    issues:write
pulls:read     pulls:write    docs:read
docs:write     chat:read      chat:write
runs:read      tasks:read

What is missing is the point. An agent cannot push - there is no code:write in that list, and there is no tool that writes a commit out of nowhere. It reads code, opens pull requests from branches that exist, comments on lines, and commits a suggestion somebody can read before it lands. It cannot create repositories, read or rotate CI secrets, or cut releases.

tasks:read is there so an agent can look up what was concluded last time. The workspace is its memory, through the same search everybody else uses, rather than a private store nobody can audit.

How work reaches an agent

Delegating is the obvious one, and it is not the only one. A task can start from any of these, and the record says which:

Assigning an issue to an agent stands even when the workspace is over its token budget. The assignment is a statement about who owns the issue; only the work it would have spawned is refused.

The task

A task is the unit of agent work and the whole record of it. Every turn is a step - the message, each tool call and its result, each proposal, and anything a person said in the middle.

running  ->  awaiting_review  ->  approved  ->  done
         ->  failed
         ->  cancelled

awaiting_review is where the product's central claim lives: the agent has done what it can and is asking. Approving lets it continue; rejecting sends it back with what was wrong. cancelled is a person stopping it mid-run, which is terminal and is not a failure.

You can talk to a task while it is running, and after it has finished. A correction lands in the step log in the order it was said, so the agent rebuilds the conversation including your interruption rather than treating it as the preamble to a second task that knows nothing.

The gate

Three tools stop for a human no matter what the agent's token says, because none of them can be undone by doing the opposite: pull_merge, doc_publish and canvas_share. The agent turns the call into a proposal and waits.

The check lives in the tool layer that both runtimes pass through, so it binds a hosted agent and an external one identically - a rule an agent can get around by being asked in chat instead is not a rule.

An agent can be granted standing permission for one of the three from its config. It is off by default, has to be acknowledged when turned on, and is written to the audit log with the person who granted it.

Memory

When you correct an agent mid-task - "don't touch the vendored files" - that correction is gone by the next task unless somebody keeps it. A memory is that gesture made one click: the line is promoted to a standing instruction, kept with who said it and which task it was said in, and read back in the prompt from then on.

Nothing is inferred. An agent that quietly learns is acting on a belief nobody wrote down and nobody can review, which is the opposite of what the gate exists to give. A person decides what is worth remembering, anybody can read the list, and anybody can delete a line from it.

Watches and schedules

A watch is an agent reacting to the workspace without being asked. There are two: CI, where a failed run becomes a diagnosis and a suggested fix, and docs, where a push becomes a draft of the page it made stale.

A schedule is standing work on a calendar - a triage sweep every morning, a weekly digest. Any member may create one; changing or deleting somebody else's is an admin's call, the same line approve and reject are drawn along.

Hosted and external runtimes

A hosted agent runs on our infrastructure and our inference, and there is nothing to operate.

An external agent is the same member of the workspace, driven by your own harness - your Claude, your prompt loop, your inference bill. Your runtime holds the agent's token, takes the task, writes what it did, says what it spent, and finishes. It gets no credential of ours, it can only ever see the task it was given, and it cannot approve or reject - an agent that could approve its own proposal is not a gated agent.

An external agent's config shows when its runtime last asked for work. There is no staleness threshold: a runtime that polls hourly is not broken, and we have no way to know what cadence you intended, so the time is shown and you judge.

Bring your own key

A workspace can hold its own LLM credentials - Anthropic, OpenAI, or OpenRouter - and point an agent at one. Keys go in sealed and never come back out; a list shows the last four characters, which is enough to tell two apart.

What that buys is not a discount, it is a different relationship to the meter. Work on your key is counted and never gated, because those tokens were never ours to ration. Work on the platform key is governed by the workspace's monthly cap. The two live side by side, per agent.

From the terminal

$ rezee agent list
$ rezee task create reviewer "review the auth refactor"
$ rezee task list --state awaiting_review
$ rezee task view <id>
$ rezee task watch
$ rezee task approve <id>
$ rezee task reject <id>

The prompt can come from arguments, from --prompt, or from stdin - so a diff pipes straight in:

$ git diff | rezee task create reviewer --prompt "review this change"

rezee task watch exits 0 when the task ended well and 5 when it failed.