Skip to main content
After this guide, one agent (the supervisor) reads another agent’s logs, workflow runs, chosen data collections, versions, source and environment variable names from its own code, and the supervised agent (the target) accepts changes from the supervisor only through tools that check who is calling. Use it for an agent that watches or maintains other agents, such as an operations agent that reviews the failures of a support agent every morning. The supervision members are live on the platform; their lua-cli types arrive in the next CLI release. Before you begin
  • Two agents in the same organization. A grant across organizations is refused, and so is an agent supervising itself.
  • An org admin or owner to create the grant (Organizations and roles). Nothing in an agent’s code, its environment or a push can create one.
  • An API key or session for that admin (REST API overview).
1

Choose the actions

A grant gives the supervisor one or more actions on each target. Grant the least that does the job.act and release are write actions and are never transitive: an agent that is itself supervised cannot hold one, an agent that holds one cannot be supervised, and two agents cannot supervise each other.
2

Grant supervision (org admin)

An org admin posts the grant to the organization. Find the organization id as orgId in lua agents --json --ci.
dataCollections and releaseWorkflowIds take explicit names only: at most 50 each, matching [A-Za-z0-9_.:-]{1,128}, never *. The grant, not the target’s code, decides which collections are readable.The route needs the members:assign-role permission on the organization, which admin and owner hold. It answers 201 with one grant per target:
Output
Posting again for the same supervisor and target replaces that grant’s actions and lists. Every change is recorded in the organization’s audit log.
3

List and revoke grants

GET lists the organization’s grants and needs members:manage; DELETE revokes one by its id, answers 204, and also works when the target has been archived.
4

Read the target from the supervisor

In the supervisor’s code, the Agents members read what the grant allows. A job that summarises the target’s errors every morning:
src/jobs/ReviewSupportAgentJob.ts
Log rows carry timestamp, level, logSource, primitiveName and toolName, never a user id, and a message only with observe-content. Runs carry metadata only, never inputs or outputs. A collection the grant does not name fails with supervision_data_not_granted.
5

Accept changes from a supervisor

When another agent invokes the target, the target’s code sees Lua.request.invokedBy, set by the platform from the verified call. The platform supplies the identity; the target keeps its own policy. A tool that changes something should allow a write from an agent only when all three hold:
  • invokedBy.supervisor is true, which needs an admin’s act grant on this agent;
  • invokedBy.agentId is on the target’s own list of supervisors it trusts;
  • every field the call changes is on this tool’s list of fields a supervisor may change.
A turn without invokedBy came from a person, so apply your usual owner check. delegatedUserId, and the userId of a turn an agent created, never grant owner rights.
src/skills/tools/UpdateEscalationPolicyTool.ts
Here a supervisor may tune threshold and quietHours, but only the owner may change who is paged. When another agent invokes the target, the target always runs with its own persona, model and tools: the caller cannot replace them (What reaches another agent).
6

Verify

Run the supervisor’s job once, then read the target’s logs as its owner. Every supervision call the target allowed, and every call refused for lack of a grant, is a supervisor_access line in the target’s logs, naming the supervisor and the member it called.
The lines have the source supervision. From the next lua-cli release, --type supervision shows only them; lua-cli 3.39.4 does not accept that value yet.If the line cannot be written, the call fails instead of running unrecorded (supervision_audit_unavailable).

Options you may need

Test the supervisor locally

In lua test, the read members use your own developer credential and return what you can see, with the same projections: logs without user ids or message bodies, runs as metadata, environment variable names only. data, source.get, list and get are not available offline (supervision_unavailable_offline), because the readable collections are part of the grant.

Limits

If it isn’t working

Cause The supervisor holds no grant on any agent of its organization. Fix Have an org admin post a grant, then list grants to check supervisorAgentId is the agent your code runs as.
Cause The grant lacks the action the member needs: every read needs observe. Fix Post the grant again with the missing action; the new list replaces the old one.
Cause The target is in another organization or does not exist; the two are reported the same way on purpose. Fix Check the id with lua agents --json --ci.
Cause The collection is not in the grant’s dataCollections. Fix Post the grant again with the collection named.
Cause Only act sets it; observe, preview and release never do. Fix Add act to the grant if the target should accept that agent’s writes.

Next steps

Agents reference

Every supervision member, its return shape and its errors.

Lua reference

Lua.request.invokedBy on an invoked turn.

Compose agents

Hand part of a task to another agent with Agents.invoke.

Organizations and roles

Who is an org admin.