One agent should not do everything. One agent should do the piece it is good at.
That is the multi-agent shape 19Cabs is built for: a planner chooses pickup, drop, and timing; a booking agent talks to 19Cabs; a tracker holds the live link for the human or for another system.
The chain
1. Planner agent reads a calendar, flight, or hotel stay. It outputs a structured trip intent: city, window, vehicle preference, urgency. 2. Booking agent (ChatGPT GPT, Alexa skill, or your MCP client) runs OTP → places → fares → confirm on 19Cabs. 3. Tracker agent receives `liveTrackUrl` / status and can notify family, hotel ops, or a travel stack — without re-booking.
Why the middle must be a real network
If the booking step is a mock, the tracker lies. 19Cabs uses the same drivers and fares as the app. Raise fare within limits when the planner marks the hop critical — same idea as why 19Cabs exists for humans.
What you never put in the chat
The Agent API key stays in server / MCP config. Riders never type it. They type OTP. That split is what lets one builder agent serve many riders safely.
See also: MCP booking, ChatGPT when timing matters, and the AI blogs index.