Sharing Agents
Learn how Group placement and permissions determine who can use an Agent in Giga.
Agents are designed to be reusable across the people who should have access to them.
In the current product model, Group placement is the main permission boundary around an Agent. The Group helps determine who can use the Agent and which shared resources are in scope.
Share through the right Group
Private Agent
Place the Agent in your private Group when it should only be available to you.
Shared Agent
Place the Agent in a shared Group when a team should be able to work with it.
Choose the audience before the access
The Group should reflect the real team or access boundary around the Agent.
What Group access can affect
An Agent may rely on several resources around it.
| Resource | How access is shaped |
|---|---|
| Agent | Available within its current Group and permission scope |
| Connections | Must be available to the Agent within the relevant scope |
| Skills | Must be visible or shared into the appropriate Group when needed |
| Files | Follow the access scope of the Group or Track that contains them |
| Context | Retrieved according to the current workspace and Group permissions |
Sharing the Agent alone does not automatically grant access to every resource elsewhere in the workspace.
Give teammates access to the Group
A teammate needs to belong to the workspace before an admin can give them access to a shared Group.
Confirm the teammate is in the workspace
Workspace membership comes before Group access.
Choose the Agent’s shared Group
Use the Group that represents the team or permission boundary around the Agent.
Grant the teammate access to that Group
Workspace admins can add an existing workspace member to a shared Group.
Check the Agent’s supporting resources
Confirm the required Connections, Skills, files, and context are also available within the appropriate scope.
Learn about Members and access →
Sharing an Agent does not expose secrets
If the Agent uses a shared Connection, teammates may be able to use that Connection through the Agent without seeing the underlying password, token, API key, or connection string.
Credential ownership and Connection sharing remain separate from Agent access.
Learn about giving Agents access to Connections →
Skills may need their own sharing
Skills have an explicit sharing model.
A Skill can remain owner-only or be shared into one or more Groups.
If a shared Agent relies on a Skill, make sure that Skill is available within the relevant Group scope rather than assuming the Agent can access every Skill in the workspace.
Private to shared
An Agent may begin as personal work and later become useful to a team.
Before widening its audience, review:
- its instructions
- its context
- the Connections it can use
- the Skills it relies on
- the Group that should own the shared access boundary
This helps prevent personal or overly broad context from being carried into a wider audience accidentally.
Review access before widening the audience
Sharing an Agent can make its role and supporting resources useful to more people. Check the full access scope before doing so.
Example: shared Recruiting Agent
Imagine a Recruiting team has a shared Recruiting Agent.
Recruiting Group
Defines the team that should be able to use the Agent.
Recruiting Agent
Carries the reusable role, instructions, and Agent-specific context.
Recruiting Connections
Give the Agent access to approved recruiting systems.
Recruiting Skills
Shared task methods can be reused by the Agent and team where permissions allow.
The Group keeps the audience consistent while each supporting resource keeps its own permission rules.
Image placeholder
Diagram showing a shared Group containing teammates and an Agent, with approved Connections and Skills available within the same permission scope.