Mandate Design Patterns

Every interface you have ever designed assumes the same thing: a human will be present to make decisions. The button expects a click. The form expects input. The confirmation dialogue expects a conscious choice. This assumption is so deeply embedded in design practice that most designers do not even recognise it as an assumption. It is simply how things work.

Agentic AI breaks this assumption. When an autonomous agent acts on behalf of a human - researching products, comparing prices, negotiating terms, initiating purchases - the human is not present at the moment of decision. They are elsewhere, doing something else, trusting that the agent is operating within the boundaries they intended. The question that every designer must now answer is: how did those boundaries get set?

This is the mandate problem. Not "how do we build smarter agents?" but "how do we design the interfaces through which humans express what they want, how much they are willing to spend, what constraints matter, and when the agent should stop and ask?" The mandate is the contract between human intention and machine autonomy. It is the most consequential new design surface in Agentic Experience Design, and it is the surface that most teams are getting wrong.

In the Agent Payments Protocol (AP2), mandates take a specific technical form: Verifiable Digital Credentials that cryptographically bind an agent's authority to a human's attested intent. But the design challenge extends far beyond payments. Every domain where agents act autonomously - scheduling, procurement, healthcare coordination, legal research, travel planning - requires mandate interfaces. The patterns differ in their specifics, but the underlying design problems are universal.

This essay catalogues those patterns. It is a practitioner's guide to designing the interfaces through which humans delegate authority to machines - not as an abstract exercise, but as the concrete, buildable design work that will define whether agentic commerce and autonomous systems earn or forfeit human trust.

A mandate is a structured expression of human intent that authorises an autonomous agent to act within defined boundaries. It is distinct from a command, which specifies a single action ("buy this item"), and distinct from a goal, which specifies a desired outcome without constraints ("find me the best deal"). A mandate occupies the space between the two: it specifies an outcome, the constraints within which the agent may pursue that outcome, and the conditions under which the agent must pause, escalate, or stop.

The concept draws from legal theory, where a mandate is an authorisation granted by a principal (the human) to an agent (the AI) to act on their behalf within specified limits. In contract law, the validity of an agent's actions depends entirely on whether they fall within the scope of the mandate. The same principle applies in agentic experience design: an agent's actions are only legitimate to the extent that they fall within the boundaries the human has defined.

This legal framing is not metaphorical. The Agent Payments Protocol (AP2) operationalises mandates as Verifiable Digital Credentials - cryptographically signed documents that encode a human's spending authority, category constraints, temporal limits, and approval requirements. When an agent presents a mandate to a merchant, it is presenting proof that a human has authorised this specific scope of action. The mandate is the mechanism through which trust architecture becomes operational.

For designers, this means that the mandate interface is not a settings panel or a preferences screen. It is a trust instrument. The quality of the mandate - its precision, its completeness, its alignment with the human's actual intent - determines whether the agent will act in ways the human would endorse. A poorly designed mandate interface produces vague, over-broad, or misaligned mandates, which produce agent behaviour that erodes trust. A well-designed mandate interface produces precise, bounded, reviewable mandates that give humans genuine control over autonomous action.

Every mandate, regardless of domain, comprises six structural elements. These elements may be expressed differently depending on the context - a grocery shopping mandate looks different from a travel booking mandate - but the underlying structure is consistent. Understanding this anatomy is essential for designers because each element presents distinct interface challenges.

The relationship between these six elements is not additive - it is architectural. Intent without constraints produces unbounded action. Constraints without authority levels produce rigid, brittle mandates that cannot adapt to real-world conditions. Authority levels without escalation rules produce agents that either over-escalate (asking permission for everything) or under-escalate (making consequential decisions silently). The designer's task is to create interfaces that help humans specify all six elements in a way that is coherent, complete, and aligned with their actual preferences.

Intent capture is the first and most fundamental mandate pattern. It addresses the question: how does a human express what they want an agent to do? This sounds simple, but it conceals a deep design challenge. Human intent is inherently ambiguous, contextual, and often incompletely formed. When someone says "find me a good hotel in Barcelona," they carry unstated assumptions about price range, neighbourhood, amenities, and aesthetic preferences that they may not even be consciously aware of.

The Intent Architecture Framework identifies three primary intent capture patterns, each suited to different contexts and levels of user sophistication.

