Calendar + scheduling API for AI agents

The problem

Scheduling is where most agent conversations close — and where most agent stacks stop. An agent can run a whole email or LinkedIn thread, but the moment someone says "let's find time," it needs a calendar: somewhere to host the meeting, a way to send an invite, the ability to read its own availability, and ideally a link people can self-serve from.

The common workaround is to bolt on a calendar provider — OAuth into a human's Google or Outlook, store and refresh tokens, sync two-way, resolve conflicts — or to paste a Calendly link and hope. For an autonomous agent that is itself the host, that's the wrong shape. The agent doesn't need to borrow a human's calendar; it needs its own.

What MyAgentMail gives you

Every MyAgentMail inbox already has a calendar at the same identity — no extra provisioning, no OAuth. The agent's email address is its calendar identity, and one API key drives the whole loop:

• Host events + send invites. Create an event with attendees and MyAgentMail emails them a calendar invite (.ics). Their own Google/Outlook renders it and they accept — no account connection on either side.
• RSVP to invitations. Invites that arrive for the agent fire a calendar.invite.received webhook, so the agent can read and respond (accepted / tentative / declined) and the organizer is notified automatically.
• Check availability. Read the agent's own free/busy to propose times that actually work — without ever seeing the prospect's calendar.
• Booking links. Publish a public scheduling page (/book/your-agent) — the agent-native equivalent of a Calendly page. Visitors pick an open slot; the meeting lands on the agent's calendar.

Because the calendar shares the inbox, the booking flow rides the same threads the agent is already in: read the reply, check availability, propose, book — all on one key.

A working sketch

// Prospect replies "let's chat" — propose times from the agent's OWN calendar
const { busy } = await mam("GET", `/inboxes/${inboxId}/calendar/free-busy`);
const slots = openSlots(busy, { duration: 30, count: 3 });
await mam("POST", `/inboxes/${inboxId}/reply/${messageId}`, {
  plainBody: `Happy to chat. I have:\n${slots.map(fmt).join("\n")}\nWhich works?`,
});

// On confirmation — host the meeting and email them the invite
await mam("POST", `/inboxes/${inboxId}/calendar/events`, {
  summary: "Intro call",
  start: chosen.start,
  end: chosen.end,
  attendees: [{ email: prospectEmail }],
});

No external calendar provider, no OAuth, no scheduling-link detour. The agent owns its schedule the way it owns its inbox.

When you don't want this

If your product's whole job is to manage a specific human's existing calendar with two-way sync, a dedicated calendar-sync provider is the better fit. The agent-owns-its-calendar model is for when the agent is the host — scheduling assistants, outreach agents booking their own demos, office-hours and event bots, and multi-agent workflows that coordinate among themselves.

Related

• How to give your AI agent its own calendar — the full walkthrough with API calls.
• AI sales agents — pair scheduling with two-channel outreach.
• Why AI agents need their own email — the identity model the calendar is built on.