One suitcase, several participants
The traveller needs her suitcase by Friday and gives the assistant her budget, dimensions and preferences. What she sees as one task spans search, product information, offers, payments and logistics behind the scenes. A later invoice or repair still belongs to that same relationship.
For the purchasing journey to work, participants need a shared understanding of the product sought, the applicable price, consent and order status. Protocols give that exchange a form, much as agreed measurements, order forms and delivery records do in established trade.
That explains the apparent protocol zoo. The names represent different jobs along the same purchasing journey. Some help with discovery, others with access to business functions, purchasing or payment. Understanding the journey makes the initials much easier to place.
The journey provides the map
The customer’s intent leads to a selection, for which the merchant calculates an offer. Following the traveller’s consent, order and payment are executed, followed by delivery and service. This familiar purchasing journey shows the job each protocol performs.
Three things need to travel through the whole journey: product information, the customer’s permission and the progress of the task. For our traveller, it is still the same suitcase, within the same €180 budget, arriving before the same trip. Moving from a chat to a shop should preserve that context.
The approaches shown in the diagram are different ways to perform the jobs. A merchant connects the components its customers and partners use. One protocol may cover several tasks: UCP, for example, spans the discovery of commerce capabilities through to order events, while MCP can provide access to those same functions. [S28, S30]
Shared terms reduce translation work
Today, a merchant often needs a separate integration for each partner. The same basket is described differently, delivery terms go into different fields, and status messages vary. Common protocols reduce this translation work. A new interface can connect more easily to existing commerce functions.
The division of work remains familiar: merchants manage products, prices and orders while assistants help customers navigate them and payment providers handle money movement. A protocol makes the connections between those responsibilities reusable across purchasing journeys.
MCP gives the agent tools
Suppose the assistant wants to know which suitcases meet the cabin-baggage requirements. It needs a search function and then accurate variant information. The Model Context Protocol, or MCP, describes a shared way to make tools and data available to AI applications. An application can use it to search products, check stock or prepare a basket. [S30, S31]
Existing functions can continue to do the work: product search uses the catalogue and prices come from the shop’s pricing logic. MCP makes those foundations available to another user rather than requiring the merchant to rebuild them for the agent.
Useful tools follow the work
An employee understands the difference between checking a price, preparing an offer and submitting an order. An agent needs the same distinctions in its tools. Clear tasks help it choose the right next step and let the merchant see which step the agent is carrying out.
A useful response might say: “The suitcase is available. This offer is valid until 4 p.m. The customer’s consent is still needed to place the order.” The assistant can work with that. When something goes wrong, the response should also explain the next step: obtain a new offer, find an alternative or involve customer service.
The shop checks the required permissions. Product search and a binding order remain separate activities, as they are in daily operations. That separation creates room to delegate more work over time.
A2A connects independent partners
A direct stock query returns a number immediately, whereas coordination with another partner can take time and require questions. If the suitcase needs delivery to a hotel, a logistics partner may take responsibility for that part of the task and return with an answer later.
Agent2Agent, or A2A, describes messages, tasks and results exchanged between independent agent systems. An Agent Card introduces the work a partner can undertake and how to reach it. The requesting agent can bring in support without knowing how the partner works internally. [S32]
Collaboration needs a common thread
The traveller wants to explain her request once. When an agent passes on a delivery question, the deadline, destination and permitted choices should travel with it. The partner should receive only the information needed for its job. Hotel delivery requires an address, rather than a copy of every conversation about the trip.
The delivery partner acknowledges the assignment, sends a follow-up question and later returns a result. The buyer agent knows whether to wait for an answer or prepare the next step. The traveller receives the hotel-delivery information without coordinating the exchange herself.
Several agents are particularly useful when responsibilities differ or tasks can run in parallel. The arrangement should make purchasing easier. Five agents taking turns to summarise the same catalogue look more like a meeting with a higher electricity bill.
The traveller can now receive an offer. The next step turns it into a purchase she has consented to.