Agent operators

An agent operator is the person or organisation that answers for software that pays: an agent whose payments bind its operator and spend its funds. Each agent carries a human-backed agent credential that names the responsible person of your account as its accountable principal, within the bounds you approved. A seller reading it learns one thing: an accountable, verified principal stands behind this payment, within declared bounds. Nobody learns who.

This page follows the dashboard at https://zadq.app from the account to a live bounded agent: what your runtime does, what each approval means, the seats and caps, Stop, Renew and Kill, and what happens when no proof is read. The seller's side of the same exchange is on the seller integration page; the free checks a paying agent runs on a seller are on buyer verification.

The account

Everything runs under one account, opened at https://zadq.app/#/sign-up?for=agent-operator.

• Create your account. The responsible person gives their name and work

e-mail, says who we contract with (an organisation or a sole trader), accepts the Terms and creates a passkey. The registration signs in.

• Sign in with your passkey from then on. The session is a cookie the

dashboard's own code cannot read; nothing is kept in browser storage.

• Next steps (https://zadq.app/#/account/next/agent-operator) is the account's

start page. Each step ticks itself from the account's state and links to its page; the step to do now carries the one action.

A wallet is never a login. An account that opened with a wallet before passkeys adds a passkey at its next sign-in; the wallet then stays on the account as a payTo binding, which signs only the writes that touch that payTo address.

The plans

Two plans for the person who answers for the agents: Personal, with one bounded agent, and Premium, with up to 5. Each includes one identity verification a year, and a higher check (grade A3) when a service asks for it. Billed monthly or yearly, in advance. Prices are shown in your account, before VAT.

Every account takes these plans, an organisation or a sole trader, agent operators included. Personal includes 1 agent; a 2nd means Premium. You can move from Personal to Premium at any time, and the unused part of what you paid is credited. Mints and renewals are part of the plan.

The app reads the plans from GET /v1/plans: a plan lists seats_max, grade_included and its periods; amounts are net (vat: "exclusive") and the VAT is computed at checkout; contact names Enterprise with seats_from; there are no steps.

{
  "plans": [
    {
      "id": "personal",
      "seats_max": 1,
      "grade_included": 3,
      "periods": [{ "period": "year", "on_sale": true, "amount_minor": <amount>, "unit": "EUR" }]
    }
  ],
  "default_period": "year",
  "vat": "exclusive",
  "steps": [],
  "contact": { "id": "enterprise", "label": "Enterprise", "seats_from": 6, "by_contact": true }
}

The choice is POST /v1/products/agent-operator/activate with {"plan": "personal"} or {"plan": "premium"}; enterprise answers plan_by_contact (409) and any other value plan_unknown (400).

Enterprise

From 6 agents, or for agents you run for others, Enterprise is by contract. Let's talk about your enterprise account: write to us and propose a time for a call. Once the contract is agreed, ZadQ activates it on your account; there is no self-serve price and no self-serve step.

An account on a contract reads plan: "enterprise" and seats.plan (the contract's agents), with enterprise {seats, period, channel, paid_until, ends_at}; its invoices reach you from the billing provider (channel: "invoice"). A plan choice on it answers plan_not_switchable (409). Mints and renewals are part of the contract.

From the account to a live agent

The steps, in the order Next steps shows them:

1. Add your invoicing details. Legal name, registered address, and the EU

VAT number or national tax number, before any payment.

1. Pay for your plan. Choose Personal or Premium and the period, then pay

the first period on the billing provider's hosted checkout; it comes back to the dashboard, and the plan reads paid once the provider's signed confirmation lands. On Enterprise there is no checkout: the contract's invoices reach you from the billing provider.

1. Verify the responsible person. Identity verification (KYC) runs once,

on the identity provider's page, inside the issuer's boundary; no document is asked in the dashboard. It opens once the plan is paid. The account keeps the session handle, the grade and the reuse window, never a document or a date of birth. One verification backs every product of the account until its reuse window closes; after that, you verify again.

1. Create an enrolment and give its code to your runtime. See

Enrolment.

1. Approve the delegation with your passkey. See

Approvals. Once your runtime reports the agent registered, it appears in Agents.

Enrolment

An enrolment is one agent's way into a credential. You create it in Enrolments with:

Creating it shows a one-time code once: eight characters of Crockford base32 (digits and capitals without I, L, O and U), written in two groups of four, and a QR code of the claim URL https://zadq.app/claim#<code>, which carries the code in its fragment. Neither is stored where it can be shown again. The code ends after 24 hours if no runtime claims it; create a new enrolment then.

Your runtime then walks the enrolment on its own:

1. Claim. The runtime posts the code with a descriptor of itself (kind,

version, instance reference) and receives a short-lived session credential scoped to that enrolment. A delegate approval lands in your Approvals.

1. Wait. The runtime polls the enrolment while you decide.
2. Collect the material once. After your approval, the next poll

delivers the mint material exactly once; the service deletes it on delivery. Today the material is the agent's credential offer.

1. Complete the issuance in its own process. The credential is born in

your runtime, next to the agent's key, from the responsible person's holder, which also lives in your own infrastructure. ZadQ holds no custody of either.

1. Report. The runtime reports the agent registered, optionally with a

control hook (see Kill), or reports a failure with its reason code.

The enrolment reads one state at a time, and the dashboard says what is true and what to do:

You can cancel an enrolment until the runtime takes the material. A runtime that missed the one-time material claims again, and you approve again; nothing else changes.

Approvals

Approvals is the responsible person's inbox. A request does nothing until you approve it with your passkey, and it ends if you do not decide in time. Each approval asks for a fresh passkey assertion. Three kinds arrive:

• Delegate. Your runtime claimed an enrolment. The request reads as one

sentence: the agent's name, the bundle, its sellers, places and limit, and the credential's lease. Approving asks the issuer for the agent's offer.

• Renew. You asked to renew an agent from Agents. Approving asks the

issuer to renew; your runtime completes it.

• Present. Your runtime asks the responsible person to prove a predicate

to a verifier, such as an assurance grade threshold. The request carries the verifier's declaration (its origin, its challenge endpoint, the profile and the claim policy), never a challenge. Approving hands the declaration to the holder in your own infrastructure, which answers the verifier's challenge once. The result, {session_id, request, envelope}, passes through the approval once to your runtime's poll, about every second, and is deleted on delivery; your runtime validates it on its own verifier inside the challenge's ten seconds. The handshake binding is provisional.

Delegate and renew approvals carry price_line: null on every plan and on Enterprise: mints and renewals are part of the plan or the contract, an approval says nothing of a price, and approving it authorises nothing on a card.

A request ends in one of these states: approved, declined (nothing minted, sent or charged), expired before you decided (the same; the runtime can ask again), or failed, with its reason. An issuer refusal reads failed and nothing is minted.

Your runtime's calls

The dashboard's own calls run under the passkey session. Your runtime's calls run under the session credential it received at the claim, sent as a bearer. The shapes follow the platform API contract (v1.2):

Errors read {error, detail} with a stable code.

Seats and caps

The Agents page shows three counters:

• Agents, in use against your plan's seats_max: 1 on Personal, 5 on

Premium; on Enterprise, against the contract's seats.plan. An unclaimed enrolment holds a seat too.

• The issuer's cap: ten active agents per person. You can hold the lower

of your plan's agents and that cap at once.

• Mints this hour, renewals included, under the issuer's own hourly cap.

Reaching a limit is said on the request that met it, with its code; the approval stays pending, nothing is retried behind your back and the agents already live are unaffected. The 2nd agent on Personal answers plan_cap_reached (409): Personal includes 1 agent; a 2nd means Premium, and the move is POST /v1/products/agent-operator/activate with {"plan": "premium"}, paid as every line, with the unused part of Personal credited. The 6th on Premium answers seats_exhausted: switch one off, or let's talk about your enterprise account. On Enterprise, the agent beyond seats.plan answers seats_exhausted too (switch one off, or contact us to change the contract), and a contract that has ended answers product_inactive. The issuer's own caps answer person_cap_reached and mints_per_hour_reached. Creating, approving and renewing also wait on the verification (kyc_required) and a paid plan (product_inactive). On a principal plan, a create or a renewal in runtime mode answers credential_not_held (409) while the person is verified and the plan is paid but the identity credential is not held yet: keep it in this browser, or hold it in your operator's runtime, then create the agent again. A suspended product keeps its agents listed and usable.

Stop, Renew and Kill

Agents lists every agent your runtimes registered, with its bundle, sellers, places, limit, lease end, runtime and state: registered, then usable once the runtime reports its scope anchored, expiring near the lease end, and the ended states revoked and expired.

• Stop the agent. Asks the issuer to revoke the agent's credential; it

then presents nowhere. A seat frees up and nothing is refunded. Stopping needs nothing from your runtime.

• Renew the lease. Opens a renew approval in your inbox. The agent stays

usable on its current credential until your runtime reports the renewed one; the new lease end then shows in Agents. An agent whose lease has ended is past renewal: enrol a new agent to continue.

• Kill the agent. Offered only when the runtime registered a control

hook. The dashboard calls that hook, and the agent revokes its own credential with the custody your runtime holds, through the network's privacy relay. Without a hook, Stop is the switch.

Withdraw consent on the Verification page revokes everything the responsible person's verification backs: every agent of the account stops, enrolments in progress end, and the product waits for a new verification. Revoked agents stay revoked.

Your agents' payments

A payment is your agent's, made from its own wallet under the x402 scheme the seller names: the seller's 402 response carries the identity requirement beside the payment requirements, and your agent's wallet signs and pays. ZadQ settles nothing. It never holds, routes or settles a payment, never acts as a facilitator and never takes a cut out of a payment (its own fees are invoiced separately); it never asks for, stores or derives an agent's payment key or a seed, and that key stays in a custody you control.

The credential proves that an accountable principal stands behind the payment; it does not hide the payer. A fresh proof each time and a different pseudonym at each seller cover the identity proof only: an agent that pays every seller from one address is linkable through that address and the settlement record. Whether the payer is linkable depends on the wallet and the payment scheme.

A claim about one of your agents

The accountable principal is the recourse: the network's dispute process runs notice and private settlement, an arbiter's offer, and identity only under the arbiter's certified finding. It is specified, not built.

Specified, and not yet running: every agent presentation carries an encrypted reference to the agent that only its issuer and the network's Foundation together can open, and only for a recorded claim. The verifier that accepts your agent keeps it, unreadable, for the claim window, so a claim reaches an agent that no longer answers.

Once agent presentations carry it, a verifier that cannot keep that record refuses the agent with the reason code dispute_retention_unavailable. The verifier could not keep the record a claim would need, so it refused the agent: an operator problem on the verifier's side, never your agent's fault. Your runtime may try again later with a fresh challenge; it should not retry in a loop.

Graceful degradation

Every payment keeps working when no proof is read. An agent that holds no credential, or whose credential cannot be presented, keeps paying every seller that has not chosen to require attested agents: nothing blocks by default. Whether a seller welcomes, prefers or requires attested agents is that seller's own choice, and a seller that reads no proof treats the payment exactly as before; its badge and its verdict fall back to unknown.

The dashboard follows the same rule. When the service is unreachable, the pages show the last known state and retry by themselves; your agents and their credentials keep working meanwhile, because their custody is in your runtime.

What the account holds

The account's name and its passkeys' public keys; the responsible person's name and work e-mail; the invoicing details; any payTo bindings; the verification's session handle, grade and reuse window; the product's state and plan; the price lines' states; and for each enrolment, approval and agent its name, bundle, parameters, lease, runtime descriptor and state, with an activity log of reason codes. Never a document, a key, an agent's custody or a proof kept after delivery, and nothing that tells a seller who stands behind an agent.

Next: buyer verification describes the free checks an agent runs on the sellers it pays, and agent tools and badge the tools that run them.