By KYN AI Advisory Team — AI implementation specialists, Singapore
An agent can reply to meeting requests by reading your calendar, applying fixed rules and offering or confirming a slot. Double booking is avoided by three controls: one calendar as the source of truth, a short hold on any slot it offers, and a final availability check at the moment of confirmation. Rules decide the slot. The model only writes the wording.
Why do double bookings happen?
Almost always from a gap in time between two actions. A slot is offered at 9:00. Another person books it at 9:05. The first person accepts at 9:20. Nothing checked again.
Four causes cover most cases.
- Several calendars. Work, personal and a shared team calendar disagree.
- Offers without holds. The slot is offered but not reserved.
- Time zones. A request at "3pm" is read in the wrong zone.
- Travel and buffers ignored. Back-to-back meetings in different places.
An agent makes each worse if built carelessly, because it replies faster than a person and to more people. It also fixes each cause if the rules are written down.
What rules should the agent follow?
Write them as plain conditions. A calendar rule that cannot be stated in a sentence is too vague to automate.
| Rule | Example setting | |---|---| | Working windows | Mon to Thu, 10:00 to 17:00 local time | | Meeting lengths | 15, 30 or 45 minutes only | | Buffer | 15 minutes before and after each meeting | | Daily cap | No more than four external meetings a day | | No-meeting blocks | Friday afternoon, school run, prayer times | | Lead time | Nothing sooner than 4 working hours ahead | | Travel | Add the travel time for in-person meetings | | Who may auto-book | Existing contacts and replies labelled interested |
These are your settings, not recommendations. The point is that each is a check the code can run. If a request breaks any rule, the agent does not accept it. It proposes alternatives from within the rules, or hands the request to a person.
How does the booking flow work?
Follow six steps.
- Read the request. The agent extracts the proposed time, length, attendee and place or link.
- Normalise the time. Convert to your zone and the attendee's zone. Show both in the reply.
- Check the rules. Run the table above against the request.
- Check the calendar. Read the free and busy view of every calendar that counts, including the team calendar.
- Hold, then reply. If the slot is free, place a tentative hold for a short period, such as 30 minutes, and send the confirmation or the offer.
- Confirm with a re-check. When the attendee accepts, check again. If the slot is still free, convert the hold to a booking. If not, offer new times and say why.
Step 6 is what prevents the 9:05 problem. A hold is a placeholder visible to other bookers. A re-check is the guard if the hold failed or expired.
What should the agent never confirm alone?
Some meetings carry weight beyond the diary. Make the agent hand these to a person.
- A first meeting with a new contact from an unknown source.
- Any meeting with a regulator, auditor, lawyer or bank.
- A request to move or cancel a meeting already booked with a client.
- Any meeting that requires travel outside the city.
- A request from a senior person that conflicts with a rule.
These are judgement calls about relationships and priority. The agent can prepare options and a draft. A named person decides. See approval gates for high-risk agent actions.
How should the reply read?
Short, with the time shown in both zones and one clear action.
Thanks, Mei. Thursday 14 November, 11:00 to 11:30 Singapore time (10:00 Jakarta) is free. I have held it for you until 17:00 today. Reply "yes" to confirm, or suggest another time.
Avoid long lists of options. Offer two or three slots. Include a video link or address in the confirmation, not in the offer.
If you decline, say why in one clause and offer an alternative: "I am not available that day. Tuesday morning is open."
How do you test the rules before going live?
Run the agent in draft mode for two weeks. It writes each reply, but a person sends it.
- Replay 50 past requests and compare the agent's answer with what actually happened.
- Create deliberate clashes: two requests for the same slot a minute apart, a request across a daylight-saving change, a request from a zone with a half-hour offset.
- Count clashes found per 100 requests. The target is zero double bookings. Anything else sends you back to the rules.
Log every decision with the rule that fired. When a person asks why the agent declined, the log answers.
What does a worked example look like?
Take an illustrative request that arrives on Monday at 08:12: "Can we meet Thursday 3pm Jakarta time?" The rules are those in the table above.
- Read. Proposed time: Thursday 15:00 WIB. Length not stated, so the default of 30 minutes applies.
- Normalise. 15:00 WIB is 16:00 in Singapore.
- Rules. Thursday is a working day. 16:00 to 16:30 sits inside the window. The daily cap is not reached.
- Calendar. Free and busy shows a client call ending at 16:00. The buffer rule requires 15 minutes, so 16:00 fails.
- Alternatives. The agent offers Thursday 16:30 Singapore time (15:30 Jakarta) and Friday 11:00 Singapore time.
- Hold. It places a tentative hold on 16:30 for 30 minutes, then replies. The attendee accepts at 08:50. The agent re-checks, finds the slot free and books it.
Every step is a rule or a calendar read. The model wrote only the wording of the reply.
What edge cases should you test?
| Case | What should happen | |---|---| | Two requests for one slot a minute apart | First holds the slot; second receives alternatives | | Request across a public holiday in one country | Flag the holiday and offer other days | | Request that gives only "next week" | Ask for a day range; do not guess | | Attendee replies after the hold expires | Re-check; book if free, otherwise offer new times | | Recurring series | Hand to a person; automate single meetings first | | Meeting moved by the attendee | Release the old slot, then repeat the flow |
Release holds the moment a request is declined or expires. An orphan hold blocks a slot that nobody will use.
Where KYN fits
KYN builds calendar and reply agents as part of a sales system or an operations system, running in your own cloud account. The agent has its own restricted account with calendar access limited to free and busy, plus write access only for holds. Every action is logged with the actor. Messages that carry your name wait for a named person until you have measured the desk and chosen what may run alone.
The first 14 days are a review of your stack and interviews with your team. A full build ships in under 90 days. You can revoke KYN's role and everything keeps running.
Frequently asked questions
Can an AI agent read my whole calendar?
It does not need to. Give it free and busy status, plus titles only for meetings you mark as shareable. Restricted access also limits what leaks if a credential is misused.
What happens if two people request the same slot?
The first request places a hold. The second request sees the slot as busy and receives alternatives. Both outcomes are logged.
Does the agent handle time zones for Singapore, Jakarta and Hong Kong?
Yes, if the zone is stored for each contact and each time is shown in both zones in the reply. Test requests that cross a date line and a half-hour zone before going live.
Checked 30 October 2026.
Curious whether Marketing agents fits your business? Talk to KYN on WhatsApp — no forms, just a conversation.
