The agent that books the meeting before the call ends

Connect Google Calendar or Calendly once, decide which agents may look and which may act, and the appointment lands on a real calendar while the caller is still on the line.

The call that ends in "someone will get back to you"

Most inbound calls to a business that sells appointments are about an appointment. Do you have anything Thursday. Can we move Tuesday. Am I still down for the 14th.

An agent handles that conversation well. Then it reaches the one moment that matters and has nothing to write to. So it takes a message. Someone reads the message, opens the calendar, calls back, misses, leaves a voicemail, and an appointment that was one sentence away from being booked takes two days and three attempts, if it survives at all.

Scheduling is where a voice agent either finishes the job or hands it back. Aethex now connects the two tools businesses actually keep their availability in: Google Calendar and Calendly.

Two calendars, two different contracts

Google Calendar is a store of time. Calendly is a booking product with rules of its own. That difference is not cosmetic; it decides what an agent can offer and what it can promise.

Google Calendar

Connecting takes one browser approval from whoever owns the calendar.

That approval asks Google for exactly two things: permission to create, update and delete events, and permission to read busy time ranges. Nothing else. Which has a consequence worth saying plainly: finding a free slot reveals when the account is busy, never what it is busy with. No titles, no guests, no locations of existing appointments are read to find a gap.

From there the agent can scan forward for open gaps of a given length, in the time zone you name, up to 31 days out. It can create an appointment, move one, or cancel one. Every action is an ordinary calendar action, visible in Google Calendar like anything else, with guests emailed the way they always are.

Calendly

Calendly connects with either a token from your Calendly settings or a browser approval, and both end as the same connection. A token is the whole integration for a team automating its own calendar, and it does not expire. Browser approval is how someone else's Calendly becomes the connected account.

Calendly → Integrations & apps → API & webhooks

Everything on the Calendly side starts from the event type: the kinds of meeting the account takes, each with its duration, its description, and anything a booking will require. From there the agent can read open times, list what is already booked, and book.

Event types, as Calendly holds them

A booking here is a real Calendly booking. The invitee gets Calendly's own confirmation email, the meeting lands on the calendar behind the event type, and the response comes back with Calendly's cancel and reschedule links.

What Calendly deliberately does not get is a cancel or reschedule action. A mistaken cancellation is not something a caller can undo mid-call, so the agent hands over those links instead of holding the power itself.

Which one to connect. If your team owns the calendar and you want the agent to move and cancel appointments as well as make them, connect Google Calendar. If your booking rules already live in Calendly, buffers, round-robin between reps, intake questions, a different duration per meeting type, connect Calendly and let those rules keep governing. They will: Calendly refuses a booking that does not match its own configuration, whoever is asking.

Read or write: the line that holds

Connecting stores a credential. It hands it to nothing.

A connection with no agent is connected and completely inert. That is the default on purpose, so a calendar is never exposed to every agent you run just because somebody connected it. Access is granted per agent, at one of two levels:

Read. The agent may check availability and offer times, nothing more.

Write. The agent may also book, and on Google Calendar move and cancel.

Two things about that design are worth explaining, because both were arguments before they were features.

It is a level, not a checklist of tools. The actions chain into each other, so picking tools one by one mostly produces combinations that cannot work. Looking versus acting is the line that holds.

It is enforced by omission, not by refusal. What an agent can reach is settled when the call is assembled. An action outside the grant is never given to the agent at all. A read-only agent does not decline to book. It has no notion of booking to decline, which is a considerably stronger guarantee than a prompt asking it nicely not to.

Grants take effect when a call starts, so removing one applies to the next call rather than disarming an agent already talking to someone. Disconnecting the integration bites immediately.

What the caller actually hears

Caller: I need to see someone about my back, as soon as you can.

Agent: Let me check the diary. I have tomorrow at 9:40, or Friday at 11:20. Those are your times, in Accra.

Caller: Friday.

