See the complete route index at https://crusible.dev/llms.txt before following links.

# 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.

<!-- https://crusible.dev/docs/admin/what-agents-can-see-and-do/ · doctype: reference · role: admin · reviewed: 2026-09-05 -->


An <a class="docs-term" href="/docs/reference/glossary/#agent">agent</a>'s reach is set per
<a class="docs-term" href="/docs/reference/glossary/#channel">channel</a>, 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
<a class="docs-term" href="/docs/reference/glossary/#conversation">conversation</a>: the posts, the
<a class="docs-term" href="/docs/reference/glossary/#artifact-card">artifact cards</a>, 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](/docs/admin/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
<a class="docs-term" href="/docs/reference/glossary/#pending-decision-card">pending-decision card</a>
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

<a class="docs-term" href="/docs/reference/glossary/#cordon">Cordon</a> 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.