Team agents
Choose between a team-owned agent and a personal agent shared with a team for run-only access.
A team makes an agent available two ways: the team owns it, or a person shares their personal agent for run-only use. Both let every member run it. They differ in who may change it, which is the decision that matters after the first run.
Availability is easy; maintenance is the real choice
Either model gets the agent in front of your team today. Only one of them decides who fixes it next month.
The team's Agents tab keeps the two apart, so you can always tell which model an agent is on.
Two ownership models
The agent belongs to the team. Owners and Editors edit its configuration; every member runs it.
- Who maintains it: Owners and Editors, together
- What they can change: instructions, skills, tools, connected integrations, and its execution mode
- Choose it when the agent's job belongs to the team's workflow rather than one person's
Team ownership also lets agents work as a system. Scout triages a case, delegates to Scribe when the resolution should become documentation, and hands the approved result toward Press. That handoff lives in the shared configuration, so Owners and Editors maintain it once and Members use it without redefining it each run. How each agent gets started, on a schedule, from Slack, or by another agent, is covered in Invocations.
Scout and Scribe fit here: support and documentation specialists maintain them together.
The agent stays personal and the team gets run-only access. Its owner keeps everything else.
- Who maintains it: the person who shared it, alone
- What the team can do: run it, and nothing more, whatever their role
- Its context: only what was already available to the agent, never its owner's wider library
- Choose it when teammates should benefit from the agent without becoming its maintainers
To share, use Share… on your agent and pick the team. Nothing transfers: no copy is made, and the team can't edit the source. If Press needs a new publishing connection, only its owner can add it.
Revoking the share is an access decision, not an ownership change: Press stops being runnable through that team, nothing is deleted, and the team keeps no frozen copy. Share it again later and the same relationship comes back rather than a duplicate.
Sharing does not widen memory access
A shared agent uses only the context already available to it. Press keeps its linked publishing preference, gains nothing else from its owner's personal library, and absorbs nothing from whoever runs it.
Move an agent between personal and team
Sharing grants access; a move changes who owns the agent. Reach for it when maintenance should change hands: a personal agent whose job has become the team's, or a team agent that should go back to one person.
Start the import
Open the team's Agents tab and choose Import, then pick the personal agent that should become the team's.
Review what moves
The confirmation lists what changes hands: the agent's configuration, its own memories, and its threads, which are re-stamped to the team workspace. It tells you how many threads that is before you commit. Linked documents get a per-document choice: copy into the team, or leave behind.
Confirm
From then on Owners and Editors maintain the agent and every member can run it. The reverse move, demoting a team agent to one person, works the same way, and pauses the agent's automations so a schedule doesn't keep firing under changed ownership.
Whichever model an agent is on, the person who starts a run owns the resulting thread and its outputs. Agent ownership decides who maintains the capability, not who owns the work it produces.