Teams

Teams let builders share agents and skills while keeping ownership and configuration control. Teammates get a useful agent or method they can call on when they need an output produced.

When work becomes shared

Sharing starts when a setup you built for yourself becomes useful to other people. Maybe it's an agent that checks pipeline movement before your Monday forecast call, or a brand voice skill you keep using for launch materials.

Once the setup works, the next step is access. Sales wants to run the pipeline agent. Marketing wants the brand voice skill available to anyone writing emails, pages, or launch briefs.

Teams make that setup available to other people while the builder keeps the source.

How shared access works

Your personal workspace is where you build and manage your own agents, skills, memories, and threads. A team is the shared surface where selected agents and skills become available to other people.

The builder keeps the source. The team gets access to use it. Shared agents stay configured by the owner. Shared skills become available in each teammate's workspace, where their agents can discover them like any other available skill.

From there, teammates can use a shared skill in the ways they already use skills: attach it to an agent, pin it when it should be part of that agent's default job, or fork it when they need their own editable version.

What teams share

Teams share agents and skills by reference. The shared item still traces back to the person who built it.

Threads, documents, tables, and projects stay with the person using the agent. If a teammate starts a thread with a shared agent, the documents and tables created in that thread belong to that teammate's run. That keeps people's artifacts separate and avoids accidental overwrites.

Roles and permissions

Teams have two roles: owner and member.

Owners configure the shared system. Members use it to run agents and apply shared methods.

Sharing agents

Sharing an agent gives the team run-only access. Teammates can use the agent while the owner keeps the configuration.

This works well when the agent already has the right role, tools, integrations, skills, memories, and invocation methods. A RevOps agent might already know the team's pipeline definitions, have access to Salesforce and Databricks, and follow the forecast-review process your team expects. Sharing gives teammates that working setup while the owner keeps the machinery underneath.

The agent owner's configuration still matters. The shared agent uses the owner's configured integrations and billing. If the owner connected Salesforce, Gmail, or another service to the agent, teammates using the agent inherit that working connection through the agent.

Sharing skills and credentials

Shared skills become available to teammates and their agents. Teammates can attach or pin them to their own agents, or fork them when they want an editable copy.

Credentials are the part to think through before sharing a skill. Some skills are pure method: a voice guide, checklist, report format, or research workflow. Others can run scripts or call APIs, which means they need access to another system.

Teams lets the skill owner choose how that access works. A teammate can use the owner's credentials, bring their own, or use the skill as documentation with no credentials attached.

Credential modes let you share the useful method with the right level of access. A teammate might use a research checklist with no credentials, connect their own account for work that should run as them, or run an approved workflow through one shared service account.

Knowledge access

Shared agents need clear rules for learning. The main question is: should the agent learn from the team, or should the owner decide exactly what it knows?

Knowledge Access controls what the agent can see and whether team conversations can improve the agent over time.

Curated is the controlled default for shared agents. The agent only sees the memories and skills linked to it, and learning stays off for shared conversations.

Team Learning keeps the same linked knowledge boundary, but lets the agent improve from team conversations over time.

Use Personal for agents you use yourself, and Custom when you want to tune permissions one by one.

Builder vs. user experience

The builder sees the configuration surface. They maintain the system prompt, integrations, skills, memories, knowledge access, credential choices, and invocation methods.

The user sees the useful surface. For a shared agent, that means the name, description, icon, purpose, and ways to start a run. They can run the agent through the entry points the owner configured. The owner maintains the system prompt, credential setup, model settings, learning settings, and attached skills list.

For a shared skill, users see the name, description, tags, when-to-use guidance, and documentation in read-only mode. If they need to change it, they fork it into their own workspace.

This keeps shared agents and skills usable while the builder maintains the setup.

Team FAQs

Teams are a sharing surface for agents and skills. Builders keep ownership and configuration control. Members can run shared agents, use shared skills, and work within clear credential and knowledge boundaries. Use Curated access when shared behavior should stay controlled, and Team Learning when the agent should improve from team use.