Conversational intent capture uses natural language dialogue to progressively elicit and refine the user's goals. The agent asks questions, proposes interpretations, and iteratively narrows the intent until both parties agree on a specification. This pattern is most effective for complex, novel, or emotionally significant mandates - booking a honeymoon, selecting a care provider, commissioning a bespoke product. Its strength is that it meets users where they are, allowing them to express intent in their own words rather than through structured forms. Its weakness is that it is slow, requires sophisticated natural language understanding, and can produce mandates that are difficult to verify because the specification is distributed across a conversation rather than captured in a single document.

Structured intent capture uses form-based interfaces - sliders, toggles, dropdowns, range selectors - to guide users through a systematic specification of their intent. This pattern is most effective for routine, well-understood mandates where the parameters are known in advance: weekly grocery orders, recurring subscriptions, standard procurement. Its strength is precision: every parameter is explicitly set, producing mandates that are unambiguous and machine-readable. Its weakness is that it requires users to know what they want before they start, which is often not the case.

Template-based intent capture provides pre-built mandate templates that users can select and customise. "Weekly grocery shop," "business trip to London," "birthday gift under 50 GBP" - each template encodes a common intent pattern with sensible defaults for scope, constraints, and authority levels. Users modify only the parameters that differ from the default. This pattern is most effective for high-frequency, low-complexity mandates where speed matters more than precision. Its strength is efficiency: a mandate that might take five minutes to build from scratch can be issued in thirty seconds from a template. Its weakness is that templates encode assumptions that may not match the user's actual intent, creating a gap between what the user thinks they authorised and what the agent actually does.

The most effective mandate interfaces combine all three patterns. A user might start with a template for their weekly grocery order, switch to structured capture to adjust specific constraints (budget, delivery window), and use conversational capture to handle an exception ("I'm hosting a dinner party on Saturday - add ingredients for a Thai green curry for eight people"). The designer's task is to make transitions between these modes seamless, preserving context and constraint state as the user moves between them.

If intent capture answers "what do you want?", boundary specification answers "what are you not willing to accept?" Boundaries are the constraints that define the operational envelope within which an agent may act. They are, in many ways, more important than the intent itself, because boundaries are what prevent an agent from pursuing a goal in ways the human would find unacceptable.

The Delegation Design Framework distinguishes four categories of boundaries, each requiring different interface treatments.

Financial boundaries are the most intuitive and the most commonly implemented. They include budget ceilings (hard maximum spend), per-item limits (maximum price for any single item), approval thresholds (amounts above which human approval is required), and rate limits (maximum spend per time period). The design challenge is not in capturing these values - a slider or input field suffices - but in helping users set appropriate values. Most users have poor intuitions about what a reasonable budget is for a task they have never delegated before. Effective financial boundary interfaces provide contextual anchors: "Similar orders typically cost between 80 and 130 GBP" or "Your last three grocery orders averaged 97 GBP."

Temporal boundaries define when the mandate is active and when it expires. They include start times, end times, deadlines, blackout periods (times when the agent should not act), and frequency limits (how often the agent may repeat an action). Temporal boundaries are critical for preventing mandate drift - the gradual expansion of an agent's authority over time as a mandate remains active beyond its intended lifespan. Every mandate should have an explicit expiry, and the interface should make the temporal scope visible and prominent rather than burying it in advanced settings.

Quality boundaries encode preferences about the characteristics of acceptable outcomes. Brand preferences, minimum ratings, material requirements, ethical constraints (fair trade, sustainable sourcing), allergen exclusions - these are the boundaries that make a mandate personal rather than generic. Quality boundaries are the hardest to capture because they often involve subjective judgements that users struggle to articulate. A user knows they prefer "good quality" olive oil but may not be able to specify what that means in terms of region, extraction method, or price point. Effective quality boundary interfaces use examples rather than abstractions: "Would you prefer something like this?" with concrete product examples that help users calibrate their preferences.

Scope boundaries define the operational territory of the mandate - which merchants, categories, geographies, or service providers the agent may engage. Scope boundaries prevent an agent from interpreting a mandate too broadly. A mandate to "find the best price on running shoes" should not result in the agent browsing counterfeit goods marketplaces or international sellers with three-week shipping times, even if those options technically satisfy the stated intent. Scope boundaries are best implemented as allowlists (explicitly permitted merchants or categories) rather than blocklists (explicitly excluded ones), because allowlists fail safely - an unlisted merchant is excluded by default - while blocklists fail dangerously, requiring the user to anticipate every unacceptable option in advance.

The Autonomy Gradient Design System provides the theoretical foundation for authority gradients - the spectrum of autonomy that a mandate grants to an agent. This is not a binary choice between "fully autonomous" and "fully supervised." It is a nuanced, context-dependent calibration that may vary within a single mandate depending on the type of decision being made.

