Scheduling Is an Unsolved Infrastructure Problem
TL;DR
Scheduling is an NP-hard infrastructure problem on par with DNS and routing. Why current tools are primitive and what a real solution looks like.
In the early 1980s, getting a packet from one computer to another was a coordination nightmare. No standardized routing, no DNS, no load balancing. Every connection was manually configured. If you wanted to reach a new server, someone had to update a table somewhere. It worked, technically. It didn't scale.
Today's scheduling tools are in the same era. They "work" in the sense that early networking "worked" — functional, fragile, and fundamentally unable to handle the coordination complexity of modern organizations.
The problem is harder than it looks
Scheduling a meeting between two people with open calendars is trivial. Find a common free slot, book it, done. This is the problem that Calendly solved, and it was a genuine contribution — eliminating the "when are you free?" email chain saved millions of hours.
But that's like solving networking by building a point-to-point serial cable. It works for two computers. Now try connecting 10,000.
Real scheduling complexity emerges from constraints that multiply combinatorially:
- Multi-party coordination — scheduling across 5 people with different calendars, time zones, and preferences creates a search space of millions of possible configurations.
- Preference asymmetry — the CEO prefers mornings, the engineer prefers afternoons, the client is in Tokyo. There may be no slot that's optimal for everyone, only trade-offs.
- Cascading effects — booking a meeting on Tuesday morning makes Tuesday afternoon worse (higher meeting density), which makes Wednesday morning better (day spread), which affects everyone else's optimal slots for the rest of the week.
- Resource constraints — rooms, Zoom licenses, equipment, interpreters. Physical resources add hard constraints to an already complex optimization space.
- Dynamic state — calendars change constantly. A solution that's optimal at noon may be suboptimal by 2 PM when someone adds a new commitment.
In computer science terms, this is a constraint satisfaction problem with dynamic constraints and multiple objectives. The general form is NP-hard. Current tools don't even attempt to solve it — they just show you a flat list of open slots and let you figure it out.
Parallels to solved infrastructure problems
DNS took a simple problem (mapping names to addresses) and built an elegant, distributed, caching infrastructure that scales to billions of queries per day. Before DNS, there was a single hosts.txt file that everyone downloaded. Scheduling today is in the hosts.txt era — everyone maintains their own availability manually, and coordination requires checking each source individually.
Load balancing distributes work across servers based on capacity, health, and request type. Smart scheduling should distribute meetings across time based on cognitive capacity, energy, and meeting type. Today's tools are like round-robin load balancing — they fill slots sequentially without considering the characteristics of the work or the worker.
Routing protocols find optimal paths through complex networks with changing conditions. Scheduling needs to find optimal times through complex calendars with changing constraints. BGP considers bandwidth, latency, hop count, and policy. Slot scoring should consider energy, adjacency, density, and preference. The algorithmic challenge is similar; the investment in solving it is orders of magnitude different.
Why current tools are primitive
The dominant scheduling tools — Calendly, Acuity, SavvyCal — are fundamentally booking pages. They solve the "share your availability" problem. That's important, but it's like solving networking by building better modems. The real infrastructure challenges remain untouched.
See this in action
skdul gives you beautiful booking pages with smart availability — plus full AI agent support.
Try it freeThese tools don't:
- Score slots by quality, only by availability
- Optimize across multiple participants' cognitive patterns
- Learn from booking history and outcomes
- Negotiate between competing preferences programmatically
- Consider the downstream effects of each booking on the rest of the week
- Expose APIs rich enough for AI agents to use them intelligently
They're also architecturally siloed. Your Calendly doesn't talk to my Acuity. There's no shared protocol for exchanging availability information. Imagine if every email provider only worked with its own network — that's where scheduling is today.
What real scheduling infrastructure looks like
The next generation of scheduling needs to work more like modern internet infrastructure:
A scoring layer that evaluates not just "is this slot free?" but "is this slot good?" — considering time-of-day preference, gap efficiency, day spread, buffer comfort, and booking density. This is the scheduling equivalent of a routing algorithm.
An agent interface that lets AI systems negotiate times programmatically. The end of "let me check my calendar" requires agents that can check calendars, score options, propose times, and resolve conflicts — all through structured protocols like MCP, not through screen scraping web UIs.
An optimization engine that treats each booking as part of a system, not as an isolated transaction. Integrating with workflow automation and respecting the downstream impact every meeting has on focus time, energy, and other commitments.
A learning loop that improves over time. Did the user reschedule the 8 AM slot three times? Stop suggesting 8 AM. Did the team consistently cancel the Friday retrospective? Surface that pattern. Infrastructure should get smarter with usage, not just older.
Why this matters now
The shift to remote and hybrid work made the scheduling problem exponentially harder. When everyone was in the same office and the same timezone, the constraints were manageable. Now, a single team might span 8 time zones, 3 calendar systems, and 4 different definitions of "working hours."
Simultaneously, the rise of AI agents creates both the opportunity and the necessity for real scheduling infrastructure. Agents can handle the computational complexity that humans can't — but only if the infrastructure exists for them to interact with. You can't route packets without routers. You can't schedule intelligently without a scheduling layer that speaks the agent's language.
We're building modems when we need to build the internet. The scheduling infrastructure problem is real, it's hard, and it's time someone solved it properly.
Frequently asked questions
Is scheduling really NP-hard?
Why haven't existing scheduling tools solved this already?
What does an agent-first scheduling infrastructure look like?
Arjun Mehta
Founder
Keep reading
Start scheduling for free.
Get started for free