Canopy

Canopy is the universal Xema agent: one conversation, scoped to your organization, that can reach every capability of every installed biome. You describe a goal in plain language. Canopy finds the capabilities that fit, checks that it may run them, and runs them for you.

Canopy ships as a base biome. It is a conversation host and tool broker, not a data store: the capability catalogue, your conversations and your files live in the services that already own them.

---

Conversations and threads

A Canopy conversation belongs to the person who started it. Nobody else in the organization can list or open it, and asking for someone else's conversation gets the same "not found" answer as asking for one that does not exist.

• You can have several threads at once; there is no fixed cap.
• Opening Canopy again resumes your most recent conversation. Starting a new conversation is an explicit act.
• A conversation begins organization-wide. You can point it at a project, or return it to organization-wide, without losing the transcript.
• Answers stream as they are produced. The same turn is also written to a durable session ledger, so a client that disconnects can reconnect and continue from where it stopped.

---

Two tiers

Escalating a thread from Tier A to Tier B needs a project context, because a workspace cannot exist without a project. When you escalate, you give a reason, and Canopy narrates it into the conversation before anything is provisioned. The deep session's events are then relayed into the same conversation, so it still reads as one thread. The relay remembers its position, so disconnecting and reconnecting neither repeats nor drops an event. You can return a thread to Tier A at any time; the conversation continues.

---

Reaching capabilities

Canopy does not carry a fixed tool list. It uses the same discover, describe and invoke path as any other agent (see Capabilities and MCP and Capabilities), so installing a biome widens what Canopy can do with no prompt change. Every call it makes goes through the normal permission check and is audited as a capability invocation. What Canopy may do is decided by what you may do, not by Canopy.

---

Autonomy and consent

Before Canopy runs a capability that changes something, an autonomy setting decides whether it asks you first.

At every level, high and critical risk actions, actions that require approval, and organization-wide actions are confirmed. Nothing can make them silent.

Each organization can set a ceiling. An org admin sets the highest level any user may run at, or removes the ceiling. The ceiling is applied when the level is read, so lowering it takes effect for everyone at once, including users who never chose a level, and your own stored choice is kept as you set it. The setting shows you three things: the level in force, the level you asked for, and the ceiling that capped it.

When Canopy asks, the ask is durable: it survives a page reload, a restart and a change of device, and answering it on one device clears it on the others. You answer with one of:

• allow runs the action once.
• always also records a standing grant for that capability, so Canopy stops asking about it. It is accepted only where the ask said it was eligible, and the grant is capped at the risk level you were shown; if the capability later becomes riskier, Canopy asks again.
• deny refuses the action. The turn continues without it, and Canopy can adapt instead of retrying.

You can list your standing grants and revoke any of them. Revoking a grant you do not have is reported as "not found" rather than as success.

---

Using Canopy from the terminal

The xema canopy command opens a conversational REPL against your platform.

---

Previous: ← Shell Next: Store →