What Is an Intent Object? How AI Agents Get Authorization to Spend

An intent object is a structured, line-item purchase contract that a user approves before an AI agent executes it. It names the merchant, the specific items, the quantities, the price ceiling, and the fulfillment details. In Lane, the intent object is the authorization primitive: the agent gets permission to complete one bounded purchase, not open-ended access to a card.

Lane is the payment infrastructure that lets AI agents transact with any merchant: agents integrate once and can order food, shop online, and book travel and reservations on a user's behalf, with the user's own card and explicit approval. The intent object is what that explicit approval is made of.

Why does an agent purchase need an intent object at all?

Consider what a naive agent purchase authorization looks like: the user types "yeah, order it" and the agent charges a card. That string is not an authorization record. It has no amount, no merchant, no items, and no way to reconstruct after the fact what the user believed they were agreeing to.

That gap causes three concrete problems. The user cannot tell what is about to happen before it happens. The builder cannot prove what was approved when a dispute arrives. And nothing constrains the agent if the merchant's page turns out to cost more, contain a different item, or add fees. The intent object closes all three by making the approval a structured object rather than a conversational turn.

What is inside an intent object?

The exact schema lives in Lane's docs, but conceptually an intent object carries the answers to every question a user would want answered before saying yes.

The intent object is a receipt before the purchase happens.

That framing is the point. A receipt is the artifact users already trust to describe a transaction precisely. An intent object is the same artifact, presented before money moves, at the moment the user can still say no.

How does approval work in practice?

1. 1

   The user expresses intent. Someone asks the agent to order dinner, buy a specific item, or book a table.

2. 2

   Lane drafts the intent object. The prompt becomes a structured contract with the merchant, items, quantities, and ceiling resolved to concrete values.

3. 3

   The user approves it. A scoped prompt shows exactly what will happen, confirmed with a biometric or passkey, in the style of an Apple Pay double-click. It renders natively in the builder's own product with no redirect.

4. 4

   Lane executes within the terms. Lane completes the purchase against the merchant, checking every step against the approved intent.

5. 5

   The purchase confirms or stops. If reality diverges from the approved terms, execution stops rather than proceeding on the user's card.

What stops an agent from spending outside the approved terms?

Enforcement, not trust. This is the distinction that matters most about how Lane uses intent objects: the approved terms are enforced throughout execution, not validated once at the beginning and then assumed. The agent is physically unable to buy anything outside the approved terms.

The practical cases this covers are the ones that actually occur. A merchant raises the price between selection and checkout. The store substitutes an unavailable item. A fee, a surcharge, or a tip default pushes the total above what the user saw. In each case the transaction is stopped or returned for a fresh approval rather than silently completed at a number the user never agreed to.

This is why Lane treats intent as an object rather than a prompt. Prompts are instructions an agent can reinterpret. Objects are constraints the infrastructure applies.

The enforcement also reaches below the agent. The payment credential Lane mints for an approved intent carries the approved ceiling at the card network level, so even an agent that somehow went rogue could not spend past it. The limit is a property of the credential itself, not a check the agent is trusted to run.

How is an intent object different from a card spend limit?

Spend controls on a card are real, useful, and far too coarse for consumer purchases. A network-level control can see an amount, a merchant category, and sometimes a merchant identifier. It cannot see what is in the cart.

• A spend limit sees an amount: it can block a charge over $80. It cannot tell whether that $80 bought the item the user asked for.
• A spend limit sees a category: it can allow restaurants. It cannot restrict the purchase to one specific restaurant the user named.
• An intent object sees the brand and the merchant: approval is scoped to the actual store, so an agent cannot redirect the same budget somewhere else.
• An intent object sees the item: approval is scoped to specific products and quantities, which is the level users actually reason about.
• An intent object sees the price as a ceiling on a known basket: not a standalone number, which is what makes a substitution or a surcharge detectable.

The two are complementary rather than competing. A card control is a blunt outer boundary. An intent object is the specific, per-purchase contract inside it, and it is the layer that maps to what a user thinks they authorized.

Why do issuers and merchants benefit from intent-level data?

Agent-initiated purchases are hard to approve because they look anomalous. The device is unfamiliar, the pattern is unusual, and the context an issuer receives is thin: an amount, a merchant, and a timestamp. Faced with thin context and unusual signals, the risk-minimizing decision is to decline.

Intent-level data changes the input. When authorization information from an approved intent object carries into the transaction, the decision is being made with the approved merchant, the approved basket, and the approved ceiling attached, plus the fact that a specific human confirmed it with a biometric or passkey. Richer context is a better fraud signal in both directions: genuine agent purchases become easier to distinguish from card testing, and the transaction stops looking like an anomaly worth declining.

For the user, this is also the mechanism behind liability. Because the consent trail reaches the card networks, an agent purchase made through Lane is a properly authorized cardholder transaction, and the user keeps their bank's normal dispute protections. You are still protected by your bank.

Where does the intent object fit in Lane's stack?

Lane's infrastructure has four layers: verified agent identity, intent and consent, wallet and credentials, and execution. The intent object is the second layer, and it is the one the other three defer to. Identity establishes that the agent is accountable. Credentials make the purchase chargeable without exposing a card number. Execution completes the checkout. All of it is bounded by what the intent object says the user approved.

The reason Lane leads with the intent object rather than the card is that the credential was never the hard part of agent payments. Knowing precisely what a human authorized, and being able to enforce it while software acts on their behalf, is the part that makes agent spending safe enough to ship.