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 and 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 boundaries.
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.
You staff the role
An agent or skill that already works in your workspace. Early experiments stay personal until the method is stable.
You share access
You choose what the team can run or use, and under what credential and knowledge rules.
The team uses it
Teammates start runs and apply methods. You keep configuration control.
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.
Where the source lives
Create agents, shape skills, save memories, run private threads before anything is shared.
Where access is granted
Shared agents can be run. Shared skills can be discovered, attached, pinned, used, or forked.
What travels with a share
Teams share agents and skills by reference. The item still traces back to the person who built it.
🤖Shared agents
Run-only for members. Owner keeps prompt, tools, invocations, and settings.
🧩Shared skills
Method others can use. Fork when someone needs an editable copy of their own.
🧠Agent knowledge
Memories travel with the agent. Knowledge access decides whether team conversations can improve that agent.
🔌Integrations
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.
Runs stay with the person who starts them
If Taylor runs your shared agent, Taylor owns that thread and its artifacts. You still own the agent configuration.
Roles
🔑Owner
Invite and remove members, manage team settings, maintain shared infrastructure, delete the team.
👤Member
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
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 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
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.
Builder vs teammate
What each person sees is intentionally different. The builder maintains the machinery. The teammate gets a usable role.
Configuration and control
System prompt, model, integrations, skills, knowledge access, invocation setup, learning behavior.
Run and use
Name, description, purpose, ways to start a run, shared skill docs (read-only), fork option for skills, artifacts from their own runs.
FAQs
Teams turn personal agents into firm capacity. Builders keep ownership. Members get useful roles and methods inside clear credential and knowledge boundaries.