# Teams Source: https://www.hyperagent.com/docs/concepts/teams Share agents and skills so other people can run useful roles without owning the configuration. A useful agent on your laptop is personal capacity. The same agent, runnable by sales before the forecast call, is capacity for the firm. **Teams** are how Hyperagent makes selected [agents](/docs/concepts/agents) and [skills](/docs/concepts/skills) available to other people without turning every teammate into an agent engineer, and without giving away ownership of the configuration. You keep the source. Members get a role they can run and methods they can use, inside clear credential and [knowledge access](/docs/concepts/agents/knowledge-access) boundaries. ## When work becomes shared [#when-work-becomes-shared] Sharing starts when a setup you built for yourself becomes useful to other people. A pipeline agent before Monday forecast. A brand voice skill for launch mail. Sales wants to run the agent. Marketing wants the skill. Teams make that setup available while the builder keeps the source. An agent or skill that already works in your workspace. Early experiments stay personal until the method is stable. You choose what the team can run or use, and under what credential and knowledge rules. Teammates start runs and apply methods. You keep configuration control. ## Personal workspace and team [#personal-workspace-and-team] Your personal workspace is where you build. A team is where selected agents and skills become available to other people. The builder keeps the source. Shared agents stay configured by the owner. Shared skills become available in each teammate's workspace so their agents can discover them like any other skill: attach, pin, or fork into an editable copy. Create agents, shape skills, save memories, run private threads before anything is shared. Shared agents can be run. Shared skills can be discovered, attached, pinned, used, or forked. ## What travels with a share [#what-travels-with-a-share] Teams share agents and skills by reference. The item still traces back to the person who built it. Run-only for members. Owner keeps prompt, tools, [invocations](/docs/concepts/agents/invocations), and settings. Method others can use. Fork when someone needs an editable copy of their own. Memories travel with the agent. [Knowledge access](/docs/concepts/agents/knowledge-access) decides whether team conversations can improve that agent. The agent can bring the owner's working connections so teammates do not re-auth every system to get a first result. Threads, documents, tables, and projects from a run stay with the person who started the run. The agent is shared. The run belongs to the runner. If Taylor runs your shared agent, Taylor owns that thread and its artifacts. You still own the agent configuration. ## Roles [#roles] Invite and remove members, manage team settings, maintain shared infrastructure, delete the team. Add agents or skills to the team, run shared agents, use shared skills (owner credentials, bring-your-own, or none), fork skills into personal copies. ## Sharing agents [#sharing-agents] Share when the role is stable enough for other people to run: recurring workflows, connected tools the builder already maintains, a clear job description. Before you share, Hyperagent shows what access travels with the agent: connected accounts, credentialed skills, attached knowledge. Read that screen carefully. Teammates inherit the ability to *use* those connections through the agent, not ownership of your whole account. Set [knowledge access](/docs/concepts/agents/knowledge-access) first. * **Curated** (or agent-owned / locked learning) is the usual default for shared and Slack-facing agents. Teammates can run the role without quietly rewriting what it knows. * **Team self-learning** is for roles that should improve from team use on purpose. New knowledge lands on the agent, not in each member's private library. If the agent will listen in a channel other people can talk to, start locked down. Widen learning only when you mean to. ## Sharing skills and credentials [#sharing-skills-and-credentials] Shared skills are methods. Credentials are a separate decision. Some skills are pure method: voice, checklist, format. Others call APIs and need access. Pick the credential mode that matches the risk. * **No credentials** for process-only skills * **Owner credentials** for an approved shared account the builder maintains * **Bring your own** when each person should act as themselves against the external system Forking a skill creates an editable personal copy. It does not rewrite the shared original in place. Import behavior for bundles and marketplace installs is covered in [Edit and import skills](/docs/concepts/skills/skills-edit-and-import). ## Builder vs teammate [#builder-vs-teammate] What each person sees is intentionally different. The builder maintains the machinery. The teammate gets a usable role. System prompt, model, integrations, skills, knowledge access, invocation setup, learning behavior. Name, description, purpose, ways to start a run, shared skill docs (read-only), fork option for skills, artifacts from their own runs. ## FAQs [#faqs] When the setup is useful to other people and stable enough to run without you narrating every step. Recurring jobs with clear tools and standards are the best candidates. Early experiments, private preferences, and one-offs. Personal space is for shaping the method before it becomes infrastructure. No. Shared agents are run-only. The owner maintains configuration. Not in place. They can fork into their personal workspace and edit the copy. Only if knowledge access allows learning from those conversations (for example team self-learning). Curated keeps the wall up. Details: [Knowledge access](/docs/concepts/agents/knowledge-access). The member who started the thread owns that run's artifacts. The agent configuration stays with the owner. Teams turn personal agents into firm capacity. Builders keep ownership. Members get useful roles and methods inside clear credential and knowledge boundaries.