Loop

Loop is a scheduling app for friend groups: propose a hangout, and it reads every participant’s real calendar availability and suggests times that work for everyone.

The live link runs on a seeded demo account with no sign-in required: groups, hangouts, acceptance state, and the calendar and task views are all browsable. Built with Shayla Dutta.

Highlights

• Two-stage scheduling pipeline — a cheap model builds durable per-user scheduling profiles; an expensive model does the multi-participant reasoning
• Bidirectional Google sync: week/month calendar views backed by Google Calendar, plus a task list that syncs with Google Tasks
• Deterministic validation layer
• Live acceptance tracking
• Per-user privacy controls

Treating the model as untrusted input

Every proposed time passes through a deterministic validator before it’s rendered:

• Checked against the requester’s actual busy intervals
• Rejected if it resolves to a time in the past
• Required to carry an explicit UTC offset
• Capped at three options, so a degenerate response can’t flood the UI

All model outputs are required to be accepted first by the user, then by all invited participants.

Cost and latency as a hierarchy problem

Multi-turn group scheduling is expensive if every turn re-sends every participant’s profile and calendar. The structure Loop uses is as follows:

• Cheap path, warm. A fast model (Haiku) builds each user’s scheduling profile (inferred awake hours, weekday rhythm, communication style) on first login and refreshes it at most weekly.
• Expensive path, cold only when it has to be. The stronger model (Sonnet) handles the actual multi-participant constraint reasoning.
• Static prompt prefixes are byte-identical across calls. All per-request data lives in a separate dynamic block, so the large invariant prefix is a prompt-cache read on every turn after the first rather than a fresh multi-thousand-token send.
• Bounded lookup budget. A turn may perform at most two calendar checks, which keeps worst-case latency and cost predictable instead of model-dependent.

Availability intersection

Each participant’s Google free/busy response is normalized to UTC, merged into a set of non-overlapping busy intervals, and complemented to get free intervals; the group’s candidate windows are the intersection across participants, filtered by minimum duration.

Privacy at the data layer

Each user controls whether the assistant can see their calendar at all. When sharing is off, the calendar is never fetched. The restriction is enforced where the data is retrieved, not by instructing the model to ignore context it was already given.

Current limitations

• The scheduling assistant isn’t reachable from the demo. Everything the interface does is browsable without an account, but the assistant needs a real Google Calendar to reason over, and Loop’s sensitive Calendar and Tasks scopes haven’t cleared OAuth verification yet, so live scheduling is limited to allowlisted accounts.
• Profiles don’t learn from outcomes. Accept/decline history is stored but not yet fed back into profile refinement.