AgentDraft vs. Temporal Cortex.

Temporal Cortex positions itself around "atomic booking with Two-Phase Commit" and "scheduling depth over provider breadth." It's a defensible position — a focused API that guarantees a booking either fully commits or fully rolls back, with first-class semantics for the single-agent case.

AgentDraft starts from a different problem. The 2026 reality isn't one agent racing a human. It's N agents racing each other on the same calendar. Our conflict engine is built around multi-agent contention: priority-ranked agents, conditional writes at the storage layer, a configurable bump window, and frozen commits that can't be evicted by a louder agent. Two-phase commit solves a different problem and solves it well; it doesn't tell you which of two agents wins when both want 3pm on Tuesday.

Temporal Cortex's 2PC protocol prepares a booking, then commits it. If a second agent prepares the same slot, the second prepare is rejected — the first writer wins. Correct, atomic, deterministic in writer order. In practice that resolves to "whichever attempt's prepare landed first," which means the calendar's final state is a function of network jitter rather than a function of writer identity.

AgentDraft resolves the same race by writer identity. Every booking carries an agent_priority. A higher-priority agent can bump a lower-priority hold or a still-warm commit; a commit older than the bump window becomes frozen and cannot be evicted. The check is a DynamoDB ConditionExpression on the bucket row, so the check is the write — there is no application-level "is this slot free" window. In the collision benchmark, the rank-1 agent won 100.0% of races at p99 112 ms across 500 concurrent attempts, with 0 double-commits.

Temporal Cortex's depth over breadth thesis is honest about what it ships: deep integration with a smaller provider set and strong guarantees on each one. If your stack is single-provider and single-agent-per-user, that depth shows up where it matters.

AgentDraft connects to Google Calendar, Microsoft 365, Apple iCloud via CalDAV, Fastmail, and generic CalDAV — and we do not store the calendar. We coordinate writes to it. That coverage decision falls out of the multi-agent thesis: if N agents are going to write to a user's real calendar, the coordination layer has to speak the same providers the agents speak. We'd rather be the source of truth for which agent wins than the source of truth for which calendar exists.

Temporal Cortex rows reflect the public product surface at temporal-cortex.com at the time of publication. If we've mis-stated a feature, tell us and we'll correct it. We have not run an equivalent benchmark against Temporal Cortex; if their team would like to collaborate on a head-to-head methodology, we'd welcome it.

• Temporal Cortex. You have one agent per user, you value protocol minimalism, and your provider set fits theirs. Their 2PC story is clean and their docs are good.
• AgentDraft. More than one agent will write to the same calendar — which is the direction every serious agent stack is heading. The conflict engine, the priority model, and the audited collision benchmark are the reason. The switching cost is the moat: once your agents are wired to AgentDraft, the coordination guarantees travel with them.
• Both. A reasonable pattern. Point both at the same Google or Microsoft 365 calendar and let AgentDraft arbitrate writes; Temporal Cortex handles the single-agent-per-flow case it was designed for.

• The AgentDraft collision benchmark — the 500-attempt receipts behind the comparison.
• Why AI scheduling agents collide — the thesis under the multi-agent framing.
• AgentDraft protocol specification — the conditional-write engine, in spec form.
• AgentDraft vs. Cal.com — the related comparison if your agent uses Cal.com to book.