Authority gradients operate on four levels, each representing a different relationship between human oversight and agent autonomy.

At Level 1 - Observation, the agent monitors conditions and reports but takes no action. It watches prices, tracks availability, identifies opportunities, and surfaces information for the human to act on. The mandate at this level is essentially a standing query with notification rules. The design challenge is in defining what constitutes a noteworthy event - what threshold of price change, availability shift, or opportunity emergence warrants interrupting the human?

At Level 2 - Recommendation, the agent researches options, evaluates alternatives, and presents a ranked set of recommendations for human selection. The agent does the work of discovery and analysis; the human makes the final decision. This is the authority level most familiar to users of existing recommendation systems, but in the mandate context it carries an important distinction: the agent's recommendations are constrained by the mandate's boundaries, not by the platform's commercial interests.

At Level 3 - Conditional Autonomy, the agent may act independently within defined parameters but must escalate decisions that fall outside those parameters. This is the most complex authority level to design for, because it requires the interface to clearly communicate which decisions the agent will make autonomously and which it will escalate. The grocery example illustrates this well: auto-approve familiar items under a price threshold, but escalate unfamiliar items, out-of-stock substitutions, or items that exceed the per-item limit.

At Level 4 - Full Autonomy, the agent acts independently within the mandate's boundaries without seeking approval for individual decisions. The human reviews outcomes after the fact rather than approving actions in advance. This level is appropriate for routine, low-stakes mandates where the cost of interruption exceeds the cost of a suboptimal decision - reordering office supplies, renewing standard subscriptions, managing routine scheduling.

The critical design insight is that authority levels should not be uniform across a mandate. A single grocery mandate might grant Level 4 autonomy for staple items the user buys every week, Level 3 for items above a certain price, and Level 2 for categories the user has never purchased before. The interface must make this granularity accessible without making it overwhelming - a challenge that demands progressive disclosure, sensible defaults, and clear visual hierarchy.

A mandate is not a static document. It has a lifecycle that begins with creation, moves through activation and execution, and ends with completion, expiry, or revocation. Each phase of this lifecycle presents distinct design challenges, and the quality of the lifecycle management interface determines whether users maintain genuine control over their agents or lose track of what they have authorised.

Creation is the phase covered by the previous three patterns - intent capture, boundary specification, and authority gradient selection. But creation also includes a critical step that many designs omit: mandate review. Before a mandate becomes active, the user should see a complete, human-readable summary of what they are authorising. This summary should use plain language, not technical parameters. "You are authorising your agent to purchase weekly groceries from Tesco or Sainsbury's, spending up to 120 GBP, with automatic approval for items under 8 GBP and manual approval required for anything above. This mandate expires in 48 hours." The review step is the last opportunity to catch misalignment between intent and specification.

Activation is the moment the mandate goes live and the agent begins operating under its authority. The interface should provide a clear confirmation that the mandate is active, along with a persistent indicator of active mandates - similar to how operating systems show active downloads or background processes. Users should never be uncertain about whether an agent is currently acting on their behalf.

Monitoring is the ongoing visibility into what the agent is doing under the mandate's authority. The absent-state audit framework provides the design principles for this phase: users who were absent during agent action should be able to reconstruct what happened, why, and whether it fell within the mandate's boundaries. Monitoring interfaces should show a timeline of agent actions, each annotated with the mandate constraint it satisfied and any decisions the agent made autonomously.

Amendment is the ability to modify a mandate while it is active. This is essential because circumstances change - budgets shift, deadlines move, preferences evolve. The design challenge is in handling amendments that affect actions the agent has already taken or is in the process of taking. If a user reduces their budget after the agent has already committed to a purchase, what happens? The amendment interface must make the implications of changes visible before the user confirms them.

Completion and audit is the final phase, where the mandate has been fulfilled, expired, or revoked, and the user reviews the outcome. The explainability standard governs this phase: every action the agent took should be traceable back to the mandate that authorised it, with a clear explanation of the agent's reasoning. This is not just good design - in regulated domains like financial services, it is a compliance requirement. The audit interface should make it easy to answer the question: "Did this agent do what I asked, within the limits I set?"

The Interrupt Pattern Library and failure architecture frameworks provide the foundation for this pattern, which addresses what happens when an agent encounters conditions that fall outside the mandate's parameters. Failure and escalation design is arguably the most important mandate pattern, because it governs the moments when autonomous action is most likely to go wrong.

