Lot of puffery in this describing constraint and actual messy problems that you are all most likely just being thrown into the context for an llm agent... None of the case studies demonstrate complex scheduling at all and are just all individual serial threads. buffers, preferences and options are all simple. The hard part of scheduling is when you have multiple pending invites or invitations that have to resolve and track it down, if someone asks for a meeting on a day that you currently already have a pending invite for, and how far away that day is, and how important the relationship is etc...

The concurrent resolution problem you're describing is exactly what we deal with. When a staffing coordinator has 15 interviews to book across shared interviewers, confirming one cascades into others. We track pending holds, rank by urgency, and when a confirmation on one thread invalidates a proposal on another, Vela detects the conflict and re-proposes. Theres

The only other alternative is a booking link but this, slows down business, doesnt work in many many real life situations and more :)

Fair feedback that the case studies don't show this well - they're simplified to demonstrate the flow. The multi-party dependency resolution is happening underneath but we could surface that better.

On the LLM point - agreed that context window alone doesn't cut it. The coordination and state management layer sits outside the model. We learned that the hard way early on.