The End of Clicks: When AI Agents Become Your Customers (Part 2)
Will your systems be ready when AI Agents come knocking - not with a query, but with intent in hand?
Hi everyone, thanks for coming back to Customer Futures.
Each week I unpack the disruptive shifts around ‘Empowerment Tech’. AI Agents, digital wallets and new digital customer relationships.
If you haven’t yet signed up, why not subscribe:
Hi folks 👋
This is Part Two of last week’s newsletter by Gam Dias. A follow-up from his next book, Agents Unleashed: The Autonomous Edge. It’s another Customer Futures deep dive into what happens when AI Agents disrupt the travel and hospitality sector.
And it’s more technical this week. Because frankly, it’s time to understand how AI Agents communicate.
To look at what happens when your personal data moves between AI Agents, and how businesses will respond across their systems. And, critically, what role your digital wallet will play.
Today, Gam walks us through:
What actually happens when agents talk
Inside the agent-to-agent interaction
How digital wallets and data stores power personalization
Preparing for a world where agents are your customers
A different kind of economy - and the arrival of ‘A-Commerce’
As always, if you want to know more about AI Agents, digital wallets and the future of the digital customer relationship, you can book a call with Gam and I here.
So grab your extra-hot latte-machiato grande-thingy, settle down, and Let’s Go.
Behind the scenes - what actually happens when agents talk
It’s easy to say, “My AI booked the trip for me.”
But under the hood, there’s a sophisticated choreography at work. A digital handshake between agents, mediated by context, permission, and purpose.
So let’s unpack what actually happens when your personal assistant talks to a travel platform’s AI.
At the core of it will soon be Anthropic’s Model Context Protocol (MCP), the connective tissue that allows both agents to understand:
Who they are
What they’re trying to accomplish
What data they can access
And what actions they’re allowed to take
Think of it like a two-agent conversation:
On the customer side, there’s an MCP client that represents you.
On the business side, the travel site runs its own MCP that has access to systems like CRM, booking engines, inventory, and promotions and is able to serve your personal agent.
When your agent says: “Find me a hotel in Paris under $400 with a view of the Eiffel Tower,” it doesn’t just shoot off a search query. It packages that request with:
Your verified identity (e.g., from your digital wallet)
Preferences pulled from past trips
Payment credentials (tokenized)
Constraints like price cap, dates, loyalty programs
This is the structured context payload, and it’s sent to the travel site’s MCP client. That MCP client then forwards the request to the business-side MCP server, which does the heavy lifting:
Retrieves your historical data (if applicable)
Queries hotel inventory and pricing
Applies business rules (e.g., “show preferred partners first”)
And formats a tailored, trustworthy response
That response is then routed back to your agent, complete with flight or hotel options, cancellation policies, and next-step actions like “Hold Seat,” “Book Now,” or “Send to Calendar.”
At no point did either side guess or parse a raw prompt. Everything happened via structured negotiation between two autonomous agents, guided by a common protocol.
This architecture isn’t theoretical. It’s already being prototyped in verticals like travel, finance, and healthcare. And the implications are massive:
No screens required.
No apps to open.
No need for human mediation unless something breaks.
Next, we’ll break this interaction down diagrammatically, so you can see exactly how the data flows, what the agents exchange, and how trust is maintained at every step.
Drawing the system - inside the agent-to-agent interaction
To make agentic commerce work, both sides of the conversation - the customer agent and the travel agent system - must be able to understand and trust each other.
This is where the Model Context Protocol (MCP) does its most important work: standardizing how context is packaged, transmitted, and acted on across two autonomous systems.
Let’s walk through the full lifecycle of a hotel or flight search, from the moment a human expresses intent to the moment the result is returned.
Step 1: The Human Delegates
It begins with a natural instruction: “Find me a direct flight to Rome under $500, window seat preferred, leaving April 20th.”
Your personal agent hears this. But before it acts, it turns to its internal MCP Server, which has access to:
Your digital identity
Travel preferences and historical patterns
Your calendar, which confirms you’re free
Your budget constraints
Verified payment tokens
The MCP Server assembles this into a structured context payload and passes it to your MCP Client - the software agent responsible for executing the action.
Step 2: Customer MCP Client Initiates Contact
Your agent now reaches out to the travel platform's MCP Client using a secure, signed request. This handshake includes:
The task intent (“search_flight” or “book_hotel”)
Your constraints and preferences (price, dates, airline choices)
Your identity token (for personalization and trust)
Optional instructions like “Hold result, don’t book yet”
This isn't scraping a website. It’s not filling out a form. It’s API-native negotiation between two structured agents.
Step 3: Travel Agent MCP Client Forwards to MCP Server
On the travel side, their MCP Client receives your request and passes it into their MCP Server, which can access:
CRM (customer records, loyalty tiers)
Inventory systems (flight databases, hotel availability)
Pricing logic and promotional rules
Internal business rules (like airline partnerships or upsell targets)
This MCP Server also interprets security permissions, ensuring that only valid, signed, and trusted requests are processed.
Step 4: Response is Composed
The travel agent’s MCP Server compiles matching results, constrained by:
Your preferences
Availability and pricing
Internal priorities (e.g., showing preferred partners)
Legal and compliance policies (e.g., honoring data scopes)
It sends these back to the travel MCP Client, which routes them securely to your agent.
Step 5: Your Agent Interprets and Responds
Your MCP Client receives the response and may:
Filter or re-rank the options based on your deeper preferences
Present them to you conversationally
Suggest actions like “Hold seat” or “Book now”
Trigger calendar entries or send confirmation emails
Critically, no raw browsing, scraping, or manual entry took place. Every step was machine-readable, governed, and purpose-built for interoperability.
How digital wallets and data stores power personalization
Let’s zoom in on the two most underappreciated systems in the agent-to-agent model: the customer’s digital wallet and the personal data store (PDS) behind it.
If the Model Context Protocol defines the rules of engagement, then the wallet and PDS provide the fuel. The raw, personalized context that makes agentic decisions accurate, trusted, and human-centric.
A) On the Customer Side: The Personal Context Engine
When your agent begins a task, say searching for a flight, it turns to the customer-side MCP Server, which performs three critical roles:
Identity Verification
It confirms who the user is, using verifiable credentials.
These might come from a government-issued digital ID, a loyalty provider (e.g. Delta, Marriott), or even an enterprise SSO system.
This ensures the agent is acting on behalf of a real person with known entitlements.
Preference and History Retrieval
It queries your personal data store, which could be decentralized (e.g. Solid Wallet), cloud-based or embedded in your device.
This includes: preferred airlines, seating choices, past travel dates, loyalty programs, budget ranges, even accessibility needs.
Think of this as your “agentic memory” - not something the AI model remembers, but something your system delivers as structured context.
Tokenized Payment and Permissions
Your wallet grants the agent scoped, temporary access to payment credentials (via Apple Pay, Google Pay, or crypto rails).
You might also define a budget cap or require confirmation for bookings over a threshold.
These parameters are enforced by the MCP server, not hardcoded into the model.
When these three components are combined, your MCP Client sends a highly structured payload to the travel agent that might look like:
This isn’t browsing any more.
It’s delegated intent, embedded with trust, context, and rules.
B) On the Travel Agent Side: Trust and Matching Logic
Once the travel platform receives this payload via its MCP Client, it turns inward to resolve the request.
The travel-side MCP Server acts as an orchestrator, routing the request through:
CRM or CDP systems: Is this a known customer? Do we have past bookings or tiered loyalty benefits?
Inventory engines: What flights or hotels match the request?
Business rules and policy filters: Are there promotions? Can we upsell? Are there blackout dates?
Critically, the server must evaluate:
Identity trust: Is this a legitimate, non-malicious agent request?
Context alignment: Do the preferences match known capabilities?
Execution authority: Does the agent have permission to hold or book?
The travel MCP Server responds with structured results - flight or hotel options, pricing, and next actions - clearly scoped and tagged by metadata (e.g., refundable, holdable, loyalty-eligible).
While the architecture makes this flow appear seamless, the underlying complexity on the travel system side is significant.
Inventory, availability, and pricing often depend on a two-stage flow. Where fast search responses are generated from cached combinations, and exact pricing or rules are validated only later, especially in cases involving flights, bundled offers, or package products.
This orchestration is what enables agents to deliver the experience consumers increasingly expect, even when business logic varies dramatically behind the scenes.
And this interaction changes the game. Because now:
The customer didn’t browse.
The business didn’t guess.
Two agents completed a task based entirely on structured context.
There’s no form to fill.
No checkout to convert.
No CAPTCHA to click.
Just systems acting on behalf of their stakeholders, in real time, through shared trust and machine-readable context. That’s what makes agentic commerce powerful.
But more importantly, it’s what makes it safe.
Preparing for a World Where Agents Are Your Customers
Right now, business analytics dashboards are filled with metrics like bounce rate, time on site, click-through, and cart abandonment.
But in the near future, you’ll have a new kind of visitor.
One that doesn’t scroll, doesn’t click, and doesn’t hesitate. It will land on your site not as a person, but as an agent, carrying the full context of your customer’s intent.
And here’s the critical shift: That agent will decide whether or not you matter.
So what should you be doing now?
1. Make Your Services Machine-Readable
If your product catalog, availability, and pricing logic are only exposed through HTML and JavaScript, an agent can’t engage with you. Implement structured, API-accessible interfaces, or better yet, adopt standards like Model Context Protocol to make your business legible to autonomous agents.
2. Recognize and Prioritize Trusted Agents
Just as you segment customers today (e.g., first-time vs. repeat buyers), tomorrow you’ll segment agents:
Malicious bots
Basic screen-scrapers
Legitimate, unauthenticated agents
Fully authenticated, high-trust agents with verified customer context
Treat these tiers differently. Invest in identity negotiation. Use wallet-based verification. Don’t turn away valuable customers just because they showed up as machines.
3. Support Context Exchange
You must be ready to receive structured context from external agents. That means:
Accepting identity tokens
Respecting privacy and permission scopes
Matching requests to your inventory and policy engine
Don’t wait until your competitors are already doing it. Context compatibility will be the next differentiator in conversion.
4. Redesign for Headless Interaction
What happens when there is no user interface? How do you deliver your value proposition when there’s no homepage, no form, no funnel?
Start thinking in task-level APIs. Structure your offerings so agents can:
Search
Negotiate
Purchase
Request support
All through protocols, not pixels.
5. Reframe Success Metrics
If your customers don’t visit your website, how do you measure success? New KPIs will emerge:
Agent acceptance rate
Task fulfillment latency
Context match accuracy
Wallet-based transaction volume
Start tracking what happens before a user shows up, because soon, they might not.
A different kind of economy - and the arrival of A-Commerce
The future of commerce won’t be defined by more automation. It will be defined by a new architecture of interaction.
One where context arrives before the customer, and where decisions are executed invisibly, without a screen or a scroll.
This is ‘A-Commerce’, and what agentic systems enable. It’s what the Model Context Protocol was built to support. And it’s what digital wallets already secure and personalize.
Together, they create the infrastructure for a different kind of economy. One where software doesn’t just respond, but represents.
So the real question isn’t whether your business will join this future. It’s already arriving.
The real question is: Will your systems be ready when the agent comes knocking - not with a query, but with intent in hand?
Thanks Gam! Another banger of a deep dive.
Look out for more deep dives coming soon, with experts from across the Customer Futures Network getting to the heart of the big Empowerment Tech topics. From Personal AI and regulation, to digital wallets and payments. And much more.
All of it, of course, is about understanding the future of being a digital customer. So thanks again for coming back to the Customer Futures newsletter.
Until next time,
Jamie
And that’s a wrap. Stay tuned for more Customer Futures soon, both here and over at LinkedIn.
And if you’re not yet signed up, why not subscribe: