Xaply
Books meetings from WhatsApp and Gmail threads by reading the conversation and proposing times.
Most scheduling tools ask you to leave the conversation. You agree to meet, then you open a calendar or paste a booking link and wait. Xaply stays in the thread. Write "book something with Sarah on Thursday afternoon" and the meeting appears on the calendar with the invitation sent.
Product
Conversational calendar assistant
Channels
WhatsApp, email threads, web app
Calendar
Google Calendar, several per user
Status
Owned and operated by ErlyStage
Scheduling in plain language breaks in boring ways.
Next Tuesday is ambiguous to most people and to nearly every model. Someone sends three messages before the first is answered. A user has four connected calendars and the agent picks the wrong one. An access token expires halfway through a booking. None of these are solved by a better prompt.
The hard parts are handled below the model.
Dates resolve through ISO week logic rather than inference. Messages queue per user with a lock. Tool arguments are checked before execution and repaired once on failure. Timezones resolve through a fixed order. That is what separates a demo from something people put their real calendar into.
From a message to an invitation.
What happens between someone typing a request and the meeting existing.
The message arrives
A webhook delivers it, the sender is matched to a user by phone number, and the message enters that user queue.
The queue holds order
People type in fragments. Messages for one user are processed in order with a lock, so a second worker stands down rather than producing three partial bookings.
An acknowledgement goes out
Written from the message itself rather than pulled from a fixed list, because silence during a calendar read and write reads as failure.
The agent books
It checks availability, writes the event, and replies in the same thread. History is stored per user and retrieved by relevance rather than as a fixed window.
A defined set of tools and nothing outside them.
Availability is checked before booking, never after. The agent asks whether a meeting is virtual or in person rather than guessing, because both wrong answers waste someone time. It never invents a duration, a time or an address.
Dates that resolve correctly
Weeks run Monday to Sunday. This Thursday is the Thursday of the current week. Next Thursday adds seven days and can never land inside it, which is the exact error that books a meeting a week early.
Someone else calendar
A user can connect the conversation to another person calendar. The agent then says whose calendar it is checking, and reads the connection fresh rather than inferring it from earlier in the thread.
Scheduling links
Each connected calendar produces a booking page showing real availability, and a WhatsApp link that opens a chat already addressed to the right calendar. Both embed into a site.
Availability
Recurring weekly hours with one off exceptions layered over them, plus a holiday calendar, so public holidays are excluded without anyone remembering to block them.
Three mechanisms for the failures that actually occur.
Arguments checked before execution
Every tool call is inspected before it runs. Missing or empty required arguments are caught at the boundary and returned as a clear error rather than a partial booking.
Repair and retry
When a call fails, the error and its arguments go to a smaller model whose only job is to correct the inputs. It cannot change what the function does. The call is retried once.
Outcomes logged
Every invocation writes the action, the result and any error against the user, which makes a scheduling failure diagnosable rather than a report that the assistant did not work.