Ask an AI agent to find you a restaurant for Saturday night. It will give you a name. Maybe three names. Maybe a phone number and a link to the website. Then it stops, and you're on your own — calling to check availability, navigating a clunky reservation system, figuring out if they can handle your friend's nut allergy.
This is where every AI agent in the world stalls out today. They can discover. They can't transact. And the gap between "here's a recommendation" and "it's booked, confirmed, here's the details" is where most of the value in local commerce actually lives.
The agent that closes the loop — that goes from discovery to transaction in a single interaction — is the one that wins. But to get there, agents need data infrastructure that doesn't exist yet.
The three stages of an agent query
Every local commerce query passes through three stages, whether the user realizes it or not.
Stage 1: Discovery. Find businesses that broadly match the request. "Italian restaurants in Calgary." "Hotels in Banff." "Dog groomers near me." This is the stage that search engines have handled for twenty years, and it's the stage that today's AI agents can do competently. Give me names in this category, in this location.
Stage 2: Qualification. Narrow the list to businesses that match the specific intent. Not just "Italian restaurant" but "Italian restaurant with a private room that seats eight, available Saturday, under $80 per person, with celiac-safe options." Qualification requires detailed, current data about the business — capabilities, availability, constraints, pricing. This is where most agents fail, because this data rarely exists in a structured, queryable form.
Stage 3: Transaction. Complete the action. Book the table. Reserve the room. Schedule the appointment. Confirm the details. Handle payment if needed. Send confirmation to both the customer and the business. This is where virtually no agent operates today, because transactions require structured APIs, real-time availability checks, and business systems that can accept programmatic bookings.
Today's AI agents handle Stage 1 and then hand you a phone number for Stages 2 and 3. That's like a travel agent who finds a hotel name and then tells you to call them yourself. The value is in the last mile, and the last mile is missing.
Why agents get stuck at discovery
The bottleneck isn't model intelligence. GPT-4, Claude, Gemini — any of these models could orchestrate a multi-step booking flow. The agent could easily coordinate "check availability, select option, confirm booking, send receipt" if it had the data and the endpoints.
The bottleneck is data.
For qualification, agents need structured data about what each business can actually do: room types and configurations, menu accommodations, service specializations, group size limits, real-time availability. Most businesses don't have this data in any machine-readable format. It's on their website as prose, or in their reservation system behind a login, or in the manager's head.
For transactions, agents need even more: booking endpoints that accept programmatic requests, confirmation flows, cancellation policies, payment handling. The plumbing doesn't exist. A few large platforms (OpenTable, Booking.com, Calendly) offer APIs for their categories, but the vast majority of local businesses — the independent restaurant, the local mechanic, the boutique hotel — have no programmatic booking interface.
The result: agents are brilliant at Stage 1 (which requires only public web data) and helpless at Stages 2 and 3 (which require structured, real-time, business-specific data).
What the qualification layer looks like
Qualification is the most underappreciated stage because it looks simple from the outside but is deeply data-intensive.
Consider what happens when a user asks: "Find me a boutique hotel in Banff for next weekend, pet-friendly for a 70-pound dog, with a fireplace, under $250 per night."
To qualify a hotel against this intent, the agent needs to know:
Does the hotel allow pets? What's the weight limit? Is there a pet fee? What room types have fireplaces? Are any of those rooms available for next weekend? What's the rate for those specific rooms on those specific dates? Is the rate within budget after fees and taxes?
Each of these is a data point that exists somewhere — in the hotel's property management system, in the front desk manager's knowledge, in the pet policy buried on page three of the website. But none of it is available in a structured format that an agent can query programmatically.
Now multiply by every hotel in Banff. The agent needs to run this qualification check against twenty or thirty properties to find the handful that actually match. Without structured data, the agent either guesses (and gets it wrong) or gives up and says "here are some pet-friendly hotels in Banff, you should call to check details."
A proper qualification layer would let the agent query: {"sector": "hospitality", "location": "Banff", "pet_weight_min": 70, "amenity": "fireplace", "available": "2026-01-17/2026-01-19", "max_rate": 250} and get back a ranked list of matching properties with real-time availability and actual rates. That query takes milliseconds against structured data. It takes thirty minutes of phone calls against the current state of the world.
What the transaction layer looks like
Beyond qualification, the transaction layer requires businesses to expose booking, scheduling, or purchasing capabilities through a programmable interface.
For some sectors, this already exists in fragmented form. OpenTable handles restaurant reservations. Booking.com handles hotel bookings. Calendly and Acuity handle appointment scheduling. But these platforms serve their own ecosystems — the data stays within their walls, and access requires platform-specific integrations.
For the independent businesses that make up the bulk of local commerce — the family Italian restaurant, the independent mechanic, the local yoga studio — there's no programmable booking interface at all. The "API" is a phone call. The "booking system" is a paper calendar or a Square appointment widget that doesn't expose availability data.
The transaction layer will emerge when structured data and booking intent converge. A business that has already shared its availability, pricing, and constraints through a data layer like Pawlo is most of the way to enabling transactional booking. The additional step — actually confirming the booking — is smaller than it appears once the qualification data exists.
In practice, the transaction layer might look like this for a hotel booking: the agent queries Pawlo's MCP for matching hotels with availability. It receives structured results including rates, room types, and booking constraints. It presents options to the user. The user selects one. The agent sends a booking request through the data layer to the hotel's system (or to the hotel directly via SMS/email confirmation). The hotel confirms. The agent sends confirmation to the user. End to end, the user went from "find me a hotel" to "confirmed booking" without leaving the conversation.
Who captures the value
In any transaction chain, the entity that enables the most critical step captures the most value.
In Google's model, the critical step was discovery (finding the business), and Google captured value through advertising. In the platform era, the critical step was aggregation (having all the options in one place), and platforms like Booking.com captured 15-25% commissions for enabling it.
In the agent economy, the critical step shifts to qualification and transaction — not just finding a business, but confirming it matches and completing the action. The data provider that enables agents to go from discovery through qualification to transaction captures the most value in the chain.
This is why the data layer matters more than the agent itself. Agents are the interface — they talk to users and orchestrate the workflow. But the data layer is what makes qualification and transaction possible. Without structured, real-time business data, the agent is stuck at discovery and the value chain breaks.
The platforms that exist today (OpenTable, Booking.com, etc.) own the transaction layer for their categories. But they only cover a fraction of local commerce. The restaurant without OpenTable, the hotel not on Booking.com, the mechanic who only takes phone calls — these businesses represent the majority of local commerce, and they have no transaction layer at all.
Building that layer — structured data that enables discovery, qualification, and eventually transaction for the businesses that today's platforms don't serve — is the largest uncaptured opportunity in local commerce infrastructure.
The timeline
This won't happen all at once. The progression will be:
Now through 2026: Agents get better at discovery and begin basic qualification using whatever structured data they can access. The businesses with the best-structured data get disproportionate recommendations. Transaction remains manual (phone calls, website bookings).
2027-2028: Qualification becomes reliable for businesses that have structured their data. Agents can confidently say "this hotel matches all your criteria and has a room available at $209." Transaction begins for categories with existing APIs (restaurants, hotels on platforms, appointment-based services with Calendly-like tools).
2029+: Transaction becomes standard. Agents book, reserve, and schedule as a normal part of handling a query. The user says "find me something and book it" and the agent does. Businesses without a programmable interface for availability and booking are functionally invisible to this channel.
The businesses and data providers that start building the qualification and transaction infrastructure now will be the rails that agent-mediated commerce runs on. The ones that wait will be left with the same choice businesses faced in 2005 when they didn't have a website: adapt late, or become invisible.