When agents negotiate: the emerging protocols for automated service agreements
In January 2026, IBM's Institute for Business Value reported that 45% of consumers already use AI for part of their buying journey. Research suggests agentic commerce could generate between $3 trillion and $5 trillion globally by 2030. Shopify and Google just co-developed the Universal Commerce Protocol (UCP) — an open standard for AI agents to transact with any merchant. OpenAI's Agent Commerce Protocol (ACP) powers instant checkout in ChatGPT for Shopify and Etsy merchants.
This isn't a whitepaper about what might happen someday. Agents are buying things right now. The question isn't whether agent-to-service negotiation will happen — it's which protocols will win, what the negotiation surface looks like, and what SaaS companies need to build to participate.
The four-layer protocol stack
Agent-to-service interaction isn't one protocol. It's a stack. Each layer solves a different problem, and they're designed to work together:
┌─────────────────────────────────────┐
│ Layer 4: Commerce & Payment │ UCP, ACP, AP2
│ "Complete this purchase" │
├─────────────────────────────────────┤
│ Layer 3: Agent-to-Agent (A2A) │ Google A2A Protocol
│ "Delegate this task to you" │
├─────────────────────────────────────┤
│ Layer 2: Tools & Context (MCP) │ Anthropic MCP
│ "Here's what I can do for you" │
├─────────────────────────────────────┤
│ Layer 1: Discovery │ robots.txt, llms.txt,
│ "Here's who I am" │ /.well-known/agent.json
└─────────────────────────────────────┘
Layer 1: Discovery — "Here's who I am"
Before agents can negotiate, they need to find each other. Three standards compete here:
robots.txt + llms.txt — The current baseline. A robots.txt file says what's crawlable; an llms.txt file provides a machine-readable summary of what the service does. From our benchmark of 997 SaaS companies, only 2% have an llms.txt file. It's early.
/.well-known/agent.json (A2A Agent Cards) — Google's A2A protocol introduced Agent Cards: JSON files hosted at a well-known URL that describe an agent's capabilities, supported interactions, authentication requirements, and service endpoints.
{
"name": "Acme Inventory Agent",
"description": "Manages product inventory, pricing, and availability",
"url": "https://agents.acme.com",
"version": "1.0.0",
"capabilities": {
"streaming": true,
"pushNotifications": true,
"stateTransitionHistory": true
},
"skills": [
{
"id": "check-availability",
"name": "Check Product Availability",
"description": "Returns real-time stock levels for a given SKU",
"tags": ["inventory", "availability", "stock"],
"examples": [
"Is SKU-12345 in stock?",
"How many units of Widget Pro are available?"
]
},
{
"id": "negotiate-price",
"name": "Negotiate Bulk Pricing",
"description": "Provides volume discounts for orders above threshold",
"tags": ["pricing", "negotiation", "bulk"],
"examples": [
"What's the price for 500 units?",
"Can you do better than $12.50 per unit?"
]
}
],
"defaultInputModes": ["text/plain", "application/json"],
"defaultOutputModes": ["text/plain", "application/json"],
"authentication": {
"schemes": ["OAuth2"],
"credentials": "https://agents.acme.com/oauth/register"
}
}
Agent Cards are the "LinkedIn profiles" for AI agents — they advertise what an agent can do so other agents can decide whether to interact with it. The A2A spec places these at /.well-known/agent.json, following the same convention as /.well-known/openid-configuration for OAuth discovery.
MCP Server Manifests — Anthropic's Model Context Protocol takes a different approach: instead of static JSON files, MCP servers dynamically advertise their tools and capabilities through the protocol itself. An agent connects to an MCP server and receives a list of available tools with descriptions, parameter schemas, and return types.
Layer 2: Tools and context — "Here's what I can do for you"
MCP, standardized by Anthropic in 2024 and adopted by OpenAI in March 2025, is the current consensus standard for connecting AI agents to external services. It's essentially an API for APIs — a standardized way for agents to discover and invoke tools.
// MCP server exposing a SaaS product's capabilities
const server = new McpServer({
name: "acme-api",
version: "1.0.0",
});
// Tool: Get pricing information
server.tool(
"get_pricing",
"Returns current pricing for a product tier",
{
tier: z.enum(["starter", "professional", "enterprise"]),
billing_cycle: z.enum(["monthly", "annual"]),
seats: z.number().min(1).max(10000),
},
async ({ tier, billing_cycle, seats }) => {
const pricing = await calculatePricing(tier, billing_cycle, seats);
return {
content: [{
type: "text",
text: JSON.stringify({
tier,
price_per_seat: pricing.perSeat,
total_monthly: pricing.totalMonthly,
total_annual: pricing.totalAnnual,
discount_applied: pricing.discount,
volume_discount_available: seats >= 50,
negotiable: tier === "enterprise",
}),
}],
};
}
);
// Tool: Request a custom quote (the negotiation entry point)
server.tool(
"request_quote",
"Request a custom enterprise quote with optional negotiation parameters",
{
company_name: z.string(),
seats: z.number().min(1),
desired_price_per_seat: z.number().optional(),
contract_length_months: z.enum(["12", "24", "36"]).optional(),
competing_offer: z.string().optional(), // "We have a quote from Competitor X at $Y/seat"
},
async (params) => {
const quote = await generateQuote(params);
return {
content: [{
type: "text",
text: JSON.stringify({
quote_id: quote.id,
offered_price_per_seat: quote.pricePerSeat,
total_contract_value: quote.totalValue,
terms: quote.terms,
valid_until: quote.expiry,
counter_negotiation_available: quote.isNegotiable,
next_step: quote.isNegotiable
? "Call negotiate_quote with a counter-offer"
: "Call accept_quote to proceed",
}),
}],
};
}
);
MCP handles the "what can you do" and "do this thing" interactions. But it's fundamentally a client-server protocol — one agent calls tools on another service. It doesn't handle the peer-to-peer negotiation pattern.
Layer 3: Agent-to-agent — "Delegate this task to you"
This is where Google's A2A protocol fills the gap. Launched in April 2025 with support from over 50 technology partners (Atlassian, Salesforce, SAP, ServiceNow, PayPal, and others) and now housed by the Linux Foundation, A2A enables peer-to-peer communication between agents.
The key difference from MCP: A2A treats agents as opaque collaborators, not tool servers. An A2A client doesn't call functions on a remote agent — it sends tasks and receives results. The remote agent decides how to accomplish the task internally.
Client Agent Remote Agent (Vendor)
│ │
│ POST /tasks/send │
│ { "find me the best deal │
│ on 100 API calls/month" } │
│ ─────────────────────────────► │
│ │
│ Status: "working" │
│ ◄───────────────────────────── │
│ │
│ (agent researches internally,│
│ checks inventory, runs │
│ pricing calculator) │
│ │
│ Status: "completed" │
│ Artifact: { │
│ "offer": { │
│ "plan": "Growth", │
│ "price": "$49/mo", │
│ "includes": "150 calls", │
│ "valid_for": "48h" │
│ } │
│ } │
│ ◄───────────────────────────── │
│ │
│ "Can you do $39 for a │
│ 12-month commitment?" │
│ ─────────────────────────────► │
│ │
│ Artifact: { │
│ "counter_offer": { │
│ "price": "$42/mo", │
│ "commitment": "12mo", │
│ "includes": "200 calls", │
│ "sweetener": "priority │
│ support included" │
│ } │
│ } │
│ ◄───────────────────────────── │
A2A tasks have a lifecycle (submitted → working → input-required → completed / failed) that naturally models the back-and-forth of negotiation. The input-required state is particularly important — it's how a vendor agent says "I need more information before I can give you a final price" or "this requires human approval."
Layer 4: Commerce and payment — "Complete this purchase"
The newest and most commercially significant layer. Three protocols are competing:
Universal Commerce Protocol (UCP) — Co-developed by Shopify and Google, announced February 2026. UCP is the most comprehensive: it handles product discovery, cart management, discount codes, subscription billing, delivery preferences, and payment processing. It's designed to work across REST, MCP, A2A, and Shopify's own Agent Payments Protocol (AP2).
From Shopify's announcement: "UCP gives a standard way for retailers to specify to agents what information is needed from customers in the checkout flow." This means a furniture retailer can require delivery date selection, a subscription service can require billing cadence choice, and a luxury brand can require terms acceptance — all expressed in a standard format that any agent can render.
Agent Commerce Protocol (ACP) — OpenAI's protocol for ChatGPT instant checkout. Co-developed with Stripe, ACP enables secure transactions between AI agents and merchants without the user leaving the conversation. Already live with Shopify and Etsy merchants.
Agent Payments Protocol (AP2) — Shopify's payment-specific protocol that handles the actual money movement. Works in conjunction with UCP for the commerce layer and supports any payment processor, including Shopify Payments.
What negotiation actually looks like today
Let's be concrete. Here's what an agent-to-service negotiation looks like in early 2026, using the protocols that actually exist:
Scenario: Agent procuring a SaaS tool for an enterprise
Step 1: DISCOVERY
Agent checks /.well-known/agent.json on vendor's domain
→ Gets capabilities, pricing endpoint, auth requirements
Step 2: CAPABILITY CHECK (MCP)
Agent connects to vendor's MCP server
→ Calls get_pricing(tier="enterprise", seats=200, billing="annual")
→ Gets: $45/seat/month, volume discount available at 500+ seats
Step 3: NEGOTIATION (A2A)
Agent sends A2A task: "We need 200 seats on annual billing.
Our budget is $35/seat. We're also evaluating Competitor X
at $38/seat with 300 included API calls."
Vendor agent responds:
Status: working → input-required
"What contract length are you considering?"
Agent responds: "24 months with annual payment."
Vendor agent responds:
Status: completed
Artifact: {
offer: $38/seat/month (24-month commitment),
includes: 250 API calls per seat,
SLA: 99.9% uptime guarantee,
valid_for: "72 hours",
acceptance_url: "https://vendor.com/quotes/Q-12345/accept"
}
Step 4: APPROVAL
Agent presents offer to human for approval
Human approves within spending authority
Step 5: TRANSACTION (UCP/ACP)
Agent completes purchase via commerce protocol
→ Payment processed, contract signed, API keys issued
What's missing from this picture
The protocols exist. The vision is clear. But in practice, several pieces are still being built:
Spending authority and guardrails. When an agent negotiates on behalf of a user, what's its budget? What's it authorized to commit to? There's no standard for expressing delegation limits. Today, each agent framework handles this ad hoc.
Multi-party negotiation. The current A2A model is bilateral — one client agent, one remote agent. Real procurement often involves multiple vendors being played against each other simultaneously. There's no protocol support for "I have three offers on the table; beat them."
Liability and dispute resolution. PSD3, the EU's updated Payment Services Directive expected from 2026, aims to formalize delegated payment initiation and harmonize liability for AI-initiated transactions. But for now, if an agent commits to a contract the user didn't authorize, who's responsible?
Verifiable commitment. When a vendor agent says "this price is valid for 48 hours," there's no cryptographic proof. Agent Cards in A2A can be signed with JWS (JSON Web Signature), but offer terms currently lack this protection. Stanford's Digital Economy Lab has published research on the risks of automated negotiation without verifiable commitments — including scenarios where both parties' agents converge on locally optimal but globally suboptimal deals.
What this means for SaaS companies
If you're building a SaaS product and you want AI agents to be able to discover, evaluate, and purchase your service, here's what you need to build — in priority order.
1. Agent Card at /.well-known/agent.json (today)
Even if you're not running an A2A server, publishing an agent card makes your service discoverable. It's a static JSON file:
Free Tool
How agent-ready is your website?
Run a free scan to see how AI agents experience your signup flow, robots.txt, API docs, and LLM visibility.
Run a free scan →{
"name": "Your SaaS Product",
"description": "One-line description of what you do",
"url": "https://yourdomain.com",
"version": "1.0.0",
"skills": [
{
"id": "get-started",
"name": "Sign Up and Get API Key",
"description": "Create an account and receive API credentials",
"tags": ["signup", "api", "onboarding"]
}
],
"defaultInputModes": ["text/plain"],
"defaultOutputModes": ["application/json"],
"authentication": {
"schemes": ["OAuth2"],
"credentials": "https://yourdomain.com/oauth/register"
}
}
Host it at https://yourdomain.com/.well-known/agent.json. This is the A2A equivalent of a Google Business Profile — it's how agents find you.
2. MCP server with pricing and onboarding tools (this quarter)
Expose your core commercial flows as MCP tools:
// Minimum viable MCP server for commercial agent interaction
const commerceTools = [
{
name: "get_plans",
description: "List all available plans with pricing",
// No params — agents should be able to browse your offerings
},
{
name: "get_pricing",
description: "Calculate price for specific configuration",
params: { tier: "string", seats: "number", billing: "string" },
},
{
name: "create_trial",
description: "Create a free trial account and return API credentials",
params: { email: "string", company: "string?" },
},
{
name: "request_quote",
description: "Request a custom quote for enterprise deals",
params: { seats: "number", requirements: "string" },
},
];
The create_trial tool is critical. An agent should be able to go from "evaluate this product" to "I have API keys" in a single MCP call. That's the agent-era version of a signup page.
3. Machine-readable pricing (this quarter)
This is the simplest change with the highest impact. Most SaaS pricing pages are designed for human eyes — sliders, comparison tables, "Contact Sales" buttons. Agents can't parse these reliably.
Publish your pricing as structured data:
// GET /api/pricing — structured pricing for agent consumption
{
"plans": [
{
"id": "starter",
"name": "Starter",
"price": { "monthly": 29, "annual": 24, "currency": "USD" },
"limits": { "api_calls": 10000, "seats": 5, "storage_gb": 10 },
"features": ["core_api", "email_support", "basic_analytics"],
"self_service": true
},
{
"id": "professional",
"name": "Professional",
"price": { "monthly": 99, "annual": 79, "currency": "USD" },
"limits": { "api_calls": 100000, "seats": 25, "storage_gb": 100 },
"features": ["core_api", "priority_support", "advanced_analytics", "sso"],
"self_service": true
},
{
"id": "enterprise",
"name": "Enterprise",
"price": null,
"negotiable": true,
"minimum_seats": 50,
"features": ["core_api", "dedicated_support", "custom_analytics", "sso", "sla", "custom_contracts"],
"self_service": false,
"contact": "https://yourdomain.com/api/request-quote"
}
],
"volume_discounts": [
{ "min_seats": 50, "discount_percent": 10 },
{ "min_seats": 100, "discount_percent": 15 },
{ "min_seats": 500, "discount_percent": 25 }
]
}
When an agent is comparison-shopping across five vendors, the one that returns clean JSON pricing wins. The one that returns "Contact Sales" loses.
4. Commerce protocol support (this year)
If you sell products or subscriptions, implement UCP or ACP so agents can complete purchases without leaving the conversation they're in. If you're a Shopify merchant, this is already available through Agentic Storefronts. If you're not, study the UCP spec — it's an open standard designed for any commerce stack.
The negotiation economy: who wins, who loses
The shift to agent-mediated commerce reshapes competitive dynamics:
Winners: Products with transparent, machine-readable pricing. When agents comparison-shop, structured data wins. The company with a JSON pricing endpoint gets evaluated; the one with a PDF price sheet doesn't.
Winners: Products with self-service onboarding. Agents that can sign up, get API keys, and run a test integration in under 60 seconds will always be recommended over products that require "Schedule a Demo."
Losers: Products that hide pricing behind sales calls. "Contact Sales" is the Disallow: / of agentic commerce. An agent can't negotiate with a human sales team (yet). It'll recommend the vendor that gave it a price.
Losers: Products that rely on brand loyalty. Agents don't have brand preferences. They optimize on price, features, API quality, and documentation. Your brand story doesn't matter to GPTBot — your structured data does.
Wild card: Products with negotiation-capable agents. The companies that deploy their own vendor-side agents — capable of negotiating with purchasing agents in real time — will have a structural advantage. They can offer dynamic pricing, bundle deals, and competitive counter-offers automatically. This is the emerging frontier.
The timeline
Here's our best estimate of how agent-to-service negotiation evolves:
Now (early 2026): MCP is the de facto standard for agent-tool interaction. A2A is gaining adoption for agent-to-agent communication. UCP and ACP are live for retail commerce via Shopify/ChatGPT. Most SaaS products have zero agent-facing infrastructure.
Late 2026: Agent Cards at /.well-known/agent.json become as standard as robots.txt. MCP servers become a standard part of SaaS product architecture, alongside REST APIs and webhooks. First enterprise SaaS products deploy vendor-side negotiation agents.
2027: Multi-agent procurement workflows become common in enterprise. Agent-to-agent price negotiation replaces manual RFP processes for commodity software. EU's PSD3 provides legal framework for agent-initiated payments. First disputes over agent-negotiated contracts reach courts.
2028–2030: The agent commerce layer matures. Agent-facing pricing and onboarding become table stakes for B2B SaaS — like having a website is today. Companies without agent-accessible interfaces lose visibility in the AI-mediated discovery layer that by then drives a majority of software evaluation.
Start building now
The protocol stack is forming. The standards are open. The early movers are already live. Here's your checklist:
- Publish
/.well-known/agent.jsonwith your service description and capabilities - Create a structured pricing endpoint (
GET /api/pricing) that returns JSON - Build an MCP server that exposes your core commercial tools (pricing, trial creation, API key generation)
- Ensure your signup flow is agent-accessible (no CAPTCHAs, server-rendered, OAuth available)
- Add
llms.txtto your domain root with a machine-readable product summary - Monitor the UCP and A2A specs for commerce-specific extensions relevant to your product
The agents are already shopping. The question is whether they can find your store.
How agent-ready is your product today? Run the free AgentGate Benchmark to get your score across authentication, documentation, discoverability, and 4 other categories. See where you stand on the Leaderboard.
Get Started
Ready to make your product agent-accessible?
Add a few lines of code and let AI agents discover, request access, and get real credentials — with human oversight built in.
Get started with Anon →