· 6 min read · Billy Lui

Agent-to-Agent Scheduling: What Happens When Both Sides Are Autonomous

Most scheduling flows assume one side has an agent and the other side is a human with a calendar. The agent checks availability, picks a slot, and books it. The interaction is asymmetric by design — one scheduler, one schedulee.

Now remove that assumption. Both sides have AI agents. Both agents have access to their principal’s calendar, preferences, and scheduling rules. Both agents can propose, counter-propose, accept, and reject. What happens?

You get distributed systems problems.

The infinite proposer problem

When a human receives three time options from an AI scheduling assistant, they pick one. The interaction terminates. When an agent receives three time options from another agent, it evaluates all three against its principal’s calendar, finds none of them ideal, and counter-proposes three alternatives. The other agent does the same.

Without a termination condition, two well-intentioned agents can enter an infinite proposal loop. Each round is rational — the agent is optimizing for its principal’s preferences. But the system never converges.

This is the distributed consensus problem wearing a calendar hat. The same dynamics that plague Paxos and Raft apply: multiple proposers, no single leader, and unbounded rounds of negotiation.

The solution is protocol-level constraints, not smarter agents. The A2A (Agent-to-Agent) protocol bounds the interaction with a maximum round count, preference ranking (ordinal, not just accept/reject), and a fallback to asynchronous resolution when synchronous negotiation stalls. The agents don’t need to be clever about termination — the protocol enforces it.

Deadlock: the mutual wait

Agent A checks Agent B’s availability and finds 2pm free. Simultaneously, Agent B checks Agent A’s availability and finds 2pm free. Both agents attempt to lock 2pm on their respective calendars. Agent A waits for confirmation from Agent B. Agent B waits for confirmation from Agent A.

Deadlock.

This is the dining philosophers problem. Two agents, two resources (two calendar slots), circular wait. In a single-agent scenario, Two-Phase Commit prevents double-booking because there’s one proposer and one lock. With two agents proposing simultaneously, you need deadlock prevention.

The canonical solution is lock ordering — both agents must acquire locks in a deterministic order (say, by principal email sorted lexicographically). Agent A’s principal is [email protected], Agent B’s is [email protected]. Both agents lock Alice’s calendar first, then Bob’s. No circular wait, no deadlock.

In practice, this means the agent-to-agent protocol designates a proposer and a responder at the start of the negotiation. The proposer drives the flow: propose slots, receive acceptance or counter-proposal, finalize. The responder reacts. Asymmetry eliminates the deadlock.

Preference negotiation

Human scheduling is implicit preference negotiation. “How about Tuesday?” “Tuesday doesn’t work, how about Wednesday afternoon?” The preferences are expressed through rejection and counter-proposal, not enumerated upfront.

Agent-to-agent scheduling can be explicit. Each agent can declare its principal’s preferences as structured constraints:

  • Hard constraints: “No meetings before 9am. No meetings on Fridays.”
  • Soft constraints: “Prefer mornings. Prefer 30-minute slots over 60-minute.”
  • Scheduling windows: Maximum advance booking (14 days), minimum notice (2 hours).

When both sides declare constraints, the intersection is computable. The proposing agent can filter its candidate slots against the responder’s declared constraints before proposing, reducing rounds. In the best case, the first proposal is already within both sets of constraints, and the negotiation completes in a single round.

This is where infrastructure matters. Computing constraint intersections across timezone boundaries, recurring blocked times, and multi-calendar availability requires the same deterministic temporal computation that single-agent scheduling does — just applied to both sides simultaneously.

Capability discovery with Agent Cards

Before any of this negotiation begins, there’s a fundamental question: does the other side even have an agent?

The A2A protocol addresses this with Agent Cards — machine-readable capability declarations that an agent publishes at a well-known endpoint. An Agent Card declares:

  • What protocols the agent supports (A2A, MCP, REST, browser fallback)
  • What scheduling capabilities it has (propose, accept, counter-propose, delegate)
  • What constraints it enforces (scheduling windows, approval requirements)
  • Whether it can act autonomously or needs human approval

When Agent A wants to schedule with a contact, it first resolves the contact’s identity and checks for an Agent Card. If one exists, it knows the other side has an agent and which capabilities to expect. If not, it falls back to a non-agent protocol.

The protocol negotiation cascade

Not everyone has an AI agent. Not every agent supports the same protocols. The scheduling infrastructure needs to handle the full spectrum:

Scenario 1: Both sides have A2A-capable agents → Full agent-to-agent negotiation. Structured proposals, constraint exchange, automatic convergence.

Scenario 2: One side has an agent, the other has a public booking page → The agent queries the booking page’s availability API and books directly. No negotiation needed — the booking page’s rules are the constraints.

Scenario 3: One side has an agent, the other has nothing → The agent composes a scheduling proposal and delivers it via the available channel (email, messaging). The other party responds manually.

Temporal Cortex handles this cascade through the resolve_contact and compose_proposal tools. The agent calls resolve_contact to determine what protocols the other party supports. Based on the response, it either initiates A2A negotiation, queries a public availability endpoint, or composes a human-readable proposal.

// resolve_contact response when A2A is available
{
  "contact": {
    "name": "Sarah Chen",
    "email": "[email protected]",
    "protocols": ["a2a", "booking_page"],
    "agent_card_url": "https://company.com/.well-known/agent.json"
  }
}

// resolve_contact response when no agent exists
{
  "contact": {
    "name": "Mike Johnson",
    "email": "[email protected]",
    "protocols": ["email"],
    "agent_card_url": null
  }
}

The agent doesn’t need to know which path to take in advance. The infrastructure discovers it at runtime.

Why this is a distributed systems problem, not an AI problem

The instinct is to solve agent-to-agent scheduling with smarter models. Give both agents better prompts, more context, longer reasoning chains. But the failure modes — infinite loops, deadlocks, missed constraints — aren’t intelligence failures. They’re coordination failures.

Distributed systems solved these problems decades ago. Leader election prevents deadlock. Protocol-bounded rounds prevent infinite negotiation. Structured constraint exchange prevents preference misalignment. Fallback hierarchies handle capability asymmetry.

The AI part is still important — understanding “let’s meet sometime next week to discuss the Q2 roadmap” is an intent-extraction problem that LLMs excel at. But the coordination, the locking, the protocol negotiation, and the fallback logic are infrastructure. They should be deterministic, bounded, and protocol-enforced.

This is the same principle behind moving temporal computation out of the LLM. The model extracts intent. The infrastructure executes it. Agent-to-agent scheduling just extends that principle from one agent to two.

Where we are today

The A2A protocol is emerging. Google’s Agent-to-Agent protocol specification defines the primitives — Agent Cards, task lifecycle, capability discovery. Temporal Cortex implements the scheduling-specific layer on top: how agents negotiate time, how constraints are exchanged, and how the protocol cascades when one side doesn’t have an agent.

The near-term reality is mixed. Most scheduling interactions will remain asymmetric — one agent, one human — for the next year or two. But the infrastructure needs to handle both cases from day one, because the protocol negotiation cascade ensures graceful degradation. An agent built for A2A scheduling doesn’t break when the other side is a human. It simply uses a different branch of the same cascade.

Build for the asymmetric case. Design for the symmetric one. The protocols will catch up.