Skip to main content
Wallet adapters let the Agent SDK ask your application to sign or submit a typed Action. Current transaction execution also exposes durable Commit views with their own review and recovery lifecycle. The wallet stays in your application, and your UI keeps the approval boundary.

Adapt a Viem wallet

Install Viem alongside the Aomi client:
This adapter covers typed Actions, using one transaction at a time because Viem’s sendCalls returns a bundle identifier while the Action capability expects transaction hashes. It does not implement durable prepared sends or sign-only Commit capabilities. Add only the methods your wallet actually supports.
The examples target the current source contract. Wallet signing and submission require a compatible adapter, the requested chain, and explicit user approval.

Review an Agent request

Agent execution is manual by default:
The AgentRun events are action, completed, and error. Simulation details and warnings, when present, are part of action.request. Durable Commits are available through run.session.commits and session snapshots; they do not emit an AgentRun action event. Your approval UI should show the request kind, chain, sender, targets, values, simulation evidence, and warnings available on the action. execute() calls the configured wallet capability and sends its result back to the Agent.

Durable transaction reviews

This section requires the newer client and a deployment that exposes Commit views. Use a host-authenticated aomi client with a first-party session or origin-bound widget credential accepted by /api/commits/*. A /v1/agent OAuth grant alone does not authorize these host routes. A durable Commit has a stable commit_id, a version, a state, review evidence, and its next required wallet action. Refresh it after reconnecting or losing a response; never infer success from a closed wallet popup. For a custom UI, subscribe to the session and render the controller’s current reviews:
The controller follows the server’s action and validates the expected signer. A sign-only adapter supplies signTransaction and, when requested, broadcastTransaction. An external EVM wallet using prepared sends needs both preparePreparedTransaction and sendPreparedTransaction, plus a durable CommitRecoveryStore. Forward the complete prepared payload, including fee and nonce fields; do not reconstruct a different transaction from a display summary. Persist recovery records before opening the wallet and after it returns a transaction hash. An unresolved wallet attempt needs reconciliation, not another send. submitted is a Commit lifecycle state, while confirmed is its successful terminal state. These states are separate from Pipeline’s status: "committed" response.

Review a Pipeline Build

Pipeline keeps review and commit separate:
Pipeline commit does not automatically use the wallet configured on Aomi. It returns status: "committed", digest, operation output (result for EVM or results for SVM), and requests: ActionRequest[]. These requests have no durable Agent Action IDs. Your application owns their wallet execution and receipt tracking; committed does not mean confirmed on chain.
Catalog access does not grant execution permission. Use a credential authorized for pipeline:execute on your selected environment before testing stage, simulate, build, or commit.

Keep the boundary explicit

  • Never store a private key in browser code or docs examples.
  • Do not infer approval from a successful simulation.
  • Verify that the active wallet matches the requested sender.
  • Ask before switching chains or clusters.
  • Treat unattended execution as a separate, explicit product decision.
  • Keep guest identity, account authentication, and wallet authority separate.
Read Transaction safety for the broader execution model.
Last modified on September 1, 2026