Skip to main content

Sharing an agent

The Builder flow lets you publish an agent to your tenant's Internal Marketplace, where other members can discover, trial, and clone it.

Who can share​

Any project member with Builder role or higher. Tenant admins can restrict sharing to specific roles via Settings → Marketplace & Sharing (see Admin controls).

Where to start​

Open the Agent and go to Deployment → Share → Internal. ("With Colleagues" is the M1 internal scope. A future "Marketplace" public option is locked behind a "Phase 2" label.)

The share flow — 3 steps​

The Share modal is a 3-step flow.

Step 1 — Dependency checklist​

When you open Share, a background dependency scan runs and completes within ~5 seconds. If issues are found, a per-item checklist appears.

The two categories of items:

  • Knowledge Bases — actual KB data is not shared (Builder data stays with Builder). For each KB the agent references, you can either:
    • Add a dummy KB stub — a placeholder that the Cloner replaces later.
    • Create with AI — click the CTA on the agent/tool config screen. A detailed prompt opens; edit if needed, then generate. You preview the generated KB before adding it to the listing.
  • APIs / Connections — stripped at publish time (the Builder's secrets never leave). The Cloner provides their own credentials via the setup dialog after cloning. M1 does not let the Builder share APIs themselves.

A progress counter shows "3 of 5 resolved" so you know how far you have to go. Save & Continue is blocked until everything is resolved.

Step 2 — Listing details​

Fill in the listing card content:

  • Name — max 80 characters.
  • Description — max 300 characters.
  • Tags — up to 5, optional.
  • Visibility — Internal (active in M1). Public is shown but locked, labelled "Phase 2".

These pre-fill from the agent's existing name and description if available.

Step 3 — Final review​

A summary screen shows:

  • The full listing preview as Cloners will see it.
  • The dependency summary (what's stubbed, what was stripped, what the Cloner will need to provide).
  • A KB data warning banner if you chose Keep for any KB — confirm you understand that real KB data won't be shared.

Click Publish to complete.

Versioning a listing​

  • Sharing publishes the current published version of your agent as the listing.
  • When you publish a new version of the agent later, you can update the listing to point at the new version. Cloners who cloned the previous version aren't affected — their clone is an immutable snapshot.

Unpublishing​

  • Unpublishing is instant — a confirmation modal, then it's removed from the Marketplace.
  • Unpublishing never requires admin approval.
  • Unpublishing does not affect existing clones — Cloners keep their copy regardless. They retain it even if the Builder later disables the agent.

Analytics (Builder view)​

Once published, the Builder analytics view shows:

  • Total clones.
  • Clone time-series — useful to see adoption trajectory.
  • Tenant breakdown — org names only, no individual cloner PII (no names or emails).
  • Try session count — how often the trial mode was used.
  • Listing impressions — how often the listing appeared in browse / search.

Analytics are retained after unpublish or admin removal — they're never deleted, so you can revisit historical adoption.

What flows back to the Builder (and what doesn't)​

  • The Builder sees aggregate clone counts and the org names that cloned.
  • The Builder does not see individual cloner names, emails, or run-level activity inside Cloners' projects.
  • The Builder is never charged for trial or post-clone execution — that's the Cloner's bill.

Auditing​

Every Share lifecycle event is captured in the Audit log:

  • Agent shared (Internal).
  • Listing updated.
  • Listing unpublished.
  • Listing removed by admin.

Audit log is read-only and retained for at least 12 months. Tenant admins see all listings; project admins see their project's listings; Builders see logs for their own listings only.