Autonomy and actions

kind defaults to confirmations, and the other kinds are real

This store also holds long-running tool calls, whose answer is a system's result rather than a person's judgment, and approvals raised for somebody outside the conversation. Pass kind=tool to list the work your own backend owes.

An automatic decision is recorded as an action too

Precisely so it can be read back beside the asked-for ones — automatic=true is what a policy decided without a person, and automatic=false is what somebody chose. It is a filter over the same rows either way, which is what makes "what has my agent been doing unattended" answerable.

Scoped exactly as the inbox is

Through the same helper, deliberately: a count beside a filter that disagrees with the list the filter produces is worse than no count at all.

A turn's answers travel as ONE batch, and this is why

The agent framework resolves EVERY outstanding confirmation with the next message. So a turn that raised three cannot publish three decisions separately — doing so would silently abandon the other two while reporting the run finished. Decisions are accumulated and published once the last member is decided, and the response says which happened.

Answering twice runs the tool twice

There is no idempotency of the framework's own, and delivery can redeliver a resume. What protects you is the conditional claim here — one decision per action — which is why a second answer is a 409 rather than a second run. Treat the 409 as success.

A late approval of an abandoned card still would have run the tool

Measured: a card charged after the conversation had moved on. So a batch with a later user turn is refused and recorded abandoned — which is why that status can follow an approval. It means nothing ran.

Who may answer comes from the TOOL's declaration, not from a policy

A tool declaring asks="admin" needs the tenant's admin role and cannot be answered on an end user's behalf — holding admin so you can mint your customers' tickets is not the same as deciding as the tenant. asks="end_user" is the row's owner, or a project credential naming them, which is how you build your own customers' approval queue.

Deciding a confirmation here is a 409, naming the right route

Confirmations and approvals share one table and only kind tells them apart, so crossing the two routes refuses explicitly rather than doing something surprising.

A rejection is held to the same form as an approval

Coercion runs BEFORE the service looks at the decision, so an approval declaring a required field with no default cannot be REJECTED without supplying it — the refusal reads "'Cost center' is required" on a call that was declining to incur one. Give a field a default if a denial should not need it.

The answers do not come back on the action row

They travel to the agent in the resume, and the stored action keeps the REQUEST — so reading the action back afterwards shows what was asked rather than what was answered.

This is the third kind on the same table

List them with kind=tool on the inbox route, or with elan.tools.pending(). They are the work YOUR backend owes the run, rather than a decision a person owes it, which is why the answer is a value and not an approval.

The run's owner or an admin, and there is no user

Unlike deciding a confirmation, this route takes no user to act for one of your end users. A call raised in a run you started with end_user_id belongs to that user, so answering it needs a tenant admin.

They come back in one flat list, and the SDK splits them

Because a caller that did not split them would read a tenant cap and write it back as their own. Each row carries its scope; the SDK exposes mine and tenant separately for that reason.

A tool nobody has touched is ABSENT, not defaulted

There is no row, and that means "no opinion" rather than "as the agent ships". Do not synthesize one from the manifest: if an untouched policy voted, every user who had never chosen anything would cancel their tenant's grant.

This REPLACES; it is not a delta

Editing a single threshold rewrites that scope's whole policy for the tool, so anything calling this must read the existing policy and write it back with the change substituted. Building a fresh policy silently drops every other condition that scope carried. The SDK's rule() and tier() do that read-modify-write for you, which is the reason to prefer them over this route.

Two things are stripped on the way in and re-imposed from the manifest

The ceiling, so nobody can raise the limit meant to bound them; and declared REFUSALS, so nobody can drop a prohibition the agent's author wrote. Stripped on write AND ignored on read, because a row is data from a database.

A write must name its project

A read narrows to what you may see; a write lands in exactly one scope, and target_slug cannot say which — an agent slug is unique within a project, not a tenant. Leave project empty and the policy lands in the tenant's unattributed scope, which every project's agent of that slug reads; a project-scoped credential is refused that with 403 and may only name its own.

The SDKs cannot name a project here yet

Python's rule(), tier() and set() send no project, so with an unscoped credential they write the unattributed scope and with a project-scoped one they are refused with 403. The Node client's writes send target_slug and tool as query parameters, which this route does not read, so they are refused with 422. Call the route directly when the project matters.

This is not "set it to the default"

It revokes the row: kept for the audit trail, with revoked_at set and live false, and skipped by the resolver. The difference matters: a scope with no live row has no opinion and does not vote, whereas a row holding the manifest's own values WOULD vote — and would cancel the tenant's grant for everybody who had ever touched and reverted a setting.