The Build-vs-Embed Decision for AI Scheduling

Every developer building an AI agent eventually hits the scheduling question. A user says “book a meeting with Sarah next Thursday at 2pm,” and you need to make that happen. The real question isn’t can you build it — it’s should you.

Scheduling complexity isn’t linear. It has tiers, and most developers underestimate which tier their use case actually lives in.

Tier 1: Calendar CRUD

What it is: Read events. Write events. Delete events. The calendar equivalent of a database with four operations.

Build cost: 1-2 days with a provider SDK. Google Calendar’s API client handles auth, pagination, and event creation. Outlook’s Microsoft Graph SDK does the same. You’re writing glue code — map user intent to an API call, format the response, done.

When this is enough: Your agent manages a single user’s calendar on a single provider. It creates events when asked and lists what’s coming up. There’s no coordination with other people’s calendars, no complex recurrence logic, and no concurrent agents.

You don’t need Temporal Cortex for this. Use the Google Calendar API or Microsoft Graph directly. The provider SDKs are mature, well-documented, and handle the OAuth flow for you. If your scheduling needs stop at CRUD, adding infrastructure is over-engineering.

Tier 2: Time computation

What it is: Timezone conversion, DST-aware arithmetic, RRULE expansion, natural language datetime resolution, duration calculation across boundaries.

Build cost: 2-6 weeks. This is where most developers get surprised.

The individual problems sound simple: “convert 2pm Eastern to Pacific.” But they compound. What’s “next Tuesday” when today is Sunday — tomorrow or 9 days from now? What happens to a 2:30 AM meeting when clocks spring forward and 2:30 AM doesn’t exist? When a biweekly standup has RRULE:FREQ=WEEKLY;INTERVAL=2;BYDAY=TU,TH, does INTERVAL=2 apply per-day or per-week? (Per-week. Most LLMs get this wrong.)

Each of these is a day or two of research, implementation, and edge-case testing. Then you discover that LLMs score below 50% on temporal reasoning, so you can’t delegate any of it to the model. You need deterministic computation for all of it.

The real cost isn’t writing the code — it’s writing the tests. The Truth Engine has 9,000+ property-based tests because temporal edge cases are combinatorial. DST transitions times 3 providers times leap years times RRULEs with BYSETPOS and EXDATE produces thousands of cases. You’ll spend more time on test coverage than on the implementation itself.

When to build vs. embed: If temporal computation is your core product (you’re building a calendar app), build it. You need to own this logic. If scheduling is a feature of your AI agent (a recruiting tool, a sales assistant, a customer success platform), embed it. The Truth Engine is open source — use the library directly, or get all of it through the MCP server.

Tier 3: Autonomous booking

What it is: Multiple agents booking concurrently. Cross-provider availability merging. Two-Phase Commit for conflict prevention. Protocol negotiation between agent-to-agent and agent-to-human flows. Contact resolution. Scheduling windows and guardrails.

Build cost: 2-6 months. This is infrastructure work, not feature work.

Consider what happens when your AI agent needs to book a meeting between two people who use different calendar providers. The agent must:

1. Resolve the contact — turn “Sarah from marketing” into a calendar identity across providers
2. Merge availability — query Google for one person and Outlook for the other, merge the free/busy data into a unified view
3. Handle concurrency — if two agents check the same slot simultaneously, both see it as free. Without Two-Phase Commit, both book it.
4. Negotiate the protocol — does Sarah have an AI agent? If yes, compose a proposal and let her agent respond. If no, fall back to email or a booking link. The agent needs to discover which path to take at runtime.
5. Enforce guardrails — respect scheduling windows (no meetings before 9am), maximum advance booking (no meetings 6 months out), and minimum notice (no meetings in the next hour). These rules vary per user and per organization.

Each of these is a system, not a function. Contact resolution requires identity mapping across providers. Availability merging requires understanding provider-specific free/busy semantics. The 2PC protocol requires distributed locking. Protocol negotiation requires Agent Cards and capability discovery.

When you’re at Tier 3: You have multiple users, multiple providers, concurrent agents, or any form of cross-party scheduling. This is where Temporal Cortex exists — the infrastructure layer between your agent and the calendars.

The decision tree

Start here:

Does your agent write to calendars, or only read?

• Read-only → Tier 1. Use provider APIs directly.

Does your agent handle natural language time expressions, recurring events, or timezone conversion?

• No → Tier 1. Provider APIs are sufficient.
• Yes → Tier 2. You need deterministic temporal computation.

Does your agent coordinate between multiple people, multiple providers, or multiple concurrent sessions?

• No → Tier 2. Use the Truth Engine as a library for computation.
• Yes → Tier 3. You need scheduling infrastructure.

Is scheduling the core of your product, or a feature?

• Core → Build Tier 2, embed Tier 3. You should own the temporal logic, but the booking infrastructure is commodity.
• Feature → Embed both. Your engineering time is better spent on what makes your product unique.

What embedding looks like

At Tier 2, embedding means using the Truth Engine as a library:

# Rust
cargo add truth-engine

# JavaScript/TypeScript
npm install @temporal-cortex/truth-engine

# Python
pip install truth-engine

At Tier 3, embedding means running the MCP server:

npx @temporal-cortex/cortex-mcp

This gives your agent 18 tools across 5 layers: temporal context, calendar operations, availability computation, booking with 2PC, and open scheduling with protocol negotiation. Your agent calls the tools. The infrastructure handles the calendars.

The tier creep problem

Most developers start at Tier 1. Then a user asks about recurring events, and they’re at Tier 2. Then they need to schedule across two people’s calendars, and they’re at Tier 3.

The problem with building Tier 1 and 2 yourself is that the architecture doesn’t extend to Tier 3. A system designed for single-user CRUD doesn’t have the locking primitives for concurrent booking, the identity resolution for cross-party scheduling, or the protocol negotiation for agent-to-agent coordination.

If you know your use case will reach Tier 3, start there. If you’re not sure, start with the open-source Truth Engine at Tier 2 — it’s free, it’s a library, and it doesn’t lock you into anything. When you need Tier 3 capabilities, the MCP server adds the infrastructure layer on top of the same computation engine.

The infrastructure should be invisible. Your users don’t care about Two-Phase Commit or RRULE expansion or timezone-aware availability merging. They care that the meeting gets booked correctly. Build the experience. Embed the infrastructure.