Publishing an Agent
Building an agent for yourself is one thing. Publishing it — making it available for teammates to adopt — is where enterprise governance steps in.
The approval gate
Section titled “The approval gate”When a team member publishes an agent, it doesn’t go live for others immediately. It routes to an admin for review. The admin checks what the agent does, the tools and connectors it uses, and the actions it can take, then approves it into the team’s catalog or sends it back with feedback.
Admins can publish directly. Team members publish through approval. That one difference is what lets an organization open building up to everyone without losing control of what ends up in front of the team.
What to include when you publish
Section titled “What to include when you publish”Give your reviewer what they need to say yes quickly:
- A plain description of what the agent does and why it’s useful.
- The systems and data it touches.
- Any actions that should require approval when it runs.
- Who it’s for — a team, a department, or the whole org.
The more context you provide, the faster the review goes.
After it’s published
Section titled “After it’s published”Once approved, the agent appears in the team’s approved marketplace, where others can adopt it. Changes you make later may go through review again, depending on your organization’s settings — so an agent can’t quietly change behavior after it’s trusted.
A quick example
Section titled “A quick example”An ops lead builds an agent that generates weekly vendor reports. She publishes it with a note explaining it only reads from the finance connector and posts to a private channel. The admin sees there are no risky actions, approves it, and it’s live for the ops team by the afternoon.
Related
Section titled “Related”- Who can publish, and how → Capability matrix
- Where reviews happen → Requests