Sharing with your organization

An agent starts private. Setting its visibility to organization makes the published agent available to every member — the standard way to turn one well-built agent into a team capability.

cai agent visibility <agentId> --value organization

There is no public visibility mode: agents are private or organization-shared, nothing else.

What teammates get — and don’t

• The latest published version, always. Never the draft. Publishing is the only way changes reach them (publishing).
• Use, not edit. Sharing grants conversation access only — teammates cannot edit, manage, or open Test conversations. The draft stays entirely yours.
• Your connections. Integration actions run on the owner’s connected accounts: when a teammate’s conversation sends a Slack message, it sends as your connection. The tool surface you attach is what teammates can do as you — set approval policies with that in mind.
• The organization’s usage pool. Shared conversations meter against the org’s shared balance, not per-teammate budgets (cost model).

The stability caveat

Sharing does not freeze behavior. Two live bindings change a shared agent under its users without any publish: publishing an attached workflow (tools always follow the latest live release), and rebinding or revoking an action’s connection. Before republishing a workflow that shared agents depend on, check the blast radius:

cai deps --account

A sane rollout sequence

1. Build and test privately (draft + Test conversations).
2. Publish and use it yourself in Live for a while.
3. Set organization visibility.
4. Treat attached-workflow publishes as production changes from then on.

Example prompts

Share this agent with the organization, and first audit its tools: list every action, whose connection it runs on, and its approval policy.