Agent runtime

The Paxeer X agent runtime connects autonomous software to LayerX activity execution and Paxeer settlement through a controlled daemon boundary. layerx-agentd owns sessions, capabilities, approval holds, local limits, and durable evidence. MCP exposes those controls as tools; the hosted agent boundary carries signed activities to the node and serves execution receipts.

Runtime components

1. Configure the network profile

Choose the endpoint, network identifier, and sequencer trust anchor together. The CLI retains the implementation name layerx. Use the release-provided values for the network you intend to join.

layerx environment use beta \
  --endpoint <https-endpoint> \
  --network-id <network-id> \
  --sequencer-trust-anchor <hex>

The profile names are emulator, beta, and production. Non-loopback endpoints use HTTPS. A profile controls CLI network access; the daemon library configuration separately uses a normalized absolute node endpoint path.

2. Enrol the daemon identity

Configure the agent DID, tenant, authority, capability, session identity, and binding output under the daemon's LAYERX_AGENT_MCP_* settings. Setting LAYERX_AGENT_MCP_BINDING_ROOT enables binding publication. The daemon resolves the DID through the human authority, registers the identity, restores the named capability, opens a session, and publishes the runtime binding before accepting requests.

Library integrations use enrolment::enrol and session::open. These are daemon lifecycle operations, rather than a layerx session-opening command. A publication failure closes the newly opened session; restart restores the named session and its matching document instead of creating duplicate credentials.

Binding directories use mode 0700 and files use 0600. Existing secret files are refused instead of overwritten. A different binding at an existing publication path is also refused. The daemon surface binds to loopback, keeping the local transport distinct from public gateway access.

3. Install the runtime connection

Install MCP after daemon enrolment publishes its binding. Supported hosts are layerx, claude-code, claude-desktop, cursor, and vscode. Repeat --host to install into multiple runtimes.

layerx install mcp --host claude-code \
  --daemon-binding /absolute/path/to/binding.json

# Restrict the installed tool surface to reads.
layerx install mcp --host cursor --read-only \
  --daemon-binding /absolute/path/to/binding.json

# Run the same stdio server directly.
layerx mcp serve --daemon-binding /absolute/path/to/binding.json

The installer opens and validates the same document used at serve time. Relative explicit paths become absolute. Without an explicit binding path, installation resolves mcp/binding.json beside the CLI configuration. Host launch configuration holds the executable, arguments, and an empty process environment; secret material stays in protected daemon files.

MCP installation uses the binding's session and capability. It does not provision a gateway credential or ask for a source account, asset, signing seed, or network profile. The read-only flag narrows the declared binding mode. Tool discovery exposes only scopes admitted by the bound session.

4. Admit an action

Each action passes session authentication, capability evaluation, policy, rate and quota limits, deadlines, and budget reservation before submission. Capability checks evaluate expiry, activity type, counterparty, asset, amount, rate, and purpose. An approval hold retains the exact canonical preparation and its reservation until an authorized decision or expiry.

Use the agent action lifecycle to prepare, review, sign, submit, and track. Requests carry stable idempotency keys. Repeating an identical mutation returns its original result; changing the body under the same key produces an idempotency conflict.

Hosted submission and recovery

The hosted agent boundary accepts canonical signed activities using application/octet-stream. Submission requires Idempotency-Key; activity bodies are limited to one MiB. A durable journal binds the key, route, and activity digest so retries and restarts preserve the original submission identity.

These are the agent boundary's HTTP interfaces. Its Bearer credential planes are separate from daemon sessions and from CLI gateway credentials. Keep transport-specific credentials with their intended boundary.

Evidence and write readiness

The daemon loads trusted sequencer policy independently of incoming proof data. Receipt verification binds the network, protocol version, authorized sequencer range, epoch, batch identity, sequence range, Merkle inclusion, and execution outcome. Replay guards reject duplicate receipt and activity identities before durable accounting changes.

tenant.readiness reports transport_ready, verified_reads_ready, writes_admitted, and an optional recovery reason. An authenticated tenant requires transport and a StateProven account read to admit writes. Readiness is tenant-scoped; an HTTP connection alone does not establish recovered spending authority.

After a process failure, restore durable holds, verify receipts, and resolve uncertain spends before opening writes. An unresolved reservation remains held. Local limits enforce daemon policy; bypassing the daemon bypasses those limits. Protocol-enforced authority and cryptographic receipt evidence remain separate from local accounting.

Operate and revoke

Monitor preparation age, open approvals, held budget, unresolved submissions, stream gaps, and verification failures. The hosted boundary's /livez reports process liveness; /readyz additionally checks node connectivity and handshake identity. Loss of the node can leave liveness healthy while readiness fails.

Revoke a capability or close a session to withdraw agent access. Refresh and revocation invalidate stale credentials and pending access through the session generation and stop signals. Preserve audit and receipt records so a revoked agent's historical actions remain traceable.