Agent: Friday at 11:20, a forty-five minute assessment. I have you as Ama Boateng, on this number. Is ama.boateng@… still the right address for the confirmation?

Caller: That's it.

Agent: Booked. The confirmation is on its way, with links to move or cancel it if you need to.

The other end of that sentence

Three things are happening in those six lines.

The agent speaks in the caller's time zone, not the calendar's. The conversion happens before anything is said out loud.

It confirms the time, the name and the address back to the caller before writing anything. And if the calendar cannot be reached, it says so rather than inventing a confirmation. A call that ends without a booking is recoverable; a caller who believes they have an appointment they do not have is not.

Then there is the email address, which is the genuinely hard part of booking by voice. Spelling an address out loud is slow, and a transcript of one is rarely exact. The number the caller is on, though, the agent already has. So if the people you deal with are already in a CRM, connect that CRM next to the calendar. The agent looks them up by that number, gets a verified address without asking for one, and only has to read it back for confirmation.

One more case the connector handles rather than hides: a slot can be taken between the moment the agent offers it and the moment it books. That comes back as its own outcome, so the agent fetches availability again and offers another time instead of retrying a slot that is already gone.

Five businesses, five setups

A physiotherapy clinic. Google Calendar, write. Reschedules are the call volume here, not new bookings, and Google Calendar is the side with the move and cancel actions. What makes the calendar connectable at all is that finding a gap reads busy ranges only: no patient name, no reason for the visit, no guest list. The practice hands an agent a therapist's working diary without handing over who is on it.

An insurance desk booking callbacks. Calendly, write. Set the event type's location to a phone call and Calendly requires a number to reach the invitee on. That is the one required field the agent never has to ask for, because it already has the number the caller is on. The caller confirms a time; nobody spells anything out.

A bank with twelve branches. Google Calendar, write, one connection per branch. A connection only ever sees the calendar of the account behind its credential, so twelve branches means twelve connections, each granted to that branch's agent. That sounds like overhead and is really the safeguard: no branch agent can reach another branch's diary, and disconnecting one branch touches nothing else.

An equipment yard booking collection slots. Google Calendar, write. Here the calendar is not a person, it is a loading bay. Free-slot lookup becomes a capacity question: set the minimum gap to a bay's turnaround and the agent can only offer slots the yard can actually service. The 31-day scan earns its keep here more than anywhere, because collections get booked a month out.

A B2B team qualifying inbound. Calendly, one connection, two agents. Every inbound call reaches the same Calendly account, but not every caller should be able to book. The front-desk agent is granted read: it can say a demo runs thirty minutes and that Tuesday morning is open, then take a name and a number. When a caller qualifies, it transfers them to the qualification agent, which is granted write and books onto the round-robin event type. One calendar, two agents, two levels of authority, which is exactly why grants are per agent and not per connection.

The limits worth knowing before you launch

Calendly offers times inside the coming week. Calendly's own availability rules cap a single lookup at seven days, so an agent cannot be pointed at a window three weeks out. Google Calendar has no such rule and covers 31 days in one look.

Re-connecting Calendly clears every grant. Nothing can tell re-authorizing the same Calendly account from swapping in a different one, and carrying grants across would silently repoint every granted agent at whichever account the new credential belongs to. So nothing carries over. Re-grant afterward.

Google Calendar is in beta. It works end to end and is safe to use on real calendars, but the surface can still move before general availability. While our Google verification is under review the consent screen shows an "unverified app" warning; approving it is safe, and the warning is about our review status rather than what the integration does. On a Google Workspace domain whose administrator restricts third-party access, they may need to allow it first. Calendly is generally available.

One account per connection. Every action runs as the user the credential belongs to. A connection never sees a second calendar.

Disconnecting does not unbook anything. Removing the connection removes the stored access and every agent immediately loses the ability to use it, but appointments already booked stay exactly where they are.

Get started

Connect a calendar, grant one agent, and make a test call. It is three API calls and one browser approval end to end.

developers.aethexai.com/docs