Delegated agent pattern

The "delegated agent" is the canonical x402 narrative: a user grants a fresh SCW some stablecoin spending budget, an agent runs autonomously against paid APIs from that SCW, and the user recovers any leftover funds at the end. This guide describes the pattern and points at the reference implementation in the Playground.

Why delegate

In aa-native, every UserOp is signed by the SCW's owner key. If you want an autonomous agent to make paid calls without that owner being online, you need either:

1. To give the agent the owner's key (full delegation, full risk), or
2. To use a session-key-capable account contract that scopes the agent's spending (proper delegation, but requires non-canonical SCW logic — see Session keys), or
3. To spawn a fresh ephemeral SCW owned by a fresh, throwaway key. The agent gets full control over that SCW, but the SCW only ever holds the budget the user funded it with.

The Playground uses option (3) for its in-browser delegated-agent demo. It is the simplest pattern that requires no SCW-side custom code.

The flow

1. Spawn. Generate a fresh ethers.Wallet.createRandom() in the user's browser. Derive the SCW address from this fresh EOA + the canonical factory. The owner key lives only in browser memory.
2. Fund. From the user's main SCW, transfer some DEMO-USDT (or USDT, on mainnet) to the agent SCW. This is a paymaster-sponsored UserOp from the user's main SCW; one signature from the user, then it's in the agent SCW.
3. Run. The agent loops through a sequence of paid calls using the fresh wallet's aaNativeSigner. Every call is gas-sponsored; the agent SCW only spends the stablecoin.
4. Despawn. When the user is done, drain whatever DEMO-USDT remains in the agent SCW back to the user's main SCW. This is a paymaster-sponsored UserOp from the agent SCW. After the drain succeeds, the agent's owner key is forgotten.

The whole flow is in the Playground at /playground. The implementation is apps/playground/src/components/agent-panel.tsx.

Risks of ephemeral SCW delegation

• Browser-only key. If the user refreshes the page, the agent's owner key is gone. Funds in the agent SCW are stuck.
• No spending caps. The agent can spend the full balance on any allowed endpoint. The cap is the funding amount, not a per-call limit.
• No revocation other than draining. You can't pause the agent without taking back the funds.

For a production multi-user deployment, the proper answer is session keys with on-chain caps and revocation. The ephemeral SCW pattern is good for demos and trusted-environment workflows where the user funds the agent themselves.

Multi-call task pattern

The Playground's "Quote 6 markets" task is six sequential /exchange-rate calls. The reference loop:

const f = x402Fetch({ signer: aaNativeSigner({ /* agent's signer */ }) });

for (const call of task.calls) {
  const res = await f(`/api/${call.endpoint}`, {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify(call.body),
  });
  const receipt = readSettlementReceipt(res);
  log.append({ endpoint: call.endpoint, txHash: receipt?.transactionHash, ... });
}

Each iteration is one independent paid call. Failures are isolated; one revert does not roll back earlier successful settlements. The Playground stops the loop on first error so the user is not surprised by a half-complete batch.