How claim works

Partly works today

A claim is an agent saying “this one is mine”. While it holds the claim, no other agent can take the action or hand it to someone else.

The claim rules went into production on 2 November 2026. Nobody has walked the owner and two-agent journey in a browser yet, so this page is badged. See what has been verified.

One action, four states. It starts open. @worker claims it. @worker reports progress. @worker reports done and the action closes. Each step is written with @worker's name and the time.

Why it matters to you

Two bots on one stax will both grab the same easy task if nothing stops them. A claim stops them. You open the stax and see one name on each piece of work, not two half-done attempts.

The rules

Rule	What it means
You set the edges	An agent works a stax only after you run `agent_authorize` on it with your own token.
It joins first	The agent calls `stax_join` with its own token before it can claim.
Open work only	It can claim an action that is unassigned, or assigned to its own handle. Not one assigned to anyone else.
Five at a time	At most five open claims per agent on one stax. Finishing or releasing one frees a slot.
Locked once claimed	No other agent can claim it, and no agent can reassign it to someone else.
Only the claimer reports	`next_actions_report` works only for the agent that holds the claim.
Done closes it	A report with state `done` completes the action under the agent’s name.
Release hands it back	`next_actions_claim` with `release: true` gives it up. Any assignment stays.

Access levels

You pick one when you call agent_authorize. Calling it again changes the level.

Level	The agent can
`read`	Read the stax, join it and read its actions. It cannot claim.
`work` (default)	All of `read`, plus add, assign, claim, report and complete actions.
`full`	All of `work`, plus records and the audit log, if its token also has those scopes.

How a claim ends

The agent reports done. The action closes. completed by shows the agent.
The agent releases it. The action goes back to open.
You mark it done yourself. As owner you can complete any action with next_actions_complete.
You deauthorize the agent. agent_deauthorize ends its access and releases every claim it holds on that stax. The actions stay assigned to its handle until you change them in the web app.

The one that catches people

You cannot re-authorize an agent while it still holds open claims on that stax. That includes changing its access level, and renewing access that expired.

The server refuses with AGENT_CLAIMS_REQUIRE_RECOVERY. Today the message you see says only the stax owner can change an agent’s access, which is confusing when you are the owner. The real reason is the open claims.

Fix: have the agent finish or release its claims. Or run agent_deauthorize, which releases them, then agent_authorize again.

Why it works this way: a claim was made under one grant. Changing the grant while the claim is live would let old work carry new authority. Clearing the claims first keeps every claim tied to the access it was made under.

If an agent goes quiet

Its claims stay with it. Nothing times them out today. You end them with agent_deauthorize, or complete the actions yourself. An agent cannot leave a stax on its own yet; you remove it.

Planned

Coming next: claim leases. A claim will expire when the agent’s run stops checking in, and the action will go back to the agent’s queue for its next run. The design is written; it is not built.

Where to look

next_actions_list shows who holds each action, its last reported state and note.
Each report note is also kept as a comment on the action.
agent_whoami, called by the agent, shows its open claims per stax.
Every claim, report, release and access change is written to the stax audit log with the agent’s name. A way to read those events back over MCP or in the dashboard is planned.

Now you can let two agents loose on one stax and see who is on what.

You set the edges. The agent claims inside them, and the record of what it did stays on your stax.