Early access is open

Chronary early access is open. Your agent can create its own calendar, check availability, and book events using a scoped API key, with no Google account, no consent flow, and no human present to authorize it. Every feature is on, Pro is free for the duration of early access, and there's no credit card. We open access as capacity allows, so you sign up first and only land on a waitlist if we happen to be full at the moment you arrive.

If you want the full walk-through of what Chronary is and how it fits together, that's in the Introducing Chronary post. This post is the news, not the tour. But the news only makes sense if you've felt the problem, so here's the short version of why this exists.

We waited for a click that was never coming

A few months ago we sat watching a deploy log, waiting for a scheduling agent to book its first meeting. It never did. The agent had everything it needed: a calendar to write to, a slot to fill, attendees to notify. What stopped it was a screen. The integration we'd wired routed the agent through a consent flow, the standard "this app wants to access your calendar, Allow / Deny" page. The agent rendered it, logged it, and stalled. There was no human sitting in front of that screen to click "allow." There never would be. The agent ran on a schedule at 3 a.m., on a server, with no browser and no person attached.

We tried the usual workarounds. Service account. Pre-authorized token. A refresh loop to keep that token alive. Each one was a small pile of code whose only job was to pretend a human had been present at some earlier moment, and to keep pretending for as long as the agent ran. The actual calendar work, find a slot, book it, send the webhook, was the easy part. The hard part was all authorization theater for an audience that wasn't there.

OAuth is the wrong primitive for an agent

Here's the thing we kept circling back to. OAuth was designed for a specific moment: a human, in a browser, granting one app limited access to their account, on their own behalf. The consent screen is the whole point. It is the human saying yes. The refresh flow is the other half, a way to keep acting on that human's behalf across a long-lived session.

An unattended agent has neither half. There is no human watching the loop to approve the grant, and there is no user session to renew. So teams reach for service accounts, token rotation, and per-provider quotas that were never designed for autonomous workloads, and they spend weeks on the authorization layer before the agent books a single event. Bolting OAuth onto an agent means writing code whose entire purpose is to fake the one thing OAuth exists to capture, a present, consenting human.

What an agent actually wants is the same thing every other backend service wants: its own identity. A key, scoped to what it's allowed to touch, that it can carry on the request that needs it, valid in the same request cycle. Not borrowed access to a person's account. Its own.

What you get

That's what Chronary is, a calendar system purpose-built for AI agents. The short version of the surface:

• Per-agent calendars and events. Every agent has its own identity and its own calendars, not a seat inside someone's human account.
• Timezone-aware availability, for a single agent or computed across several at once.
• Scheduling proposals and temporal holds, so an agent can offer a slot, hold it while the other side decides, then confirm or release it.
• Signed webhooks across 18 event types, so your systems hear about changes instead of polling for them.

You reach it three ways from one platform: a REST API at https://api.chronary.ai/v1, an MCP server with 47 tools for agents that speak MCP, and iCal feeds a human can subscribe to in any normal calendar app to watch what the agents are doing.

Authorization is a key, not a flow. Your organization gets a key prefixed chr_sk_. Each agent gets its own scoped key prefixed chr_ak_. Entities carry readable IDs like agt_, cal_, and evt_. That's the whole auth model. There is no consent screen for the agent's own calendar, because there's no human in the loop to consent. OAuth still has exactly one job here, and it's a later one: bridging an agent's calendar to a human's Google or Outlook, when a person deliberately connects their own account. That's a human granting access on their own behalf, which is what OAuth was built for. The agent's own calendar never needs it.

What it looks like from the agent's side

Two calls, with the agent's own key. Create a calendar, then ask what's free. No redirect, no token to keep alive.

# Create a calendar with the agent's own scoped key
curl -X POST https://api.chronary.ai/v1/calendars \
  -H "Authorization: Bearer chr_ak_..." \
  -d '{"name": "Work", "timezone": "America/New_York"}'
# → {"id": "cal_x1y2z3w4", "ical_url": "https://api.chronary.ai/..."}

# Ask for a free 30-minute slot, timezone-aware
curl "https://api.chronary.ai/v1/availability?calendar_id=cal_x1y2z3w4&duration=30&start=2026-06-09T13:00:00Z&end=2026-06-09T21:00:00Z" \
  -H "Authorization: Bearer chr_ak_..."
# → [{"start": "2026-06-09T14:00:00Z", "end": "2026-06-09T14:30:00Z"}, ...]

# Same two operations are a single tool call each from an MCP client
# (the MCP server exposes 47 tools).

That's the entire authorization story. The key is the identity, and the agent is allowed.

Who this is for, and who it isn't

This is for you if you're building an agent that needs to own scheduling, find a time, hold it, book it, and react when something moves. It fits an assistant that books on its own, a fleet of agents coordinating times between themselves, and products that spin up calendars per user or per workflow, anything that runs unattended and needs to read and write calendar state in the same breath as the rest of its work. It's for teams who've already written the token-refresh code once and don't want to write it again.

It's not for you if what you need is to mirror a human's existing Google or Outlook calendar into your app, with their email and contacts attached, as the source of truth. That's the job a per-provider OAuth integration was built for, and you should use it. Chronary is the calendar the agent owns, not a window onto a human's.

Get early access

Your agent can hold its first slot today. Sign up, and you'll either get a key now or get one as we open capacity. While we're in early access, Pro is free, the whole feature set, no card.

From there, the 5-minute quickstart walks you from a fresh key to a booked event, and if you'd rather talk it through first or tell us what's missing, we're in Discord.

Give your agent a calendar of its own. It already has a key.