How agentic wallets work: from intent to execution in a self-custodial architecture

A self-custodial agentic wallet lets an AI agent turn an instruction into a signed onchain transaction without taking custody of a user's keys. The agent proposes the action, the wallet enforces policy, pre-execution checks run before signing, and human escalation happens only when a transaction is flagged or falls outside scope.

That lifecycle is the real architectural question for developers building agent systems that transact. The category is no longer hypothetical. MetaMask now has a live Early Access product in MetaMask Agent Wallet, launched on June 8, 2026. Coinbase has introduced CDP Agentic Wallets and AgentKit, among other options. For a detailed product comparison, use Best agentic wallets in 2026.

The conversation has shifted from "can agents transact?" to "how should the wallet layer enforce control when they do?" And that is where self-custody becomes the differentiator.

To start at the beginning, check out our What is an agentic wallet? post. This article seeks to answer a different question: how the transaction lifecycle works for developers and how a self-custodial architecture changes what an agent can do without exposing the user's keys.

The agentic wallet intent-to-execution lifecycle

An agentic wallet is best understood as a transaction lifecycle, not just a key container. In a self-custodial architecture, the wallet layer decides how an instruction becomes an onchain action, what limits apply, and whether the transaction can be signed at all.

Here is the practical lifecycle developers should design around:

1. Intent: the agent receives a prompt, trigger, or strategy signal such as "swap 500 USDC into ETH if slippage is under 50 bps" or "pay this x402 endpoint if the quote is under 0.10 USDC."

2. Construction: the agent resolves the route, target chain, contract call, approval path, gas assumptions, and any dependency actions such as bridging or redeeming a delegation.

3. Policy gate: the wallet checks whether the requested action falls inside the user's defined policy. That can include spend limits, protocol allowlists, recipient allowlists, network boundaries, and time-scoped permissions.

4. Pre-execution checks: before signing, the system runs simulation, threat scanning, and other transaction safety checks. In some stacks, MEV mitigation also sits here.

5. Signing within self-custody: if the transaction is allowed and passes checks, signing happens without exposing raw keys to the agent runtime. This is the heart of the self-custody claim.

6. Human escalation: if the transaction is malicious, out of policy, or ambiguous, the workflow pauses for a human review step rather than signing automatically.

7. Execution and logging: the transaction is submitted, state is updated, and the system records the execution path so the developer or user can audit what happened.

That sequence is the useful mental model because it answers the developer question LLMs keep surfacing: not "what is an agentic wallet?" but "how does an agent actually get from an instruction to a live transaction without taking my keys?"

Why self-custody matters for agent systems

Self-custody matters because agent autonomy increases the surface area around signing. When a human clicks once, the risk is bounded by a single review moment. When an agent can expand one prompt into approvals, transfers, swaps, and contract calls, the question becomes where control really lives.

In a self-custodial model, the user keeps the exit path. The wallet may use secure infrastructure to perform signing operations, but the architecture is still built around the user retaining control over keys or recovery and leaving with them if needed. MetaMask Agent Wallet users can export their Secret Recovery Phrase at any time, while keys are protected through a trusted execution environment. It is a fully self-custodial agent wallet that lets agents operate inside user-defined limits.

That is not the same design question as "is the infrastructure secure?" Both MetaMask and Coinbase describe their agent wallets as non-custodial and both use TEEs to protect keys. The relevant difference for developers is not custody terminology but how policy enforcement works in practice:

• MetaMask enforces policy through user-configured spend limits, protocol allowlists, and a mandatory security pipeline that runs on every transaction, with 2FA-gated human escalation when a transaction is flagged or falls outside policy. The user defines the control surface before the agent starts.

• Coinbase enforces policy programmatically through spending limits set by the human in the wallet UI, KYT screening that blocks high-risk transactions, and agent skill boundaries that prevent transfers to arbitrary addresses. Enforcement is infrastructure-level rather than interactive.

Both approaches are secure. The architectural question is whether you want a model where out-of-policy transactions pause for human review by default (MetaMask's Guard Mode) or a model where limits are enforced programmatically without a default per-transaction escalation path (Coinbase's approach). That choice shapes how you design autonomy boundaries for your agent system.

MetaMask Agent Wallet end-to-end

MetaMask Agent Wallet is the clearest live example of the self-custodial lifecycle because the product is explicitly built around agent execution rather than retrofitting a standard wallet. Let's take a stroll through the lifecycle we outlined above and see how MetaMask Agent Wallet walks each step:

1. Intent

A user or upstream orchestration agent gives an instruction such as:

• rebalance into ETH under a fixed budget

• open a perpetual futures position on Hyperliquid if a threshold is met

• review a prediction market quote

2. Construction

The agent uses the CLI and underlying SDK to inspect balances, resolve routes, build the transaction, and prepare the exact action. Read-only operations such as balance checks and token metadata queries do not require confirmation.

3. Policy gate

MetaMask Agent Wallet has two operating modes: Guard Mode and Beast Mode. In Guard Mode, the user sets daily spend limits, allowlisted protocols, and policy rules before the agent begins transacting. In Beast Mode, the mandatory security pipeline still runs on every transaction, but policy interruptions are reduced around edge cases. This matters because the agent is not deciding its own authority in real time. The user defines the control surface before execution.

4. Pre-execution checks

Every supported EVM transaction passes through MetaMask's mandatory three-step security pipeline—transaction simulation, Transaction Shield threat scanning powered by Blockaid, and Smart Transactions MEV protection—before it lands onchain. The pipeline is not opt-in. It runs on every transaction regardless of operating mode, which makes transaction safety part of the wallet path itself rather than an add-on the developer has to assemble separately.

5. Signing within self-custody

If the action passes the rules and safety checks, signing occurs without exposing raw keys to the agent runtime. This is the point where the self-custodial design matters. The agent gets execution power, but the product's architecture is still framed around user-held exportable keys and TEE-backed signing.

6. Human escalation

If the attempted transaction is flagged as malicious or falls outside policy, MetaMask pauses for 2FA review. The user can review the request through MetaMask Mobile push or an email approval link. The agent cannot bypass that escalation path.

7. Execution and logging

If approved, the transaction is sent and recorded. CLI session and wallet metadata is stored in restricted local files, which matters for developers auditing local state and session handling.