Give an agent a name, a purpose and a monthly limit, and the service runs creation as staged work that shows active only once every stage's receipt verifies. Pause it, change its limit, take money back, rotate its key or archive it. Actions it holds for your decision land in an approval inbox with amount, counterparty, asset, fee ceiling, hold expiry and the budget left after, approved once with a passkey step-up.

What it does

An owner creates a managed agent by giving three things: a name, a purpose and a monthly limit. The human service turns that into a staged journey (custody key, DID registration, recovery registration, session provisioning, capability narrowing, budget creation and funding) and the agent is only shown as active once every stage's receipt has verified; a partial creation stays in the creating state and shows which stages completed. Once the agent is running, the owner can pause and resume it, change its limit, take money back, rotate or recover its key, and archive it. Actions the agent holds for a decision appear in an approval inbox, where each item is rendered from the held activity's own disclosure and can be approved once with a passkey step-up, or rejected.

Key capabilities

• Agent creation as a staged journey; the agent shows as active only when every receipt verifies.
• Pause, resume and limit changes, each labelled protocol-enforced or app-enforced.
• Approval inbox built from the agent domain's ordered approval events, refusing gaps and replays.
• Each hold shows amount, counterparty, asset, fee ceiling, hold expiry and budget remaining after.
• Approve or reject exactly once; a decided, expired or defective hold answers with its own reason.
• Key rotation, recovery, reclaim and archive, each with its delay or consequence stated first.

Differentiators

Taking money back from an agent uses one of exactly three protocol-authorised return paths: defunding its budget, an ordinary transfer the agent authorises, or a receive under a registered payer grant. There is deliberately no raw-key sweep, and an app-enforced limit carries the sentence "This limit is enforced by the app and agent service. Bypassing them bypasses it; it is not a protocol guarantee."

Outcomes

• Set a monthly limit before an agent moves anything.
• Approve or reject each held action exactly once.
• See whether a limit is protocol-enforced or app-enforced.

Technical notes

• Partial: the current-period spend view is written but returns ProtocolBudgetStateUnavailable and serves nothing until the agent domain exposes a canonical budget-state record with a proof path (human/crates/layerx-human-service/src/agents/spend.rs).
• The hosted authority requires node-verified guarantor checkpoint certificates before it will answer identity, capability or key-policy questions positively; a missing or mismatched certificate stays refused rather than defaulted.
• Creation takes a name of at most 80 characters and a purpose of at most 64. Where a network enforces native fee authority version 2, the owner must also approve a finite native fee budget; omitting it refuses creation. Archive needs the agent's name typed back exactly, and refuses while funds remain undisposed.
• Owner-initiated rotation carries an explicit challenge delay and completion window, both positive whole seconds no greater than 4294967295, and a read-only disclosure call returns the exact operation digest, both durations and the idempotency key before the passkey step-up.
• The inbox renders three activity classes: move money, add money and set a withdrawal wallet. Anything else is reported as unreviewable rather than paraphrased, and a hold whose disclosure cannot back its own facts is marked defective and never offered for approval. Holds expire against a sequence, not a clock, and the projection refuses to serve a view older than its declared freshness bound.
• Spending caps and session scope are enforced by the chain-side session keys, capability grants and spend budgets; this surface reads and presents them. No drawdown, error-rate or quality-drop stop rule is implemented anywhere in the tree.

More in Interface