Sharing and publishing

An agent that no one knows about isn’t really an agent

You built an agent. It produces a great release note, a clean summary, a sharp customer brief. You use it three times a day.

If only you use it, you’ve automated your own work. If your team uses it, you’ve changed how a piece of your team’s work gets done. The difference between “personal tool” and “team capability” is sharing.

This page covers how.

The three ways to share

Direct sharing

The simplest pattern. You open the agent’s settings, pick who can use it, and you’re done.

You can share with:

• An individual. “Just my teammate working on this project.”
• A specific team. “Everyone on the customer success team.”
• A custom group. A set of people you pick by name.

Shared users see the agent in their list. They can run it, see results, and (depending on settings) refine the conversation. They cannot edit the agent’s underlying configuration unless you grant them that.

When direct sharing is the right call

• The agent is for a specific use case in a specific team.
• You want to test with a few real users before broader publishing.
• The agent uses sensitive knowledge sources and you want explicit control over who reaches it.

Publishing to the workspace library

When an agent has proven itself in direct sharing, you can promote it to the workspace library. From there, anyone in the workspace can discover and use it.

Publishing involves a few small upgrades to make the agent discoverable:

• A clear name. “Weekly customer-success digest writer” beats “csbot v3.”
• A description. What the agent produces, for whom, and when to use it.
• Tags. Categories that help discovery — customer-success, weekly, internal-doc.
• An example run. Pin one of your good conversations as the example.
• A “who this is for” line. Sets expectations so the wrong audience doesn’t waste a run.

Once published, the agent appears in the library alongside the pre-built library agents — searchable, browsable, ready to use.

When publishing is the right call

• The agent solves a problem several teams in your workspace have.
• You’re ready for teammates to use it without asking permission.
• You’ve used it enough to know it’s reliable.

Workspace publishing rules

Depending on your workspace, publishing may be open to any agent owner or restricted to admin-approved publishes. Either model is fine — workspace admins set this in Governance and admin.

Embedding into your own app or page

For agents that should reach people who don’t open VDF AI directly, you can embed.

The most common embedding patterns:

A web page

The agent appears as a chat widget on your internal landing page, intranet, or product page. Users start a conversation without leaving the page.

A few real examples:

• A customer support page where users can ask questions before opening a ticket.
• An internal HR page where employees can ask about policy.
• A product page where prospects can ask product questions and get sourced answers.

Inside your own product

For teams building their own software, the agent can be embedded as a feature inside the product. The user sees a familiar chat interface; the agent is yours, configured for the use case.

Through your existing workflow tools

Some teams embed agents into tools their team already uses — surfaced as a button or a side panel inside Confluence, Notion, or an internal portal.

What embedding does (and doesn’t) require

You don’t need to know how to integrate code yourself. Each agent ships with an embed snippet — a small piece of code your team’s web developer or platform team can drop into a page.

You do need to think about:

• Who the agent should serve. The embed appears to everyone who reaches the page. Match the agent’s scope to the audience.
• What knowledge it should have. An agent embedded on a customer-facing page should not have access to internal-only knowledge sources.
• What tools it should have. A customer-facing embed usually has a narrower tool set than the internal version.

A useful sharing progression

Most agents that end up being valuable to a team follow a clear arc:

1. Personal use.

   You build the agent for yourself. You use it for a week. You iterate.

2. Direct sharing with a teammate.

   You hand it to one person who has the same problem. They use it. You learn what doesn't translate.

3. Direct sharing with a small team.

   The agent is now usable by people who didn't build it. You refine for discoverability — clearer name, sharper description.

4. Workspace library publishing.

   Anyone in the workspace can find and use the agent. You add tags, an example, a "when to use" note.

5. Embedding, if it fits.

   If the agent's audience extends beyond people who use VDF AI directly, embed.

Most agents stop at step 3 or 4. That’s fine. Embedding is for the agents that serve audiences beyond your workspace.

Managing shared agents over time

A few habits that keep your shared agents healthy.

Watch the run history

The Runs view shows how often your agent is being used and by whom. Trends matter: a sudden drop usually means something changed. A steady climb is a sign the agent is becoming part of how the team works.

Listen for feedback

People who use your agent will tell you what’s missing — sometimes explicitly, sometimes through their refinement patterns. A weekly skim of recent conversations tells you what the next improvement should be.

Version explicitly

When you make a meaningful change to a shared agent, name what changed. “v4 — tightened the audience to enterprise customers only.” Future users (and future-you) will understand the agent’s history.

Retire what’s no longer useful

An agent that hasn’t been used in a quarter and isn’t part of an active workflow is a candidate to archive. A clean library is a useful library.

A few patterns that work

Share the workflow, not just the agent

When you publish an agent, write a one-paragraph guide for how to use it. “Use this for the Monday digest. Attach the weekly Salesforce report. The agent produces a draft you can edit.” The agent + the guide is what’s useful — neither alone is.

Announce publishes

When a new agent lands in the workspace library, tell the team in Slack or email. Discovery is half of usage.

Treat shared agents like products

Name. Description. Tags. Example. Owner. The same posture you’d take for a real product produces real adoption.

Retire predecessors when you publish a successor

If your “v4” agent is meant to replace your “v3” agent, don’t leave both in the library. Archive v3 with a note pointing to v4. Otherwise users get confused about which to pick.

Where to go next

• Governance and admin — workspace-level controls on sharing and publishing.
• Creating your own agent — build the agent worth sharing.
• Agent library — what good shared agents look like.
• Chatting with agents — what users experience when they reach for your agent.