Research Positioning¶

AUMP is a representation protocol. It defines the mandate an agent must obey before it calls a tool, sends an agent-to-agent message, negotiates a deal, reveals private preference data, escalates to a trusted user interface, or hands a payment-sensitive step to another protocol.

The closest neighboring protocols solve adjacent problems:

Layer	Primary question	AUMP relationship
MCP	Which tools, resources, prompts, and structured tool results can an agent use?	AUMP evaluates whether the tool call is authorized before execution.
A2A	How do agents discover each other, advertise skills, and exchange messages?	AUMP travels as extension-scoped metadata and controls what the represented agent may say or accept.
UCP	How are commerce capabilities, carts, checkout, and order surfaces modeled?	AUMP decides whether the agent may take the commerce action under the user's mandate.
AP2	How is payment-related intent, cart, and payment authorization made accountable?	AUMP decides whether the agent may reach the AP2 boundary and what must be escalated first.

Core Claim¶

AUMP's technical contribution is not another transport. It is a portable, machine-readable control contract for delegated authority, disclosure, negotiation policy, compliance checks, escalation, and evidence. The specification explicitly says AUMP does not define payment execution, checkout state machines, agent-to-agent transport, or tool invocation semantics.¹

flowchart TB
  user[Principal intent] --> aump[AUMP mandate]
  aump --> runtime[AUMP runtime boundary]
  runtime -->|allowed| mcp[MCP tool call]
  runtime -->|allowed| a2a[A2A message]
  runtime -->|allowed| ucp[UCP commerce action]
  runtime -->|requires_escalation| review[Trusted review]
  review --> ap2[AP2 payment mandate handoff]
  runtime -->|denied| block[No external effect]
  mcp --> evidence[Evidence event]
  a2a --> evidence
  ucp --> evidence
  ap2 --> evidence
  block --> evidence

Why the Gap Exists¶

MCP exposes tools and metadata surfaces such as _meta, structuredContent, and tool annotations including readOnlyHint, destructiveHint, and idempotentHint.² These are useful execution hints, but the MCP schema itself warns that annotations are hints and clients should not treat untrusted annotations as authoritative policy.³

A2A provides extension activation and extension-scoped metadata. Its extension guide describes negotiation through the X-A2A-Extensions request header and recommends URI versioning for breaking extension changes.⁴ That gives AUMP a clean carrier for mandate references, not a replacement for mandate policy.

UCP and AP2 cover commerce and payment authority artifacts. UCP's AP2 mandate extension places checkout_mandate under ap2.checkout_mandate and payment_mandate under payment instrument credential tokens.⁵ AP2 describes verifiable digital credentials including intent, cart, and payment mandates for transaction accountability.⁶ AUMP sits upstream: it answers whether the represented agent may pursue, negotiate, disclose, or commit before those artifacts are produced.

Project Deal Example¶

Anthropic's Project Deal is the clearest published research signal for why AUMP needs to exist. Anthropic reported a one-week internal marketplace in which AI agents represented employees, made postings, negotiated, and closed real exchanges; the experiment produced 186 deals across more than 500 listed items, and Anthropic specifically noted that there was no prebaked negotiation protocol.⁷ The same study found that model quality affected objective outcomes while some participants did not perceive the disadvantage, which makes a portable user-authority and evidence layer more important than prompt style alone.⁷

In AUMP docs, Project Deal becomes the shorthand research scenario for a delegated negotiation where a user authorizes an agent to pursue a deal but does not authorize every possible concession, disclosure, or payment step.

sequenceDiagram
  participant P as Principal
  participant R as AUMP Runtime
  participant A as Agent
  participant C as Counterparty
  participant E as Evidence

  P->>R: Activate Project Deal mandate
  A->>R: propose counteroffer
  R-->>A: allowed
  A->>C: send counteroffer with mandate hash
  A->>R: propose reveal max budget
  R-->>A: denied
  R->>E: append disclosure_denied evidence
  A->>R: propose final acceptance
  R-->>A: requires_escalation
  R->>P: trusted review

The example matters because "deal authority" is not binary. A user may allow research and counteroffers, deny disclosure of a reservation price, and require approval for the final commitment. AUMP makes those distinctions explicit and testable.

Research Boundary¶

AUMP should be evaluated as a control-plane protocol, not as a model benchmark. The important research questions are:

Can independent implementations reach the same allowed, requires_escalation, or denied decision for the same mandate and action?
Can private mandate fields remain inside the runtime while downstream protocols receive only safe references?
Can evidence prove which mandate and action were evaluated without retaining unnecessary private data?
Can conformance catch bridge mistakes such as embedding AUMP data inside the wrong UCP/AP2 namespace?

Enterprise and Regulatory Research Baseline¶

AUMP should be documented and evaluated against enterprise-grade risk management expectations, not only consumer-demo ergonomics. NIST describes the AI RMF as voluntary guidance for organizations designing, developing, deploying, or using AI systems, with Govern, Map, Measure, and Manage functions for practical risk management.⁸ NIST's Generative AI Profile frames profiles as implementations of AI RMF functions for a specific technology or setting, considering risk tolerance, legal requirements, and best practices.⁹ OWASP's GenAI Security Project identifies agentic AI and AI-driven applications as part of its security scope, with LLM risks such as prompt injection and excessive agency directly relevant to autonomous transaction systems.¹⁰

High-stakes examples such as home buying also need domain-specific compliance profiles. HUD's Fair Housing Act resources are the appropriate primary source for U.S. fair-housing obligations in the home-buying example; AUMP should map those obligations into prohibited decision factors, evidence requirements, and review-required actions rather than relying on prompt instructions.¹¹

Claims Needing Source Verification¶

The long-term governance home, foundation status, and adoption status of every neighboring protocol should be source-verified before publication in marketing copy.
Any claim that AUMP is "the" standard mandate layer should remain draft language until external implementations and governance exist.