Adding Team Members

Every end user of your applications is an actor. Actors live in your tenant's Directory (/app/directory), and they are what per-user access control is built on: a request identifies its actor, and the engine filters search, graph, and memory results to that actor's own data plus whatever is shared with their groups.

Provisioning is fail-closed. An actor the directory does not know is rejected, not treated as anonymous — so create the person's record before their first request, not after.

Do this before writing access rules

The group and actor ids you create here are exactly what access rules label folders with. Writing rules first means typing ids that do not exist yet.

Add one person

1. Go to Directory and click New actor.
2. Fill in the Actor id (see Actor ids — this is the one field that must be exactly right).
3. Optionally set a Display name. It is for your eyes only; nothing matches on it.
4. Pick a Role — see Roles.
5. Add the person to Groups — see Groups.
6. Click Create actor.

The actor is live immediately. There is no invitation and no email: you are not creating a login, you are telling the engine that this identity is allowed and what it may see. The person authenticates through whatever client you have connected (an MCP host, your own app, a chat channel), not through this console.

Actor ids

The actor id must match exactly what your client asserts on the request. Getting this wrong is the single most common reason a user sees nothing.

For users arriving through a UGENT channel, the id is {channel}:{user_id} — for example web:U123 or slack:U04ABCD. The create form has a channel picker that fills the prefix for you; type the user id after it. A custom channel can be typed directly.

Matching is exact, so web:U123 and Web:U123 are different actors.

Do not transcribe ids by hand

Two places in the console offer the real ids so you never mistype one:

• The New actor form lists ids the engine has already seen but that you have not provisioned yet, as a quick-fill picker.
• Actor activity (/app/actors) lists every actor a client has actually asserted — including the ones that were denied because they were not provisioned — with their recent queries. Provision them straight from that page.

Roles

The role decides how far a person can see beyond their own data.

Role	Sees
Member	Their own private data, plus anything shared with their groups. The default, and the right choice for most people.
Supervisor	Everything in their groups, including other members' private folders in those groups. Use for a team lead who must read their team's work.
Admin	Everything in the tenant. Bypasses access filtering entirely.

Give Admin sparingly: it is not "an administrator of the console", it is "this person's queries are never filtered".

Groups

A group is how you grant the same access to several people at once. Group membership is the permission: each group id on an actor grants that actor everything labeled group:<id> — in the standard folder layout, that group's shared folder.

There are two halves to a group, and only one of them is required:

• The group id on an actor. This is what actually grants access. Add it in the actor form's Groups field.
• The group record on the Directory's Groups panel. This only gives the group a display name so it is legible in the tables.

Because of that split, typing a new group id in the actor form is enough to create the group — the console warns you that it is new, the actor gets group:<id> access as soon as you save, and the group simply has no display name until you add a record for it. Deleting a group record does not unassign anyone; their membership stays in effect.

Group ids are matched case-insensitively against the group folder name, so TeamA and teama are the same group.

Add several people to a group

There is no bulk assign. Open each actor, add the group id, save. The actor form remembers the groups you already have as autocomplete suggestions, so after the first person the rest are a few keystrokes each.

Path aliases

Only needed when a person's private folder is not named after their actor id.

If actor web:U123 has files under TeamA/Alice/, give them the path alias Alice so the engine knows that folder is theirs. Aliases are matched case-insensitively. Most tenants never need this.

Database row access

If your tenant has database sources connected, the actor form gains a Database row access section with one field per source. Enter the values of that source's owner column that identify this person's rows — a Salesforce user id, for instance — one per line.

These decide which rows the actor reaches through database_query and, for tables with a row policy, which rows appear in their search results. Leave a source blank and the actor reaches its protected tables only through their group.

There is a shortcut worth knowing: in Settings → Database sources, the switch "An actor id is an owner value" makes an actor reach rows whose owner column holds their own actor id, with nothing to configure per person. Name your actors by the id the database already uses and row access follows automatically.

Turning someone off

Three options, in increasing severity:

• Disable — flip the Enabled switch off in the actors table. The record stays, and every request asserting that actor is denied. Reversible, and the right choice for someone on leave or an app being decommissioned.
• Change their role or groups — narrows what they see without cutting them off.
• Delete — removes the record entirely. Requests asserting that actor are denied because the actor is now unknown. Not reversible; you would have to recreate the record.

Deleting an actor does not delete their content or their memories. If someone leaves and their data must go too, remove the content from its workspace and use the Memory console's forget-by-filter to drop records scoped to them.

Checking your work

Do not guess whether the setup is right — the console can tell you, without holding anyone's key:

• Access → Setup check runs health checks and reports problems with stable codes (no access rule on a workspace, a scope not granted, a connection that never synced, and so on).
• Access → What would this actor see? resolves a specific actor's labels and explains the result. It is computed from configuration only — it reads no indexed document, so it is fast and cannot leak content.

Both are read-only and neither impersonates the user.