What this agent does
A Calendly follow-up agent listens for booking events, treats each invitee as a small workflow, and runs the sequence from confirmation to either a held meeting or a no-show recovery. It is not a drip campaign. It is a finite state machine attached to one booking.
The state machine has five states: booked, confirmed, reminded, held, and recovered-or-closed. Each transition either triggers a draft email, files an activity in the CRM, or both. Drafts live in a private review thread for the host until shadow mode ends.
For a parallel pattern in another channel, see AI agent for inbox triage. For meeting-specific follow-up (post-call summaries), see AI agent for meeting follow-ups. For the cluster context, see what an AI agent can actually do.
Calendly scopes and permissions
Calendly's OAuth permissions are coarser than Slack's, but the principle of least privilege still applies. Per Calendly's developer documentation, the API exposes scopes for invitees, scheduled events, event types, webhook subscriptions, and routing forms.
For a follow-up agent, the read-only set is enough:
scheduled_events:readto fetch the event metadata, the host, and the start time.invitees:readto fetch the invitee's name, email, answers to scheduling questions, and any UTM parameters.event_types:readto know which event type was booked (intro call, demo, support, etc.) so the agent picks the right template.webhook_subscriptions:writeonly to register the agent's webhook endpoint, then never used again.
Do not request scheduled_events:write unless you are also building rescheduling. Rescheduling is a separate trust step and should ship after the follow-up flow has been calibrated.
Calendly signs webhook payloads with HMAC SHA-256 over the request body, using a signing key the developer sets at subscription time. The agent must verify this signature before doing anything with the payload, including logging. A misconfigured agent that logs unverified payloads to a shared log store is the easiest way to leak invitee emails.
Event taxonomy and triggers
The agent watches three Calendly webhook types: invitee.created, invitee.canceled, and (if you enable it) invitee.no_show. The first two are documented and available on all paid tiers. The third is a server-side mark the host applies after the meeting; it is not automatic.
The taxonomy maps cleanly to four templates:
- Confirmation. Fires on
invitee.created. Adds a one-line context summary the host can paste into the calendar invite description. Identifies the company, the role, and a single talking point from the invitee's response. - Reminder. Fires 24 hours before the start time, only if the meeting still exists. Drafts a brief pre-read with the public context the agent gathered, then attaches a link to the agenda doc.
- Recap. Fires when the host marks the meeting held or when the calendar integration confirms both parties joined. Drafts a thank-you with the action items the host dictates or the meeting transcript surfaces.
- Recovery. Fires 15 minutes after the scheduled end time when no held signal arrives. Drafts a "sorry we missed you" with two reschedule slots that respect the host's calendar.
Free-text classification of meetings (urgent, sales, support, internal, etc.) is unnecessary. The Calendly event type already carries that signal. Use it directly.
Shadow mode for two weeks
Every draft the agent produces during the first two weeks goes to a private review thread, not to the invitee. The host clicks send, edit-then-send, or skip. The agent records the decision and the diff.
Two metrics matter at the end of shadow:
- Send-without-edit rate. If this is above 70% for a given template (confirmation, reminder, recap, recovery), the template is ready to graduate to auto-send.
- Disagree-and-skip rate. If this is above 15% for a template, the template needs a rewrite, not a graduation. Common causes: the template assumes a use case (sales call) that does not match a third of bookings (support).
The confirmation template should graduate first. It is short, factually grounded, and low-stakes. Reminder graduates second. Recap third. Recovery last, because a bad recovery email costs more than a missed one.
No-show recovery workflow
Calendly does not auto-detect no-shows. The agent has to infer them.
Three signals together imply a no-show: the host did not press mark held, the meeting platform's participant log shows only one of the two parties, and 15 minutes have passed since the scheduled end time. When all three are true, the agent files a recovery task and drafts the first recovery message.
The first recovery message offers two specific reschedule slots within the next five business days. It does not ask "when are you free?" Open questions in recovery emails are the single largest reason recovery sequences underperform: they ask the invitee for the work that the agent should be doing.
The second recovery message fires 72 hours later, only if the first received no reply and no reschedule. It is a soft close: "I'll assume this isn't a priority right now. Reply if it ever is." There is no third message. A third recovery message is spam.
Recovery write-back: every recovery attempt files an activity on the relevant CRM record (lead, contact, opportunity). The activity records the original meeting time, both attempted reschedule slots, the outcome, and the source webhook ID. This audit trail is what makes recovery defensible when sales ops asks why a deal stalled.
Guardrails
Five guardrails keep the agent from generating complaints.
- Suppression list. Any invitee who has unsubscribed, opted out, or replied with "stop" goes into a suppression list that the agent checks before every send. The list is per-organization, not per-template.
- Rate limit per invitee. Hard cap of three agent-originated emails to a single invitee in a 14-day window. If the host needs to send more, the host sends them.
- Send window. No agent emails outside the invitee's local 7am–9pm window. Calendly carries the invitee's time zone on the event; the agent must honour it. Saturday and Sunday are suppressed by default for B2B event types and configurable per template.
- Approval gate for non-template text. If the agent generates copy that diverges from the template by more than 30% (measured as token Levenshtein distance), the draft requires human approval even after shadow mode ends.
- Logged enrichment sources. Every enrichment field carries the URL it was scraped from and a timestamp. If the source is no longer reachable, the field gets dropped on the next refresh.
These five guardrails together cut the agent's "regrettable email" rate to near zero in our internal testing. See how we test AI agents with 80 tests per capability for the methodology.
Common mistakes
Polling instead of webhooking. Polling the events endpoint every minute hits Calendly's rate limits, lags real bookings by up to a minute, and creates a deduplication problem the agent does not need. Subscribe to webhooks and verify signatures.
Auto-sending the recap before the host confirms. The recap email contains action items. Action items get committed to. A wrong action item committed to in writing is a small reputation cost. Hold the recap until the host marks the meeting held and approves the action item list.
Enriching from data brokers. Pulling invitee enrichment from third-party contact databases is the single fastest way to acquire a GDPR complaint. Use only what the invitee has effectively published. Public LinkedIn, company about page, public posts they linked from their profile. If your enrichment source has a "premium API" tier that promises business emails, do not use it.
One template for every event type. A sales intro and a customer support call do not share a template. Map the Calendly event type to the template and switch on event-type ID, not on a classifier guess.
Ignoring the cancellation case. invitee.canceled is not just a cleanup signal. It is feedback. Track cancellation rate per event type, per host, per traffic source. A high cancellation rate on one event type is almost always a calendar misconfiguration (wrong default duration, broken video link, mandatory question that scares people off).
Frequently asked questions
What does a Calendly follow-up agent actually do?
It subscribes to Calendly invitee webhooks, reads each booked event, and drives a pre-meeting and post-meeting sequence: it drafts a prep email with the invitee's public context, files the meeting under the right CRM record, sends a reminder at a configurable interval, and on a no-show it drafts a recovery email and creates a follow-up task. It does not auto-send anything in the first two weeks. It posts every draft into a private review thread.
Which Calendly scopes does the agent need?
Read-only on day one: invitees, scheduled events, event types, and webhook subscriptions. Write scopes (cancel, reschedule) are not required for a follow-up agent and should not be granted. If you do enable rescheduling, gate it behind explicit human approval, since cancellation rate is one of the metrics buyers watch.
How does the agent handle no-shows without nagging the invitee?
It waits 15 minutes after the scheduled end time, checks the meeting platform's attendance signal if available (Zoom participant log, Google Meet attendance report), and only fires a no-show recovery draft when both the host and the agent confirm absence. The first message offers two reschedule slots, not a five-paragraph apology request. The second message is a soft close after 72 hours, not another reschedule push.
Should the agent enrich invitees with third-party data?
Only with sources the invitee has effectively published: company website, LinkedIn public profile, posts they have shared. Do not pull from data brokers or scraped contact databases in markets where GDPR or CCPA applies. The agent should log the source of every enrichment field so legal can audit the trail.
How long should the agent run in shadow mode before sending real emails?
Two weeks or 50 meetings, whichever comes first. During this window the agent drafts everything but sends nothing. The host reviews each draft and labels it as send, edit, or skip. When the send-without-edit rate crosses 70%, graduate the lowest-risk template (the meeting confirmation reply) to auto-send. Add the next template only after another 30 confirmed sends with under 5% complaint rate.
Three takeaways before you close this tab
- State machine over drip. Five states, four templates, finite per booking.
- Webhook signature first, action second. Verify HMAC before logging.
- Two recovery messages, then drop. Never three.
Sources
- Calendly Developer Documentation, "Webhooks reference and signature verification", retrieved 2026-05-11, developer.calendly.com/api-docs/webhook-subscriptions
- Calendly Developer Documentation, "OAuth scopes", retrieved 2026-05-11, developer.calendly.com/api-docs/oauth
- European Data Protection Board, "Guidelines 8/2020 on the targeting of social media users", retrieved 2026-05-11, edpb.europa.eu/guidelines-082020
- NIST, "SP 800-53 AC-6 Least Privilege", retrieved 2026-05-11, csrc.nist.gov/sp800-53/AC-6
- Aryan Agarwal, "Gravity scheduling-agent guardrails", internal v1, May 2026, About
Related agent patterns
The same shape, applied to other tools and surfaces:
- AI agent for inbox triage, the email parallel to scheduling follow-ups.
- AI agent for Slack triage, classifying and routing channel messages.
- AI agent for meeting follow-ups, post-call summaries and action items.
- AI agent for cold lead follow-up, outbound sequencing with guardrails.
- AI agent safety and guardrails, the principles every agent in this cluster respects.
- AI agent tool use explained, how an agent gets credentialed against a third-party tool.
- How we test AI agents with 80 tests per capability, the calibration methodology.