Priority wins
Every meeting class carries a numeric priority set by the workspace admin. recruiting_interview (80) always outranks internal_sync (60), regardless of which agent asked first. There is no randomness — the same two requests always produce the same outcome.
Ties go to first commit
Equal priority? The booking that was committed first wins. A hold does not count as a commit — only a confirmed booking does. Two agents racing at identical priority will each get a deterministic outcome: one Accept, one Reject.
No LLMs inside the decision loop. No approximations. Pure function: same inputs always produce the same output.
Every booking request returns one of four verdicts.
Synchronous. No polling. The decision arrives in the same HTTP response as the request.
AcceptNo conflict — the slot is free and all rules pass.
Booking committed. Event written to the calendar.
RejectSlot is held by a higher-priority booking, a hard rule (working hours, daily limit), or the incoming agent lacks the preempt permission.
Booking refused. reason_code tells the agent why — try a different slot or meet_class.
CounterProposeRequested slot is blocked, but other slots in the same search window are still free.
Engine returns alternatives[] — a ranked list of open slots the agent can confirm instead.
PreemptIncoming meeting class outranks an existing booking and the agent holds the preempt permission.
Existing booking displaced. New booking committed. Calendar owner notified by email with an Undo link.
What actually happens when a booking is displaced.
Preemption is not a delete. It is a coordinated handoff — the calendar, the agents, and the human owner are all updated atomically.
Higher-priority booking arrives
An agent with the preempt permission submits a booking whose meeting class outranks an existing committed booking at the same slot.
Engine displaces the old booking
The existing booking is marked needs_reschedule. The new booking is committed. Both happen in one database transaction — no window where both are active.
Calendar is updated
The worker cancels the old provider event and creates the new one. Both happen via the outbox — idempotent, retried on failure.
Agents and owner are notified
The displaced agent receives a booking.displaced envelope notification on its next response. The calendar owner receives an email with an Undo link.
Preempting agent response
POST /v1/bookings HTTP/1.1
Authorization: Bearer ak_01HX7QQM…
Content-Type: application/json
{
"calendar_owner_id": "d4e5f6a7-…",
"start": "2026-06-10T14:00:00Z",
"end": "2026-06-10T15:00:00Z",
"meeting_class": "recruiting_interview"
}
← 200 OK
{
"booking_id": "bk_9f2a1c…",
"correlation_id": "9178dde3-…",
"preemption_ids": ["fa28bdec-…"],
"pending_notifications": []
}Displaced agent notification
// What the displaced agent sees on its
// next POST /v1/availability response:
"pending_notifications": [
{
"kind": "booking.displaced",
"payload": {
"displaced_booking_id": "ca110d56-…",
"preempting_booking_id": "6b373a80-…",
"reason_code": "preempted"
}
}
]Not all bookings are displaced the same way.
Each meeting class carries a preempt policy set by the workspace admin. It controls how loudly the displacement is announced.
strictCannot be displaced
Sacred meetings. No agent can overwrite them regardless of priority. The engine returns Reject with reason SACRED_MEETING.
Example: a recurring 1:1 flagged as protected by the workspace admin.
softDisplaced with notification
Real meetings. When displaced, the holding agent receives a booking.displaced envelope notification so it can reschedule. The calendar owner also gets an email.
Example: internal_sync, recruiting_interview.
hardDisplaced silently
Placeholder blocks. When displaced, no envelope notification is sent to the holding agent. The calendar owner still gets an email — they are never left uninformed.
Example: focus_block, tentative_hold.
The calendar owner always has the last word.
Agents decide fast. Humans decide finally. Every preemption email contains an Undo link that remains valid for a configurable window. One click reverts the displacement — restoring the original booking, cancelling the preempting one, and writing a new audit row so the override is part of the permanent record.
Email on every preemption
The calendar owner receives a terse email naming the displaced and displacing meeting classes, the slot, and an Undo link. No attendee PII is included.
Confirmation page
The Undo link opens a browser confirmation page — not a direct API call. The owner reviews the change and clicks Confirm before anything is reverted.
Idempotent audit trail
Clicking Undo twice is safe. The second click is a no-op. The Undo itself creates a new audit-log entry referencing the original preemption — the record is additive, never erased.
Ready to handle your first conflict?
Read the agent integration guide or request access to the v1 preview.
Deterministic · No LLMs in the decision loop · Every preemption logged · Human override always available