Multi-Agent + MCP: A Practical AI Solution for Hotel Group Booking

Hotel group bookings have long been trapped in back-and-forth emails and manual quoting. A single inquiry for a wedding or conference—covering room availability, pricing, and contract drafting—can take a sales coordinator hours, sometimes a full day. The group booking case study released by the AI/MCP Agent™ platform demonstrates a new path: using two agents with clearly separated roles, connected to the hotel management system via the MCP protocol, to compress the inquiry-to-proposal workflow down to seconds.

Two Agents, Two Approaches to Division of Labor

The most thought-provoking aspect of this solution is that it doesn't dump every task onto a single "all-purpose agent."

The first role is the Group Operations Agent, whose job is number-crunching. After connecting to the hotel PMS through MCP (an open standard that provides agents with real tool-calling capabilities), it is authorized to use three tools: checking room availability, booking rooms, and calculating total group pricing. Upon receiving an inquiry, it parses room type, room count, and stay requirements, confirms that inventory actually exists, and then returns a concrete total group quote. According to the video demo, when faced with an inquiry for "15 king rooms, two nights, corporate team-building," this agent can directly pull PMS data to confirm availability and return a real price.

The second role is the Revenue & Contracts Agent, and its defining trait is the opposite—it has no tools at all. Once the Operations Agent finishes pricing, this specialist takes over, reasoning over the specific numbers passed in, restating the room block information, attaching standard terms (deposit, cutoff date, cancellation policy), and assembling a ready-to-send proposal. Its instructions explicitly require it to "use only the rates given to it, and never invent new numbers."

This "one with tools, one pure reasoning" pairing breaks the reflexive assumption that "an agent must be connected to tools to be valuable." In some steps, the core capability is careful assembly and judgment—not external calls.

MCP (Model Context Protocol) is an open protocol proposed by Anthropic in late 2024, designed to provide large language models and agents with a standardized way to call external tools and data sources. Previously, connecting an agent to different systems (such as databases, CRMs, or calendars) often required writing separate adapter code for each one, with inconsistent interface styles and high maintenance costs. MCP essentially defines a unified plug and data format for "agents calling tools": a tool provider only needs to implement an MCP server once, and any MCP-compatible agent can use it directly. This also explains why the same dual-agent workflow described here can simultaneously connect to a hotel PMS and a SIP-based telephony provider—as long as each exposes an MCP interface, the agent side needs no changes.

PMS (Property Management System) is the core software for daily hotel operations, managing key data such as room inventory, rates, reservations, check-in/check-out, and billing. When the front desk sees "is this room available tonight" or sales gets a "group negotiated rate," that information fundamentally comes from the PMS. So when an agent needs to answer "are 15 king rooms available for two nights, and what's the total price," it must query the PMS in real time rather than rely on static knowledge memorized during training—this is precisely why MCP tool calling exists.

Structured Handoff: The Key Constraint in Multi-Agent Collaboration

The classic challenge of multi-agent systems is: how do agents pass information to each other without distortion?

The platform orchestrates this using a visual canvas called the "Multi-Agent Flow Designer." The flow runs left to right: receive inquiry → Operations Agent prices → Contracts Agent drafts → done. Each box corresponds to an agent, and the palette offers building blocks such as conditional branches and parallel-then-merge. The entire process requires zero code.

What truly makes the two agents mesh is the contract mechanism of structured output. The Operations Agent produces a structured "room block pricing" object, and the Contracts Agent declares that same structure as its input. The Operations Agent confirms rooms and packages the rates and total price, and the Contracts Agent receives exactly those numbers—so the proposal always matches the actual quote. You'll never see a quote of $8,000 with a contract that says $10,000.

The platform automatically handles the handoff from one specialist to the next. After each run, the chat history panel also shows the precise cost of the entire run, making it easy to monitor spending during testing.

Structured Output means having the model return data objects that strictly conform to a predefined schema (such as JSON) instead of free-form text. In multi-agent collaboration, this is equivalent to giving the downstream agent an "interface contract" with fixed fields: the upstream agent can only fill in the agreed-upon fields (e.g., room_type, room_count, nightly_rate, total_price), and the downstream agent only reads those fields. Compared to letting agents "converse" in natural language, structured handoff significantly reduces the risk of information being rewritten, omitted, or fabricated during transfer. The distortion scenario described in the article—"quoted $8,000 but the contract says $10,000"—is exactly the kind of problem most likely to occur without a contract-based handoff.

