Your AI Agent Will Book the Meeting. Will It Know When You’re Free?

Posted by & filed under , , .

Last week, Meta and Sierra introduced the Personal Agent Protocol, an open standard for how a personal AI assistant talks to a business securely. In the same week Google launched its Gemini agent for work, and Microsoft started previewing Work IQ, which connects Copilot agents to live business data. All three made the rounds on LinkedIn, and they all say the same thing: the assistant is becoming the interface, and the business at the other end is expected to answer it.

I’ve spent much of this year building Calendrz so that agents can use it, so I read the news from a slightly selfish angle. When your agent talks to a business’s agent, what do they actually talk about? Very often it’s this: “When can we do this?”

Every agent conversation ends at a calendar

Look at the use cases people bring up for personal agents: booking a haircut, rescheduling a delivery, setting up a call with a supplier, finding a slot with the dentist. You can argue about the protocol details. The part nobody can skip is that someone’s availability has to be checked, and a slot has to be held.

That’s where it gets hard in real life, because most people don’t have one calendar. They have a work Google Workspace account, a personal Gmail, maybe an Outlook account from a client or a side business. Your agent can speak a perfect open protocol to the dentist’s agent and still book you into a slot where you’re already busy, because the conflicting meeting lives in a calendar it never looked at.

Calendrz exists to fix exactly that. It mirrors your events across all your connected accounts as busy blocks, so each calendar shows your real availability. Before agents, the benefit was that a colleague’s scheduling assistant couldn’t double-book you. With agents, it matters even more: an agent is only as good as the availability data it can see.

Live data beats clever reasoning

Microsoft’s Work IQ pitch is basically “connect agents to live business data instead of relying on what the model already knows”. I agree with that, and it matches what I’ve seen running the Calendrz MCP server in production.

The Calendrz MCP server lets assistants like Claude and ChatGPT work with your calendar setup directly. They can read your events across accounts (get_events), look at your sync and mirroring preferences, trigger a sync, and add or remove connected accounts. The browser version, built on WebMCP, exposes the same tools to agents running in your browser while you’re logged in. When a user asks “what does my Thursday look like?”, the agent doesn’t guess. It asks a system that already merged every calendar the user owns.

Most of the hard problems weren’t in the AI part. They were in the plumbing:

  • Authentication that agents can actually complete. Assistants like Claude.ai and ChatGPT register themselves automatically (OAuth dynamic client registration) and then sign in through a standard OAuth 2.1 authorization code flow. No API keys get pasted into chat windows. That’s the same family of standards the Personal Agent Protocol and every serious agent framework are converging on.
  • Permissions by tier and by tool. Not every tool should be available to every user or every agent. get_capabilities tells an agent upfront what it’s allowed to do, so it doesn’t learn by failing.
  • Confirmation for destructive actions. Removing a connected account or closing your account needs a human “yes”. An agent can propose it, but you decide.
  • Telling agents how to recover. When an agent calls a tool with the wrong parameters, the error now lists the parameters the tool accepts, so the agent can fix the call on its own. (More on that in tomorrow’s post.)

What a protocol like PAP changes

Today, every business that wants to be reachable by agents ends up with its own integration: an MCP server, a WebMCP surface, a custom API. That works, and it’s what I’ve done with Calendrz, but it doesn’t scale to millions of small businesses. A shared protocol for personal agents talking to businesses could make “agent-reachable” the default instead of a project, the way HTTPS stopped being a project.

If that happens, I expect three things for scheduling products:

  1. Availability becomes an API, not a page. Booking pages and shared availability links won’t disappear, but the main consumer will often be software, not a person scrolling through slots. Calendrz already shares availability via links. Making the same data cleanly readable by agents is the natural next step.
  2. Correctness matters more. When a person sees a slot that looks wrong, they ask. An agent just books it. Stale or partial availability data will cost a lot more than it did before.
  3. Consent and audit trails become features. Calendrz already records every Smart Scheduler run with its source: the web app, email, an MCP client or, soon, the mobile apps. With agents acting on your behalf, being able to see who booked what, and through which channel, stops being an admin nicety and becomes something users need.

The boring part is the important part

Most of the excitement in last week’s headlines is about the agents themselves: smarter models, broader tools, single assistants that do everything. I’m excited about that too. But what decides whether your agent books the right slot is the boring part underneath. That’s accurate, merged, up-to-date calendar data, behind proper authentication, with the user in control of anything destructive.

That’s the layer Calendrz is building. If your agent is going to talk to the world on your behalf, it should at least know when you’re free.

If you’re juggling more than one calendar and want your assistants (human or AI) to see your real availability, give Calendrz a try.