TypeScript1
Look for booking help.
Search. Look for booking help before contacting the local business by phone.
Act. Check the matched agent’s coverage and required customer details.
Outcome. An agent match or a clear reason to use the phone fallback.
Platypus searches for booking help before calling a business
Look for booking help first, with a phone fallback when an agent cannot handle the request.
Developer project · Proposed Act workflow.
The build.
Platypus is a TypeScript application with an MCP gateway and a direct Darwin HTTP client. It checks Darwin before routing a booking to a Dial phone call. Its demo uses a fictional business, and the browser replay uses recorded responses.
The brief
Platypus checks whether an agent can book a requested local service, then falls back to a phone call when needed.
Finding the right capabilities
Darwin looks for a booking agent that covers the requested service, location, and time. A missing match sends the request to Platypus’s phone path.
Coordinating the work
On the agent path, the customer could compare appointment times and terms, then authorize one booking. Confirmation would depend on the provider’s response.
What comes back
A confirmed appointment or a clear pending, failed, or phone-fallback status. The customer knows whether anything has actually been booked.
The plan, step by step
- 2
Compare appointments.
Search. Continue with the matched booking agent; use Platypus’s phone fallback if none can handle the request.
Act. Request appointment times, prices, and cancellation terms using the approved customer details.
Outcome. Appointment options with terms and availability still to confirm.
- 3
Confirm the chosen appointment.
Search. Review the chosen appointment with the same booking provider.
Act. Submit the booking after customer approval and check the provider’s response.
Outcome. The provider’s confirmation, or an explicit pending or failed booking status.
Booking status.
Follow the request from capability check to appointment choice to the provider’s confirmation.
Agent match or phone fallback
Deliverable: An agent match or a clear reason to use the phone fallback.
Review criteria: Return a match or a clear no-match result. Keep the phone fallback separate from an agent response.
Original prototype by Karthik Subramanian and Eddy Zhao. The first booking is confirmed by phone. The next is confirmed by a text reply from the business.
Appointment options
Deliverable: Appointment options with terms and availability still to confirm.
Review criteria: Show the options before confirming. Do not treat a proposed time as a reservation.
Booking status
Deliverable: The provider’s confirmation, or an explicit pending or failed booking status.
Review criteria: Use only the appointment I confirm. Report a booking as complete only when the provider confirms it.
