The booking widget on yoniryabinski.com runs on AgentDraft.

A founder's calendar is a deceptively contended resource. Three things write to it without talking to each other: the public “book 30 minutes” widget on the site, a recruiter / inbound bot that proposes intro calls, and the founder's own assistant defending focus blocks. Each one, on its own, does the sensible thing — read the free slots, pick one, write it. Two of them doing that in the same few seconds is exactly the multi-agent calendar collision the protocol exists to kill.

The honest framing: a public booking link is just another autonomous writer. The moment a visitor confirms a slot at the same instant the recruiter bot reaches for it, a plain calendar API lets both writes land. AgentDraft sits in front so they can't.

The booker is not a special integration. It is the public, documented flow any builder gets, used by the site's own frontend:

visitor opens "30 min with Yoni"
  │
  ├─▶ GET  /v1/availability        → free slots (the source of truth, not Google's view)
  │
  ├─▶ POST /v1/bookings  mode=hold → hold the chosen slot while the form is filled
  │                                   (30s TTL — auto-expires if they abandon it)
  │
  └─▶ POST /v1/bookings  mode=commit
        ├─ 201 COMMITTED  → the slot is the visitor's; confirmation shown
        └─ 409 outranked  → assistant/recruiter took it; widget offers the next slot

No webhooks to receive, no calendar OAuth in the page, no double-book cleanup job. The widget reads availability, holds, and commits; the conflict engine does the arbitration and the underlying Google Calendar write happens only on the winning path.

These are not metrics we measured on one founder's traffic — they're properties of the protocol the site inherits the moment it routes through it. Two hold by construction; two are the published benchmark figures anyone can reproduce.

• Zero double-books on a slot — by construction. Each booking is written as one conditional row per time bucket inside a single DynamoDB transaction. The availability check is the write, so two confirmations in the same millisecond can't both win.
• Every race resolves to exactly one winner. Across the 100-round public benchmark, 100% of contested rounds produced a single committed booking and zero double-commits.
• 112 ms p99 commit latency (38 ms p50) in that same run — fast enough that the widget feels instant even when a bot is racing it.
• A losing visitor gets a next slot, not an error. A lost race returns a typed 409 with the winner's priority, so the booker re-offers availability instead of silently failing or creating an overlap.

Dogfooding only counts when the founder's case is at least as hard as a customer's. It is: a public, unauthenticated booking surface is the worst kind of writer — it fires on a stranger's click, with no coordination of its own, against a calendar that real bots also touch. If AgentDraft keeps that coherent, the multi-agent case a customer brings — several internal agents on a shared team calendar — is the same machinery with more keys.

• Calendar API for AI agents — the three endpoints the booker calls, documented.
• The multi-agent collision benchmark — where the 0 double-commits / 112 ms p99 numbers come from, and the harness to re-run them.
• AgentDraft vs. Calendly — why a booking link alone can't make this guarantee.