- Inventory, prices and policies readable by agents without scraping
- Bookings that require an explicit human approval step and cannot be duplicated
- Agent traffic routed, limited and measured separately from human traffic
- A clear basis for personal data use under the PDPA
- Partners able to integrate through a documented interface
Anonymised composite. Client names, identifying details and confidential figures are withheld; public facts are cited in the references.
The situation
A travel marketplace serving Singapore and its neighbours sold hotels, flights and activities through a website and app. Its traffic already included price scrapers and comparison bots, handled with blocking and rate limits. Its booking flow assumed a person clicking through screens.
Why now. In late October 2026, Meta made its personal AI agent, Muse, available in Singapore, with partners including Shopee, Grab, Singapore Airlines, Agoda and Trip.com12. Coverage describes the agent building a basket and waiting for the person's approval before ordering, and asking for approval before sensitive steps such as purchases2. For a travel business, that means some customers will arrive through an assistant rather than the app, and the marketplace either offers agents a good way in or watches them book elsewhere. See the tech news update for 29 October.
What had to be true
- Agents read the truth: inventory, total prices, fees and cancellation rules available as structured data, not scraped from pages.
- No booking without a person's approval, and no duplicate bookings from retries.
- Agent traffic isolated, so a busy agent platform cannot slow down human customers.
- Clear data protection basis for using personal data in recommendations under Singapore's PDPA.
- One interface for many agents, not a custom integration per assistant.
Architecture
The data flow, end to end
- AskA person asks their assistant for a hotel and flight within a budget
- SearchThe agent queries the structured search API or MCP tools
- QuoteFull price, fees and cancellation terms returned as data
- HoldInventory held briefly under an idempotency key
- ApproveThe person approves in their assistant; the approval is recorded
- BookBooking and payment confirmed once; retries return the same result
The agent-facing tools followed the Model Context Protocol so different assistants could use the same interface5. Security for those tools followed the practices in securing MCP servers, and the idempotent booking design reused patterns from idempotent payment pipelines.
The hard part: serving agents without hurting people
Agent platforms can generate bursts of searches as they compare options for thousands of users at once. The answer was to route agent traffic to its own backends with its own limits and capacity, so a spike from one assistant never slowed the app. The Kubernetes Gateway API made this declarative: routes can match on headers, such as an authenticated agent identifier, and split or direct traffic to different services4.
Treat agents as a customer channel, not as bots to block. Give them a front door, rules and limits, and they become measurable revenue instead of unmanaged load.
On personal data, the PDPC's advisory guidelines explain how consent and notification obligations, and their exceptions, apply when personal data is used in AI recommendation systems3. Recommendations to agents used only the data needed for the request, and anything personalised was tied to a recorded basis. More on the rules in fractional CTO in Singapore.
How it ran
- Which partners and agents
- Pricing and fee transparency
- Partner terms
- Structured search API
- Hold, approve and idempotent booking
- Gateway routing and limits
- PDPA basis per use
- Fraud signals for agent traffic
- Audit trail of approvals
- Structured inventory
- Prices and policies as data
- Agent traffic measured
- Hold and approve
- Idempotent booking
- Pilot with one partner
- Gateway routing
- Per-agent limits
- Separate capacity
- MCP tools
- Partner onboarding
- Conversion by channel
Key decisions and trade-offs
| Decision | Alternative | Why |
|---|---|---|
| Serve agents through an API | Block or tolerate scraping | Accurate data, control and a measurable channel |
| Hold and approve before booking | Let agents book directly | A person's consent for every purchase, fewer disputes |
| Idempotency keys on every booking call | Rely on agents not retrying | Agents retry; duplicates are expensive |
| Separate routing and capacity for agents | One shared backend | Agent bursts cannot degrade the app |
| Standard protocol for tools | Custom integration per assistant | One interface, many agents |
What I'd do again, and differently
Again: make prices and policies machine-readable first; it improved the human site too. Differently: involve finance and customer service earlier. Approval, refund and dispute flows for agent bookings raised more questions than the APIs did. Related reading: structured data for AI search and MCP registries for enterprises.
If your customers are starting to arrive through AI assistants, my AI architecture work and work in Singapore and Southeast Asia explain how I approach it, or analyse your challenge and bring the result to a call.
- 1Muse is now available in SingaporeMeta · Oct 2026
- 2Meta's Muse AI agent arrives in Singapore with Grab, Shopee and moreFintech Singapore · Oct 2026
- 3Advisory Guidelines on use of Personal Data in AI Recommendation and Decision SystemsPersonal Data Protection Commission · Mar 2024
- 4Evolving Kubernetes networking with the Gateway APIKubernetes blog · 22 Apr 2021
- 5Model Context Protocol specificationModel Context Protocol