Skip to main content
Sometimes you want to share one agent — let a teammate, an end user, or an embedded widget run it — without giving them everything in your sandbox. The decision comes down to whose integrations the agent should use when the other person runs it. Copass gives you two flavors that differ on exactly that question.

​
The two flavors

Invoke

The holder runs the agent as themselves. Their connected integrations — their Slack, their GitHub, their Gmail — are what the agent uses.Use when a teammate wants your agent design with their own credentials.

Delegate

The holder runs the agent as if you were calling. Your connected integrations are what the agent uses.Use when the holder doesn’t have their own accounts to plug in — a customer, an anonymous widget, an internal bot.
The decision tree is one question: “When this agent runs, whose Slack / Gmail / GitHub should it actually use?” Holder’s → invoke. Yours → delegate.

​
Picking the right one

Internal teammate, own credentials

“Let Alice use my support agent design with her own Slack and GitHub.”→ Invoke. You’re sharing the design; Alice authenticates as herself; the agent runs against her data.

Customer support widget

“Embed a support agent on our marketing site that anyone can chat with.”→ Delegate. Anonymous customers don’t have OAuth-connected accounts. The agent runs against your support knowledge base.

Internal Slack bot

“Bot anyone in the org can @mention to query our knowledge graph.”→ Delegate. The bot uses your service identity’s connections; per-user identity isn’t relevant for read-only querying.

Open-source agent template

“Publish my triage agent design so others can run it with their own data.”→ Invoke. Each downstream user OAuths their own integrations; the agent design is the only thing you share.

​
Sharing it

Ask the Concierge:
“Share my support agent so my teammate can use it with their own Slack.” → invoke
“Embed my triage agent on our marketing site.” → delegate
The Concierge confirms the choice (especially for delegate, since you’re effectively lending your OAuth credentials), surfaces the access token once, and reminds you to store it safely.

​
What the recipient experiences

  • Invoke: they call the agent with the access token; the agent runs against their connected integrations and their sandbox; usage is billed to their account.
  • Delegate: they call the agent with the access token; the agent runs against your integrations and your sandbox; usage is billed to your account.
The agent design is yours either way — the difference is whose execution environment it runs in.

​
Versioning

When you update the agent’s prompt, model, or tool list, the next call from any holder picks up the new version automatically. There’s no “pin to v3” today. If you need a stable contract for downstream holders, treat the agent as the contract and version-bump deliberately.

​
Listing and revoking

“What’s been shared from my support agent?” “Revoke the share for my marketing-site widget.”
Both are owner-only. Revocations take effect immediately.

​
When to share the whole sandbox instead

If the person needs to do more than run this one agent — read other agents, inspect runs, build their own — give them a sandbox connection at viewer or editor role instead. Per-agent shares are for narrow, single-purpose access; sandbox connections are for collaboration on the whole tenancy.

​
Next steps

  • Sharing context — invite someone into the whole sandbox at viewer or editor.
  • Concierge — the natural-language interface for sharing, listing, and revoking.
  • Agent Router — the runtime that the shared access token is used against.