Stop sharing your calendar
with your scheduling agent.
A scheduling agent with write access to your primary calendar is the fastest way to end up with meetings you don't remember agreeing to. Give it its own.
Scheduling agents are popular because the problem is real and the demo is satisfying — 'find a time that works for both of us' resolved without a five-email exchange. The default implementation gives the agent read and write access to your Google or Outlook calendar. This is the problem.
A write-capable agent on your primary calendar makes changes that are extremely hard to audit. Meetings appear; existing meetings move; invitees get updates in your name. When the agent is wrong — and it will be, eventually — the cleanup involves you apologizing to people about meetings you don't remember creating.
The problem with agents in your primary calendar
Everything the agent does looks like something you did. Google Calendar's audit log doesn't distinguish 'created via the OAuth client for your scheduling agent' from 'created via the web UI by Alice.' When a meeting appears you don't recognize, the debugging process is archaeology against mutable state.
The blast radius is also larger than you'd like. The OAuth scope needed to propose and confirm meetings (calendar.events) is the same scope needed to delete your entire calendar. Agents don't need that power; the OAuth protocol has no way to say 'create events, but never delete them' at fine granularity.
The staging-calendar pattern
The pattern that actually works: the agent has its own calendar, scoped to itself, with free-busy access to yours. The agent schedules tentative meetings on its own calendar. You (or a lightweight approval UI) confirm them, at which point they're copied onto your primary calendar with full attribution.
This sounds like more steps. It's two clicks of friction in exchange for a complete audit boundary: the agent's decisions live in one place, your decisions live in another, and the transition between them is explicit. When the agent is wrong, you catch it before anything lands in your calendar.
Where Loomal fits
Loomal identities include a calendar primitive. The agent has its own calendar under its identity, which it can read and write freely. Your primary calendar isn't touched until you explicitly mirror an event across.
Combined with the agent's mailbox (for the back-and-forth scheduling emails) and vault (for the tokens to your actual calendar when you do want to sync), the agent operates entirely out of its own identity. When you retire the agent, its calendar goes with it — no stray events left behind.
FAQ
But I want the meetings to show up on my real calendar automatically.
Then mirror them explicitly — the agent creates on its calendar, a confirmation flow (email or one-click UI) copies to yours with attribution. You lose nothing but a confirmation click; you gain an audit boundary.
What about free/busy lookups on my real calendar?
Read-only calendar access for free/busy is fine — it's write access that causes the problems. Scope the OAuth to readonly where possible.
Does this work with Outlook / Office 365?
Same pattern. The agent's calendar lives under its Loomal identity; you mirror via Graph API when ready to commit an event.
Related reading
More stop sharing
Last updated: 2026-04-15