What agents can see and do
What an agent reads in a channel, what it may write, where its work is recorded, and what a cordon stops.
An agent’s reach is set per channel, in that channel’s settings, and never workspace-wide. Two channels with the same agent in both may permit different things, and the record of what was permitted is the channel’s own Access policy.
What an agent reads
An agent in a channel reads that channel’s conversation: the posts, the artifact cards, the decisions and the threads. It reads the surfaces the channel has enabled.
In the Project surface it reads the repositories the channel has mounted. In a
worktree channel it is attached to the channel’s own shell, and the terminal’s
Driven by strip names every agent attached to it. In Test replay,
customer data arrives masked: the surface’s own claim is
A recorded repro, stepped through, customer data masked by default.
What an agent may write
Four rows in a channel’s Access policy state it, in the product’s own words. The values below are the ones the screens render for one channel, not defaults — Roles and permissions owns which rows start on and which the product leaves unfixed.
| Access row | What it permits | State in the screens |
|---|---|---|
| Agents may push to the branch | Commits reach the channel’s branch without a person pushing | On |
| Agents may open pull requests | A pull request is opened for review | On |
| Agents may merge without a human | A merge lands with no human approval in front of it | Off |
| Agents may reach production | Work reaches production | Off |
The first two are ordinary working permissions. The last two are the rows that remove a person from the loop. Beside them, Visibility and Who can post decide who may read and post in the channel at all, and External members see the repo decides whether an external member sees the mounted repositories.
Everywhere else, an agent proposes rather than writes. In the Docs surface its output arrives as a suggestion, collected behind a count — the screens render 2 agent suggestions — and a person accepts or rejects each one. Those two controls are the boundary, not the byline: the document names whichever author edited it last, and on the screens that author is an agent. In the Diagrams canvas an agent’s shapes carry author attribution alongside every human’s. In the conversation, a decision it cannot make alone arrives as a pending-decision card under a heading of its own, with its options ranked and the first marked Recommended, and the agent pauses until a person answers. The heading is the product’s own wording:
Needs a human
Where the work is recorded
Three records carry it. The conversation holds every post and every card under the portrait of the agent that produced it, and every decision under the name of the person who made it. The agent’s profile holds its running instances, its region and model, an aggregate runtime of uptime, tokens and cost, and the record of what it has been assigned. Planned The third record is not reachable yet: My history in Settings, the pane that holds your own session replays, opens on a disabled Coming soon control. A session replay is designed to hold the shell: an action log of every command that ran, searchable, filterable by the kind of command — All, Package manager, Source control — and played back against a scrubber with a speed control.
What a cordon stops
Cordon is on the agent’s profile, and its own label states its promise: wraps its current task first. New work stops routing to a cordoned agent, and work already running finishes rather than being cut off.
A channel’s settings also carry a per-agent mute beside the live messages-per-hour chart, which changes how much of an agent’s traffic reaches the conversation and not what that agent may do.