AI scheduling for Google Calendar by domains and modes

AR Labs schedules its week with a conversational AI scheduler: a Claude Code skill (packaged instructions, with any scripts, that an agent loads only when a task needs them) connected to Google Calendar. Our planning system decides what share of the week each department should get; the scheduler decides when that time happens. It plans the week, answers "what should I work on now?", records what actually happened when the day goes differently, and reviews the week against the plan. This page is for anyone who wants an AI agent to keep a calendar in line with a plan. The scheduler is separate from VOX Scheduler, our paused design for a voice calendar assistant. Its model rests on three terms.

How it works

Term	Meaning	Example
Domain	An area of life, mapped to its own calendar	Work, personal, travel
Mode	A type of work with its own scheduling needs	Deep learning, demo building, content creation
Container	A protected recurring slot that admits certain modes	A weekday morning block for engineering

The core rule is that containers define when and modes define what; they meet at scheduling time. Each mode carries its domain, a description, an energy level, the task labels it serves and a minimum number of hours per week. Each container carries its days and times, the modes it allows and a priority (must-do or should-do). All of this lives in one configuration file, which is the source of truth for weekly hour requirements. A separate file holds this week's intentions, and a calendar log records what actually happened, with the reason for each change.

flowchart TD
    C["Strategy agent: department shares"] --> W["Weekly log: focus and allocation"]
    W --> S["Scheduler: week start"]
    CFG["Modes and containers"] --> S
    S --> CAL["Calendar: planned blocks"]
    CAL --> D["Day: diary updates"]
    D --> LOG["Calendar log: actual"]
    LOG --> R["Week review"]
    R --> CFG

Planning the week

The week-start workflow runs in four phases. It first reflects on last week by comparing planned and actual time per mode and proposes changes to the configuration if a pattern justifies one (a mode that keeps overflowing, for instance). It then archives last week's intentions and opens a new section in the log. Next it loads the department priorities from the strategy agent's weekly log, presents them for adjustment and maps each department to modes. Finally it drafts calendar blocks: high-energy modes in the morning, medium-energy modes in the afternoon, must-do containers before should-do, conflicts checked before anything is proposed, and a reason given with each proposal. If the requirements exceed the available time, the scheduler says so and asks which modes take priority instead of silently dropping any.

Two standing preferences shape every proposal. Work is planned as sustained single-project blocks rather than a series of small tasks across projects, because progress on a project comes from time spent in it continuously. And one block a day is kept for manual work with no AI assistance.

Updating the day in plain language

During the day, changes arrive as speech or text: "didn't manage the morning block", "starting on the proposal now", "only got twenty minutes". The scheduler follows a fixed protocol before it touches the calendar:

1. Fetch the current time; never trust a time from earlier in the conversation.
2. Fetch today's events from every domain calendar, because events live in unexpected calendars.
3. Write out an interpretation: resolved times, the activities mentioned mapped to modes, the state change for each (skipped, diverged, started now, completed, extended, shortened), any constraints, and the calendar operations implied.
4. Estimate confidence. At 90% or above it acts and reports in the past tense; below that it presents the interpretation and asks.
5. Record the change in the calendar log with the reason.

The interpretation block is mandatory because writing it forces the mapping from words to calendar operations to be explicit. Only four operations exist: create, update, delete and move. Moving an event in time is an update, which preserves its details; extending a session that ran on is an update to its end time, not a new event. A block where different but productive work happened is annotated with what was actually done rather than deleted, so the review can still see both the plan and the reality.

Recovering lost time

The scheduler's primary obligation is to protect the week's hour targets. When a block is lost, it identifies which mode lost how much, compares the remaining scheduled time with the weekly minimum, surveys the rest of the week and proposes recovery options ranked from best to worst: free slots that displace nothing, then low-impact displacement, then displacement of other important work, and late-evening cramming only as a last resort. It does not suggest abandoning a mode for the week, and it always reasons about the whole week rather than the current day. Adding a new mode to a full schedule goes through an explicit renegotiation: which modes lose hours, how many, and what that does to their targets.

What exists today

The scheduler runs as an interactive Claude Code skill with Google Calendar access, reading the strategy agent's weekly priorities at the start of each week. It is interactive by design: calendar changes go through the confirmation protocol above rather than running unattended. Our own modes, containers and hour targets are not published.