Constraint violations occur when the agent cannot fulfil the mandate within its boundaries. The budget is insufficient for the requested items. The preferred merchant is out of stock. The delivery window cannot be met. The design question is: what should the agent do? The mandate must specify escalation behaviour for each type of constraint violation. Some violations warrant automatic adjustment (substitute a comparable item), some warrant notification (alert the user but continue), and some warrant a full stop (halt all activity until the user responds).

Ambiguity resolution occurs when the agent encounters a situation that the mandate does not clearly address. The user asked for "good quality" but the agent must choose between two options that are equally rated but differ in ways the mandate does not specify. Effective mandates anticipate common ambiguities and provide resolution rules. But no mandate can anticipate every ambiguity, so the escalation interface must make it easy for the agent to present the ambiguity clearly and for the user to resolve it quickly - ideally with a single tap that both resolves the immediate question and updates the mandate to handle similar situations in the future.

Mandate conflicts occur when a user has multiple active mandates with overlapping or contradictory constraints. A mandate to "minimise grocery spending" conflicts with a mandate to "buy organic whenever possible." A mandate to "book the cheapest flight" conflicts with a mandate to "avoid airlines with poor environmental ratings." Conflict detection should be built into the mandate creation process - flagging potential conflicts before the mandate is activated - and into the runtime monitoring, where the agent surfaces conflicts as they arise rather than silently resolving them according to its own priorities.

Graceful degradation is the principle that when a mandate cannot be fully fulfilled, the agent should fulfil as much as possible rather than failing entirely. If the budget is insufficient for all requested items, the agent should prioritise essential items and defer non-essential ones rather than abandoning the entire order. The mandate interface should allow users to specify priority rankings for this purpose - which items or categories are essential, which are nice-to-have, and which can be dropped entirely if constraints tighten.

Agentic commerce is the domain where mandate design patterns face their most demanding test. When an agent spends money on behalf of a human, the consequences of a poorly designed mandate are immediate, tangible, and potentially irreversible. A vague mandate that results in an unwanted purchase is not merely an inconvenience - it is a financial loss that erodes trust in the entire agentic system.

The Agent Payments Protocol (AP2) provides the technical infrastructure for commerce mandates through its three-tier credential system. The Intent Mandate encodes the user's high-level spending authority - budget, categories, temporal constraints. The Cart Mandate captures the user's explicit approval of a specific set of items at specific prices. The Payment Mandate authorises the actual financial transaction, signalling to the payment network that a human has attested their intent through the mandate chain.

This three-tier structure maps directly to the mandate design patterns described in this essay. Intent capture produces the Intent Mandate. Boundary specification and authority gradients shape its constraints. The mandate lifecycle governs the progression from Intent Mandate to Cart Mandate to Payment Mandate. And failure and escalation patterns determine what happens when the agent encounters conditions that the Intent Mandate did not anticipate.

Consider a concrete example: agentic shopping for a weekly grocery order. The user opens the mandate interface and selects a "Weekly Groceries" template (template-based intent capture). The template pre-populates with their usual supermarket, a budget based on their historical average, and their saved dietary preferences. The user adjusts the budget upward because they are hosting guests (structured boundary specification). They set the authority level to auto-approve familiar items but escalate unfamiliar ones (authority gradient). They set a 24-hour expiry with Saturday morning delivery (temporal boundary). They review the complete mandate summary and activate it.

The agent begins shopping. It encounters an out-of-stock item and proposes a substitute (escalation pattern). It finds a premium item that exceeds the per-item limit and escalates for approval (constraint boundary). It completes the order within budget and presents a Cart Mandate for the user's review - a complete, itemised list with prices, substitutions noted, and the total clearly displayed against the budget ceiling. The user approves, generating a Payment Mandate that flows through AP2 to the payment network. The entire transaction is cryptographically auditable, with every agent decision traceable to the mandate that authorised it.

Understanding how mandates fail is as important as understanding how they succeed. Five anti-patterns recur across mandate implementations, each producing a distinct failure mode.

The blank cheque mandate occurs when the interface makes it too easy to grant broad authority without specifying constraints. "Let the agent handle it" buttons, one-click delegation without boundary specification, and default-to-maximum authority levels all produce mandates that give agents more power than the user intended. The blank cheque mandate is the most common anti-pattern in early agentic systems, driven by the desire to minimise friction in the delegation process. It optimises for speed at the expense of control.

