On this page
Coordinate agents, businesses, and decisions.

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

IntegrationUse it forAuthority path
Agent APIA custom service that needs preparation, signing, submission, reads, approvals, and event subscriptions.Tenant-bound daemon session and explicit capability.
MCPExpose network tools to an assistant or development runtime.Daemon binding, session, and capability; tools use the Agent API.
A2AGateway-backed activity submission and receipt access from another agent.Hosted gateway key and locally held signing identity.
Native programsDeterministic application logic called by an agent.Signed program activities, execution receipts, and program registry evidence.

Start with Agent runtime for daemon enrolment and runtime installation, or Native 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.

OperationRequired contextPurpose
agent.registertenant, agent_did, authority_ref, client, policy_versionRegister the agent under its verified authority.
session.openSession contextOpen a tenant-bound authenticated session.
session.refreshsession_id, contextRefresh the session within its authority and policy.
session.closesession_id, contextClose access and invalidate session use.
session.listcontextInspect 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.

DimensionDecision it controls
activity_typesWhich native operations the agent can prepare.
counterpartiesWhich counterparties may participate.
assetsWhich assets the agent may use.
amount_ceilingsMaximum authorized quantities per asset.
rate_ceilingsAction counts within explicit time windows.
purpose_constraintsThe permitted purpose commitments.
expiryThe 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/.
Paxeer X · System documentationBack to top ↑

Ask Paxeer X Docs

Answers from the documentation.

What would you like to know?

Ask a question, find a guide, or get help with your next step.

Enter to send · Shift+Enter for a new line