Build
Who an agent is for
Every agent, an AI worker you set up once and then give jobs to, has an audience: the people in your organization who can find it, talk to it, and use it. You pick from three:
- Everyone in the org. Anyone who can sign in can use it. This is the default, and it is how every agent worked before this setting existed.
- Only listed people. You name who is in. Nobody else sees it at all.
- Only one person. One person's own assistant.
The reason to care is memory. An agent remembers things, and what it remembers for the group is readable by whoever can reach it. Narrowing the audience narrows that automatically. A four-person deal team gets an agent whose accumulated knowledge stays with the four of them, without anyone setting up a separate organization.
Pick one
| Audience | Use it when |
|---|---|
| Everyone in the org | The agent does shared work: triage, reporting, a company-wide assistant |
| Only listed people | A deal team, a client pod, an on-call rotation. Their working notes should stay theirs |
| Only one person | Someone wants an assistant that learns their habits and their clients, and nobody else's business to see it |
When in doubt, leave it on everyone. Narrowing later is easy. Opening back up is the change that can't be taken back, for the reason in Opening an agent up.
Set it
- Open Build > Agents and pick the agent.
- Click Edit.
- Under Who this agent is for, pick one of the three.
- If you picked one of the narrower two, search the picker for the people who should have it and add them.
- Click Save, then confirm the change.
The agent page now shows the audience and its member count, and the agent list badges it, so you can see at a glance which agents aren't shared with everybody.
You can make the same choice while creating an agent, in the same place on the create page.
Through the API, the field is visibility on the agent, and the three values
are organization, restricted, and private. Members are a sub-resource:
GET, POST, PUT, and DELETE under /v1/agents/{id}/members. Exact
shapes are in the
interactive API reference.
Who's in it
Open the agent and look at Who this agent is for. If you can manage the agent, you see the list: who's in it, when they were added, and by whom. If you're just a member, you see the count. That's on purpose: you should always be able to answer "who else can see this", without the member list becoming a company directory.
You can manage an agent's audience if you're an org owner or admin, or if you created the agent and are still one of its members. That second rule is what lets someone run their own team's agent without asking an administrator every time somebody joins.
Note: Members can be agents, not just people. Adding an agent to another agent's audience is how a coordinating agent reaches a team's agent on purpose. It's rare, and it's why the member list is visible to everyone in the audience.
Adding someone
A new member reads everything the agent knows for the group, including things that were shared before they joined. There is no partial view. That's how a shared store works, and it's worth a moment's thought before you add someone to a team agent with a long history.
What a member reads is the group's shared knowledge. What each person told the agent privately stays private to them, always. See Private and shared memory.
Removing someone
They lose access on their next request. Nothing they wrote is deleted:
- What the agent learned privately about them stays stored, readable only to that person.
- Anything they deliberately shared with the group stays shared. Sharing made it the group's.
- Their past conversations stay private and are not opened to org admins.
If you remove the last member, the agent doesn't reopen to the org. It goes
inactive and only admins can see it. Add somebody and it comes straight back.
Same thing when a person leaves the company: their memberships go with them,
and their personal agent is parked rather than handed to everyone.
Opening an agent up
Widening an audience republishes what the agent knows to the new, larger group. That can't be undone. Narrowing it again doesn't un-read what people have already seen.
So it isn't a quiet dropdown change. You'll get a confirmation that names the numbers: "Everyone in the org will be able to talk to this agent and read the 14 things it knows. The 3 current members will no longer be listed."
Narrowing an agent
Going the other way is safe for the knowledge, but it can strand people. If someone outside the new audience has private memory on the agent, a conversation with it, or a routine that uses it, we stop and tell you before anything changes.
You pick what happens to those:
- Keep them (the recommendation). Their memory and conversations stay, readable only by them. Routines they own on this agent are paused, so they fail visibly now instead of mysteriously at 3am.
- Delete their memory. Only the person or an authorized offboarding action can choose this, and only their private entries go. The group's shared knowledge is untouched.
What admins can govern
Org owners and admins can govern an agent's configuration, including a personal agent: change its custodian, narrow or widen its audience with the required dispositions, deactivate it, or delete it. Custody is separate from audience, so the human responsible for an agent can govern it without automatically joining its conversations.
That administrative authority does not reveal private conversations, output, or another person's memory. There is no admin or support break-glass read. When a person leaves, private work is shown only as counts and is sealed; it is not handed to the administrator or the agent's next custodian.
In the employee workspace
Employees see the assistants they can actually use: the company's shared ones, plus any that are theirs or their team's. Each one says who else can see it, in plain words: "Only you", or "Shared with 3 people".
There's no audience control in the workspace. Ask whoever set up your assistants to change it.
FAQ
Can I have two people on an "only one person" agent? No. Switch it to Only listed people and add the second person. Keeping the one-person case exactly one person is what makes "this is mine" mean something.
Can I take myself out of an agent I created? Yes. Leaving the audience stops you from talking to it or seeing its sessions. If you remain its custodian, you can still govern its configuration; those are separate relationships. An org admin can change either one.
Does a narrower agent work differently? No. Same model, same tools, same instructions, same company context. The only difference is who can reach it, and therefore who shares its knowledge.
Can I connect Slack or email to a narrower agent? A one-person agent, yes: messages to it write knowledge only that person reads. A team agent needs an allowed-sender list on the connection first, so an outsider can't write into the team's shared knowledge. An email inbox has no sender list, so team agents can't have one yet.
Next
- Set up the agent itself in agents.
- See what an agent remembers, and share something with your team, in agent memory.
- Manage roles and org access in organizations and access.
- Understand what an agent's work inherits in Your work and the team's work.