The interrogation mandate is the opposite extreme - an interface that demands so many specifications, preferences, and boundary definitions that users abandon the process or rush through it without reading. Twenty-step mandate creation wizards, mandatory fields for every possible constraint, and no sensible defaults produce mandates that are technically precise but practically useless because users did not engage meaningfully with the specification process.

The zombie mandate is a mandate that remains active long after its intended purpose has been fulfilled. Without clear expiry mechanisms and active mandate dashboards, users accumulate standing authorisations that they have forgotten about. The agent continues to act under mandates that no longer reflect the user's current intent. Zombie mandates are a trust architecture failure - they represent a gap between the user's actual intent and the authority the agent believes it holds.

The opaque mandate is a mandate whose constraints are expressed in technical terms that the user does not understand. "Maximum API call rate: 100/hour" or "Confidence threshold: 0.85" may be precise, but they are meaningless to most users. Opaque mandates produce a false sense of control - the user believes they have set boundaries, but they do not understand what those boundaries actually constrain.

The static mandate is a mandate that cannot be amended once activated. Real-world conditions change, and mandates must be modifiable without requiring the user to revoke and recreate them from scratch. Static mandates force users into an all-or-nothing choice: accept the agent's actions under the original mandate or cancel everything and start over.

Translating mandate design patterns into buildable interfaces requires a systematic approach. The following implementation principles, drawn from the AXD practice frameworks, provide a starting point for design teams.

Start with templates, not blank canvases. Most users do not want to build mandates from scratch. They want to select a pattern that is close to what they need and adjust it. Design your mandate system around a library of templates that encode common intent patterns with sensible defaults. Let users customise from there. The template library should grow over time, informed by usage data and user feedback, becoming increasingly personalised to each user's patterns.

Make boundaries visible, not hidden. The most important information in a mandate is what the agent cannot do. Display constraints prominently - budget ceilings, scope limits, expiry times, escalation triggers. Use visual indicators (progress bars against budget, countdown timers for expiry, colour-coded authority levels) that communicate constraint state at a glance. Never bury boundaries in settings menus or advanced options.

Use progressive disclosure for complexity. A simple mandate (reorder my usual coffee) should require minimal input. A complex mandate (plan a two-week holiday for a family of five) should reveal additional specification options as the user engages with them. The interface should adapt its complexity to the mandate's complexity, not force every mandate through the same specification process.

Always show the mandate summary in plain language. Before activation, every mandate should be rendered as a human-readable paragraph that describes what the user is authorising. This summary should be generated from the structured mandate data, not written separately, to ensure it accurately reflects the actual constraints. If the summary sounds wrong to the user, the mandate is wrong.

Design for amendment, not just creation. The mandate amendment interface should be as thoughtfully designed as the creation interface. Users should be able to adjust any parameter of an active mandate and see the implications of that adjustment before confirming it. Amendment history should be preserved for audit purposes.

Build the audit trail into the experience. Every agent action should be linked to the mandate that authorised it. The post-execution review should show not just what the agent did, but which mandate constraint each action satisfied. This is not just a compliance requirement - it is the mechanism through which users calibrate their mandates over time, learning which constraints were too tight, which were too loose, and which were missing entirely.

The mandate is not a feature. It is not a settings panel, a preferences screen, or an onboarding flow. It is the foundational interface of the agentic age - the mechanism through which humans express what they want, set the boundaries of acceptable action, and maintain meaningful control over systems that act on their behalf.

The five patterns catalogued in this essay - intent capture, boundary specification, authority gradients, lifecycle management, and failure escalation - are not optional design considerations. They are structural requirements. Any system that deploys autonomous agents without thoughtful mandate design is deploying agents without meaningful human oversight, regardless of how sophisticated the underlying AI may be.

The stakes are particularly acute in agentic commerce, where mandates govern the movement of money. The Agent Payments Protocol (AP2) provides the cryptographic infrastructure for commerce mandates, but infrastructure without interface is inert. It is the designer's task to make mandates legible, modifiable, auditable, and aligned with human intent - to ensure that the contract between human and machine is one that both parties can honour.

This is the work of Agentic Experience Design. Not building smarter agents, but building better contracts. Not optimising for autonomy, but optimising for alignment. Not removing humans from the loop, but designing the loop itself - the structured, bounded, transparent interface through which human intention becomes machine action.

A mandate is not a command and not a wish. It is a contract - a structured agreement between human intention and machine autonomy that defines what may be done, within what limits, and under whose authority. The quality of that contract determines whether autonomous agents earn or forfeit human trust.