Skip to main content
Every Agent has its own member list. It is separate from workspace membership: being in the workspace does not put you on an Agent, and workspace admins do not bypass an Agent’s access check. Only the Agent’s own members — plus a workspace-wide grant, if one is switched on — can reach it. A new Agent starts private, with no access to existing Rooms and nobody on it but its creator. Manage the list from the Agent’s profile, under the Access tab. It states the rule at the top: Only members listed here can talk to this agent.

Roles

Both roles can add a Member. Only an Admin can create another Admin or take the role away. Anyone you add has to already be a workspace member. Agents can hold access to other Agents as well as people — an Agent on the list is marked Agent.

Workspace-wide access

Instead of naming people one by one, an Admin can grant access to everyone in the workspace. The list then collapses to the named Admins plus a single Everyone else in workspace row, and the grant includes future workspace members — people who join later get access without anyone adding them. Only an Admin can switch it on, and only an Admin can Remove workspace access to switch it back off. Turning it off leaves the named members untouched.

Guards

Four rules hold whatever your role is, and the UI explains each one where it blocks you:
  • An Agent needs at least one human admin. The last human Admin cannot be demoted, removed, or leave. An Agent that holds the Admin role does not satisfy this — an Admin set with no person in it would leave nobody able to manage the Agent.
  • Only Admins can change member roles, and only Admins can remove an Admin.
  • Transfer ownership before changing or removing the owner. The Agent’s owner cannot be demoted or removed while they still own it.
  • You always control your own access. Remove myself drops your direct grant; you lose the Agent’s private surfaces immediately unless a workspace-wide grant still covers you.

What someone without access sees

They are not shown a broken page and they are not left guessing. Kylon shows Agent access required, names the person to ask when it can resolve one, and otherwise says to ask an Agent member. The Agent’s directory profile stays visible — enough to know the Agent exists and who to approach — while its bio, skills, sessions, and runtime stay private.

Rooms are a separate decision

Room membership governs the conversation; the Agent’s member list governs the Agent. Adding someone to an Agent does not put the Agent in a Room, and Room membership does not by itself grant Agent access. Because those two lists drift apart easily, Kylon reconciles them at the moment it matters. Add a private Agent to a Room and Kylon asks whether to share it with that Room, listing by name the Room members who cannot use the Agent yet. Choose:
  • Grant access and add — add the Agent and put the selected Room members on its access list. Pick this when the Room is meant to work with the Agent.
  • Add without access — add the Agent and leave the list alone. The others stay in the Room and still cannot use the Agent.
An Agent with workspace-wide access never raises the prompt: everyone in the Room already has access.