Build an Email Scheduling Agent

I wanted an agent I could CC when someone asked for a meeting.

That was the whole idea. Someone emails me. I copy my assistant. It checks my calendars, offers a few times, books the meeting, adds the meeting link, and replies to everyone on the thread.

The first time I used it on a real email, it replied only to me. The other person never got the message.

I thought the hard part would be getting the AI to understand the email. It wasn't. The AI could write "Tam is available Tuesday at 2pm" on the first try.

The hard part was everything around that sentence. Was Tuesday at 2pm open? Did the right people get the reply? Did the system make one booking or two? Did the invite have the right title, people, notes, and meeting link?

This resource walks through the system I ended up with. The repository has the code, prompts, tests, and setup instructions. You can give it to a coding agent and have it build your version.

One simple email hides 9 decisions

Take this question:

Are you free next Monday afternoon?

I read that question and know what to do. My assistant didn't. Before it could answer, it had to figure out 9 things:

1. What date next Monday is.
2. What counts as afternoon.
3. Which time zone to use.
4. How long the meeting should be.
5. Which calendars count as busy.
6. How many times to offer and whether to spread them across a few days.
7. Who should get the reply.
8. Whether the person wants options or already picked a time.
9. What the calendar invite should say.

I make those decisions without thinking about them. I know my calendar. I know I don't want meetings before 10am. I can tell that when someone writes "2 works," they mean go ahead and book it.

The agent didn't know any of that until I wrote it down.

What broke when I used it

The first version could read a request, find open times, and book a meeting. I thought the hard part was over.

Then I used it on real email threads.

I didn't make up these problems for a test. They happened in real email threads with real people.

When an AI tool is only helping me, a mistake is annoying. When it emails a client, the client sees the mistake too.

What I let the AI do

The AI reads the email and works out what the person wants. This is the part it's good at because people write things like:

• "Do you have 60 minutes early next week?"
• "I can do Tuesday morning or Thursday between 1 and 3."
• "How about 2?"
• "That works for me."
• "Can we try again?"

People refer back to earlier messages. They change their minds halfway through a thread. They leave out details they assume you already know.

I didn't want to write a pile of rules for every possible way someone might say "Tuesday works." That would break as soon as someone wrote something I hadn't planned for.

The AI reads the language and drafts the reply. That's it.

Before the email goes out, code compares the draft with the dates, times, names, and booking details the system already checked. If the AI makes something up or changes a fact, the system throws that draft away and sends a plain backup reply.

What the code handles

Everything else is handled by code. Boring code that does the same thing every time:

• today's date and the exact dates behind phrases such as "next week"
• the hours and days I allow meetings
• how long each type of meeting should be
• which time zone to use, or whether the agent needs to ask
• who is on the latest To and CC lines
• the slots Cal.com says are open
• the times already offered in the thread
• the exact time the other person selected
• booking creation through Cal.com
• a record of what already happened so a retry doesn't create 2 meetings
• the calendar event's title, time, attendees, notes, and meeting link
• delivery of the final reply to the expected recipients

AI handles the language. Code handles the facts, the actions, and the memory.

How the pieces fit together

The repository uses 6 tools. Each one has a specific job:

1. AgentMail receives the email. It gives the assistant its own email address and tells the code when a message arrives.
2. Cloudflare Workers runs the code. This replaced my laptop, so the assistant keeps working when my computer is closed.
3. Cloudflare Queues keeps track of each job. If Cal.com, Google, or the AI fails, the job can try again without losing the email.
4. A Durable Object remembers the thread. This is the thread's memory. It keeps the times already offered, the booking ID, who should get the reply, and which steps are finished.
5. Cal.com checks my calendars and books the meeting. I use it because it already knows which calendars make me busy. It also gives the other person a way to reschedule or cancel.
6. Google Calendar checks the finished event. After Cal.com books the meeting, the system reads the event and checks the title, time, people, notes, and meeting link.

The AI can't send the email or make the booking on its own. It returns a list of what it thinks the person asked for. The code checks that list and decides what can happen next.

If one of the tools gives an unclear result, the workflow stops and asks for a human to check it. It won't keep trying when a booking may already exist.

Write down your rules first

The repository gives you the workflow. You still have to tell it how you schedule meetings.

Write down:

• your time zone and the label you use in replies
• the earliest and latest meeting times you accept
• any exception for an explicitly requested early time
• the weekdays you allow
• the meeting lengths you support
• which calendars block availability
• which calendar receives the booking
• how many rounds of options the agent can send
• how many options to offer and how to spread them across days
• what the invite title should contain
• where failures should be sent for review

This was the part that caught me off guard. I knew I didn't want meetings before 10am. I knew I wanted a few options spread across different days. I knew the invite should say what the meeting is about.

None of that existed as a rule until the agent got it wrong.

Give the repo to a coding agent

You can point a coding agent at the repository and start with this prompt:

Read AGENTS.md and README.md in this repository. Adapt the scheduling agent to my inbox, booking tool, calendars, time zone, and Cloudflare account.

Start by listing the accounts and settings I already have. Do not print or save passwords or API keys. Before you create anything, change a live setting, or put the agent online, tell me exactly what you plan to do and ask for approval.

Run every check in the repository before you call it ready. Send the first test from an email address I control. Do not invite anyone else until I approve it.

Then work through the setup:

1. Fork or copy the repository.
2. Replace the sample settings with your name, inbox, calendar, time zone, meeting lengths, and Cal.com event types.
3. Connect the calendars that should block availability.
4. Add your API keys through Wrangler's secret commands so they don't end up in the repository.
5. Run npm run check:config and npm run check.
6. Review the accounts and settings the agent will change before you deploy it.
7. Connect AgentMail to the Worker after the Worker has a stable URL. AgentMail calls this connection a webhook.
8. Send a test email from an address you control and choose a meeting more than 24 hours away.
9. Check the Cal.com booking, Google Calendar event, meeting link, attendees, and reply-all behavior.

The first version I was willing to use on a real client email took a day and 51 tests. The current starter repository passed 54 tests when I checked it on September 1, 2026.

The repository still needs your account settings, credentials, and approval before anything goes live.

Start with your scheduling rules. The code can only follow the decisions you have written down.