# Agents on Paxeer X Give autonomous software a verifiable identity, explicit authority, bounded spending, and an evidence trail for every network action. Paxeer X agents act through the same native authority, signature, fee, and receipt system as human principals. An agent reads state, prepares an activity, discloses its effects, obtains a signature, and tracks the result through execution and Paxeer settlement. LayerX supplies the native activity and program execution plane; the agent daemon supplies tenant isolation, session controls, policy, and runtime integration. ## Choose an agent integration | Integration | Use it for | Authority path | | --- | --- | --- | | Agent API | A custom service that needs preparation, signing, submission, reads, approvals, and event subscriptions. | Tenant-bound daemon session and explicit capability. | | MCP | Expose network tools to an assistant or development runtime. | Daemon binding, session, and capability; tools use the Agent API. | | A2A | Gateway-backed activity submission and receipt access from another agent. | Hosted gateway key and locally held signing identity. | | Native programs | Deterministic application logic called by an agent. | Signed program activities, execution receipts, and program registry evidence. | Start with [Agent runtime](https://docs.paxeer.app/agent-runtime) for daemon enrolment and runtime installation, or [Native programs](https://docs.paxeer.app/programs) for application execution. ## Identity and registration An agent DID identifies the actor. An authority reference identifies the grant under which it acts. A tenant scopes records, credentials, and policy. These are separate from the runtime client name and from the session used to authenticate a request. Registration binds the agent to a verified authority; a self-declared DID alone does not confer permission. | Operation | Required context | Purpose | | --- | --- | --- | | `agent.register` | tenant, agent_did, authority_ref, client, policy_version | Register the agent under its verified authority. | | `session.open` | Session context | Open a tenant-bound authenticated session. | | `session.refresh` | session_id, context | Refresh the session within its authority and policy. | | `session.close` | session_id, context | Close access and invalidate session use. | | `session.list` | context | Inspect sessions visible to the authenticated owner. | The session context includes tenant, agent DID, authority reference, permitted activity types, expiry, client, and policy version. Daemon credentials also bind a session generation, preventing an old credential from silently adopting a refreshed session. ## Define what an agent may do A capability names every permission dimension explicitly. Missing dimensions are invalid; an empty set denies that dimension. Use `capability.create` to issue a bounded capability, `capability.attenuate` to derive a narrower child, `capability.list` to inspect it, and `capability.revoke` to withdraw access. | Dimension | Decision it controls | | --- | --- | | activity_types | Which native operations the agent can prepare. | | counterparties | Which counterparties may participate. | | assets | Which assets the agent may use. | | amount_ceilings | Maximum authorized quantities per asset. | | rate_ceilings | Action counts within explicit time windows. | | purpose_constraints | The permitted purpose commitments. | | expiry | The last permitted authorization period. | Attenuation never widens authority: child sets are subsets, amount ceilings do not increase, expiry does not move later, and rate windows remain at least as restrictive. Capabilities restrict an existing protocol grant; they do not manufacture a new protocol authority. ## The action lifecycle 1. **Read.** Obtain account sequence, balance, and relevant module state with the required verification level. 2. **Prepare.** Supply actor, authority, account sequence, timestamp bound, idempotency key, fee limit, payload, and payload hash. 3. **Review.** Inspect the disclosure decoded from canonical bytes: actor, authority, activity type, counterparties, amounts, asset, fees, expiry, and idempotency key. 4. **Sign.** Sign the returned preimage and bind the signature to the preparation reference. 5. **Submit.** Submit that preparation and signature, retaining the submission reference. 6. **Track.** Use `track` or `wait` to observe evidence and the requested verification level. ``` prepare → Prepared { preparation_ref, signing_preimage, disclosure, expiry } sign(preparation_ref, signature) → Signed submit(preparation_ref, signature) → TrackedSubmission track(submission_ref) → state + evidence + verification_level wait(submission_ref, requested_verification_level, deadline) ``` Submissions move through Prepared, Signed, Queued, Submitted, Acknowledged, Unknown, Executed, Failed, or Expired. Unknown is a pending outcome that requires reconciliation. Executed carries a receipt reference; its settlement domain is Paxeer. Preserve the original idempotency key while resolving an uncertain submission. ## Budgets and human approval Budget controls distinguish protocol-enforced budgets from daemon-enforced limits. A daemon limit reserves capacity across tenant, agent, session, capability, and counterparty scopes before an activity proceeds. Successful execution consumes the reservation, failure releases it, and an unresolved outcome retains its hold until evidence resolves the result. The daemon consumes protocol evidence; it does not mint balances from local accounting. Human approval binds an exact prepared activity and its canonical disclosure digest. Approval releases that preparation; rejection releases its reservation; expiry never implies approval. A changed disclosure is defective and requires a new review. Approval is a daemon restriction and does not enlarge protocol authority. ## Read, observe, and verify Read operations cover balances, accounts, module state, history, batches, checkpoints, and proof bundles. Availability fetch and offline export support evidence portability. Projection returns an estimate and is distinct from a verified read. Evidence levels progress from Unverified to SequencerSigned, BatchIncluded, StateProven, CheckpointFinalised, and SettlementAnchored. Select the level required for the decision: a signed acknowledgement, inclusion proof, state proof, and settlement anchor establish different facts. Subscriptions are scoped by tenant, agent, and capability. Filters narrow agents, accounts, activity types, modules, assets, counterparties, and result classes. Delivery is at least once; deduplicate using `deduplication_id`, acknowledge cursors, and handle Gap and Truncated events explicitly. ## Design a reliable agent - Use a dedicated identity and the narrowest capability for each workload. - Require review for actions outside a routine policy; show canonical effects to the approver. - Separate daemon policy records from cryptographically verified network receipts. - Retain preparation, submission, activity, and receipt references across process restarts. - Treat transport loss and deadlines as uncertainty, then reconcile before authorizing a replacement action. **Reference:** `agent/schema/agent-api/identity.kvx`, `write.kvx`, `stream.kvx`, `read.kvx`, `errors.kvx`; `agent/crates/layerx-agentd/src/session.rs`, `capability/`, `approval/`, `budget/`.