Agent Orchestration is the engineering practice of organizing multiple agents in sequential, branching, or parallel relationships to complete tasks collaboratively. A visual orchestrator (the "Multi-Agent Flow Designer" mentioned in the article) lets developers define workflows by dragging boxes and drawing connections, while the underlying system automatically handles context passing, error retries, and state management. For linear workflows involving only two or three roles, the orchestrator's value lies in lowering the engineering barrier—no scheduling code required to reliably run the "inquiry → pricing → drafting" chain.

Three Deployment Channels: Website, Agent Assist, and Phone

Once the flow passes testing, saving it publishes an agent code, and the entire dual-agent team can be deployed to any scenario where customers plan events. According to the video, the solution supports three delivery methods.

Website-embedded chat widget is the most direct option. A meeting planner describes their needs in the chat box on the hotel's website—for example, "15 king rooms for two nights"—the Operations Agent confirms rooms and prices them, the Contracts Agent drafts a proposal, and the planner immediately gets a real group rate and a reviewable proposal, without waiting a day for an email reply.

Chat Assist is aimed at hotel sales coordinators. While conversing with a planner, the coordinator hands the requirements to the AI assistant, which runs the same dual-agent workflow and prepares a draft reply. The coordinator reviews it, adds a personal touch, and sends it. The agent handles pricing and paperwork; the human builds relationships and wins the deal.

Phone channel leverages the standardized nature of MCP agents. The same Operations and Contracts team can connect to a SIP-based telephony provider to answer real calls. Planners can simply call and describe their group needs, and receive availability, group pricing, and a proposal via voice. A phone settings panel manages numbers, call logs, and diagnostic information.

One team, covering all three entry points: website, online chat, and phone.

SIP (Session Initiation Protocol) is the most universal signaling standard in internet telephony, responsible for establishing, modifying, and terminating voice and video calls. The vast majority of cloud call centers and IP telephony providers offer interfaces based on SIP. When an agent platform can connect to a SIP provider through MCP, it means the same reasoning logic can seamlessly extend from text chat to real-time voice scenarios: caller numbers, call status, speech-to-text, and response synthesis can all be handled through standard protocols, without rewriting a separate agent stack for the phone channel. This is also the key reason why "one team covering three entry points" is engineering-feasible.

The Real Takeaway from This Case Study

Setting aside the hotel industry itself, this case offers several transferable insights for agent system design.

More tools isn't better. The Operations Agent needs precise tool-calling capability, while the Contracts Agent needs pure reasoning with zero tools. Merging both into a single agent could instead create a fuzzy boundary where it "can both check inventory and make up terms," increasing hallucination risk.

Structured handoff is more reliable than natural language transfer. Defining the interface between agents with data structures—where the producer declares what it outputs and the consumer declares what it accepts—is far more stable than letting them converse freely.

Multi-agent doesn't have to be complex. Two agents and one linear flow are enough to cover a real business scenario. The branching and parallel capabilities the platform offers are optional complexity, not an entry barrier.

Agent systems are moving from "solo combat" to "team collaboration." This hotel group booking case shows that what matters in a team isn't headcount—it's that each role has clear boundaries and reliable handoffs.

Additional Background

Agent Assist is an intermediate form between "fully automated" and "purely human": the AI doesn't face the end customer directly, but instead generates suggested replies, summaries, or next actions alongside sales or support staff, who review before sending. This model is especially common in high-value, relationship-driven scenarios like hotels, insurance, and telecommunications—AI handles repetitive pricing calculations and document drafting, while humans retain final judgment and relationship management. It avoids the reliability risks of fully automated customer service in complex negotiations, while dramatically reducing the time it takes to handle a single inquiry manually.

One-line Summary

A hotel group booking case study showcases a dual-agent architecture: one connected to the PMS for pricing, one pure reasoning for drafting, with structured handoffs compressing the inquiry process to seconds.

Paragraph Summary

This article introduces a hotel group booking agent case study based on the MCP protocol. The solution uses a dual-agent division of labor: the Group Operations Agent connects to the PMS via MCP, calling three tools—checking rooms, booking rooms, and calculating total pricing—to handle real pricing; the Revenue & Contracts Agent uses no tools and simply assembles terms and proposals based on the structured numbers passed in. The two complete their handoff through a structured "room block pricing" object, ensuring the contract price strictly matches the quote. The entire flow is orchestrated with zero code on a visual canvas, and once published, the same agents can be deployed simultaneously to the hotel website chat widget, sales Chat Assist, and SIP phone channel. The takeaway: more tools isn't better, structured handoff is more reliable than natural language transfer, and multi-agent doesn't have to be complex.