How to Share and Collaborate on AI Agents with Your Team

You built an agent that saves you real time, and right now you're the only person who gets to run it. Your teammates keep asking for its output, so you end up running it on their behalf.

Sharing gets uncomfortable when you can't predict what happens next: someone rewrites the instructions you spent days tuning, or a colleague sees numbers they shouldn't. Below, you'll see how AgentSpot handles each kind of access, so you can hand off what you built and still keep control of it.

Should You Finish an Agent Before Sharing?

Yes: run the agent yourself first and fix what breaks before anyone else depends on it. Once colleagues rely on an agent, every rough edge shows up in their workflow too, and the questions end up in your inbox. Before you call it done, put that first run through these checks:

• Compare the output against what you'd produce by hand.

• Confirm each connected tool returns what you expect.

• Reread the instructions as if you were seeing them for the first time.

How Do You Share an AI Agent?

You share an AgentSpot agent by opening it, clicking Share, and entering your colleague's email. The steps are identical for an agent or an app, so there's only one flow to learn. On your colleague's end, a notification arrives and access is immediate: there's no separate invite to send and no waiting on IT.

That quick handoff is the heart of Multiplayer AI: the person closest to the work builds the agent, and everyone who needs it can run it. If you'd like the broader idea behind it, here's a primer on what Multiplayer AI means. Before you type that email address, though, decide what you want the person to be able to do.

What's the Difference Between Use and Edit?

Use access lets someone run your agent exactly as you built it, while edit access lets them open it in the builder and change it. Unless you choose otherwise, anyone you share with gets use access. With edit access, a colleague can add steps, adjust instructions, or connect a tool.

Here's the part to plan for: edits apply for everyone who uses the agent next. If an editor tweaks a prompt on Tuesday, every person who runs the agent on Wednesday gets the tweaked version.

So how do you decide who gets which option?

• Give use access to people who need the output but won't change the logic.

• Give edit access to people you'd trust to maintain the agent alongside you.

If you're on the fence, use access is the lower-stakes starting point, though it won't fit the colleague who wants to rework the agent for their own needs.

When Should Someone Duplicate Your Agent Instead?

Someone should duplicate your agent when they want to adapt it for their own work without changing what everyone else runs. Duplicate creates a private, fully editable copy, while your original agent and your personal details stay exactly as they were.

As for what comes along, Duplicate carries over what it can, and anything it can't shows up as a note. That might be a connector the new owner doesn't have access to, or a knowledge file that didn't transfer.

Because those gaps appear as notes, setup isn't blocked, and the new owner can see what still needs attention. Copying a proven agent also lets each person adapt it without everyone editing the same original. All of that assumes people know your agent exists in the first place.

How Do You Share Agents Org-Wide?

Org-wide reach runs through Admin: a direct share reaches only the people you name, but admins can grant AgentSpot access org-wide through roles. Once an agent is accessible org-wide, it appears in shared views like the Team Library. From there, colleagues can find it, duplicate it, or request edit access.

Why does that matter to you as the builder? Your agent's reach stops depending on who happens to know you made it.

As more colleagues build and share, your org starts to resemble the multi-agent systems you may have read about. You'll have many agents with different owners, and the Team Library gives people one place to find what already exists. With that wider reach, the next thing to settle is what data each person actually sees.

Do Shared Apps Expose Other People's Data?

No: shared apps inherit the access rules on their data sources, so each person's existing permissions decide what they see. If your app pulls from ThoughtSpot models, row-level security still applies to every viewer. Connectors like Salesforce or Slack follow the same logic another way: each viewer signs in with their own account, so the app shows only what that account can already reach.

What does that look like in practice? Say your ThoughtSpot model limits rows by region, and you share an app with a colleague in another region. You'll both open the same app, yet each of you sees only your own region's rows.

The same holds once several of your apps draw on the same sources. Because the rules live at the source, you don't rebuild permissions inside each app you share.

What Should You Ask Before You Share?

Run through these five questions before you click Share, and you'll know exactly which access each person needs:

• Have you run the agent yourself and fixed what broke?

• Does this person need to run it, change it, or adapt it for themselves?

• Would an editor's changes affect people who rely on the current version?

• Should the agent reach the whole org through the Team Library, or stay with the people you name?

• Do the data sources behind your app carry the right access rules for every viewer?

If any answer gives you pause, start with use access for a small group. You can share with more people once you've seen how it goes.

Which Agent Should You Share First?

The agent you built for yourself is often the one your team needs most. Pick the one you'd hand off first and bring it to an AgentSpot demo. In that session, you can map which teammates should run it as is and which ones need edit access or a copy of their own.

Request an AgentSpot demo, and we'll walk you through how sharing works for your team.