thinking about services

[yarimal]

I saw on the roadmap talking about service.
I was thinking also about maybe reservations or appointments that can be also added to this protocol.
Same flow, just needs time/date info from the business.

Can be used to book a reservation to a restaurant or event tickets.

Is this something you're planning? I can help implement it

[hari-lgtm]

Body

Following up on the thread started in #163 about services/reservations — I've been building in this space and wanted to share a more detailed analysis of what this would look like architecturally.

---

The Gap

UCP handles product commerce cleanly because inventory is stateless at discovery time — you can query ten merchants for the same SKU, compare, and only then start a checkout session. The inventory counter moves at order completion, not at discovery.

Temporal resources don't work this way. A hotel room on a specific date has one unit of capacity per time window. The moment two agents query the same slot simultaneously, one must lose — and must know immediately, not at checkout completion. This requires a hold on the slot itself before negotiation begins. That hold is not a checkout session. It's a distributed lease with a TTL.

---

Why Not a Checkout Extension

UCP extensions compose via allOf — they add fields to an existing capability. They can't change the parent's state machine. The booking lifecycle looks like this:

query_availability → hold (TTL starts) → negotiate → confirm → fulfilled
                           ↓ TTL expires
                        available (no session)

The hold phase precedes checkout, not contains it. You can't add this to dev.ucp.shopping.checkout via allOf without bending the model past its intended purpose.

---

What This Looks Like as dev.ucp.bookings

A peer service domain in the same discovery manifest — same /.well-known/ucp profile, same payment handler registry, same transport bindings, same signing infrastructure. A business offering both products and bookings declares both in one profile:

{
  "ucp": {
    "version": "2026-01-11",
    "services": {
      "dev.ucp.shopping": [
        { "transport": "rest", "endpoint": "https://resort.example.com/ucp/shop" }
      ],
      "dev.ucp.bookings": [
        { "transport": "rest", "endpoint": "https://resort.example.com/ucp/book" },
        { "transport": "mcp",  "endpoint": "https://resort.example.com/ucp/book/mcp" }
      ]
    },
    "capabilities": {
      "dev.ucp.shopping.checkout":    [{ "version": "2026-01-11" }],
      "dev.ucp.bookings.booking":     [{ "version": "2026-01-11" }],
      "dev.ucp.bookings.hospitality": [{
        "version": "2026-01-11",
        "extends": "dev.ucp.bookings.booking"
      }]
    },
    "payment_handlers": {
      "com.google.pay": [{ "id": "gp-1", "version": "2026-01-11" }]
    }
  }
}

An AI agent books a room and a gift basket from the same profile, sharing the same payment handler — no second manifest, no second payment integration.

---

Two New Primitives, Everything Else Reused

Primitive	Status
Discovery manifest (/.well-known/ucp)	Reused unchanged
Capability / extension model	Reused unchanged
Service / transport bindings (REST, MCP, A2A)	Reused unchanged
Payment handler registry	Reused unchanged
total.json, message.json, postal_address.json	Reused unchanged
HTTP signing, UCP-Agent header, idempotency	Reused unchanged
ucp_request lifecycle annotations pattern	Reused, new operation names (hold / negotiate / confirm)
Hold lease with TTL	New — no shopping analog
Fencing token (linearizable writes on slot state)	New — no shopping analog

Zero changes to existing shopping schemas.

---

Verticals This Enables

Hotels, vacation rentals, restaurant reservations, medical appointments, fitness classes, salon slots, tours and activities — any service where an AI agent needs to reserve a perishable, time-bound resource on behalf of a user. The same platforms, AI agents, and payment handlers that work with dev.ucp.shopping today work with dev.ucp.bookings without any new discovery or integration overhead.

---

Curious whether the TC sees this as something worth exploring as UCP matures beyond the shopping foundation. Happy to put together a formal Enhancement Proposal using the issue template if the direction makes sense.

[zologic]

Great analysis from @hari-lgtm on the hold/lease problem — the distributed TTL issue is real for high-contention slots like hotel rooms or concert tickets where two agents querying simultaneously creates a genuine race condition.

I want to offer a complementary perspective from the other end of the complexity spectrum, based on building UCPReady — a WooCommerce UCP implementation live on a production store.

---

For the majority of service commerce, a new peer domain may be more than necessary.

The contention problem hari-lgtm describes is real for hospitality and ticketing. But for the far larger category of service commerce — appointments, home services, professional services, fitness classes, repair slots — contention is rare or manageable with optimistic locking at complete_checkout. A hairdresser with 6 slots on Thursday doesn't need distributed leases. They need the agent to see the available slots, select one, and have the checkout fail gracefully if the slot is taken by the time complete_checkout fires.

This is the same model UCP already uses for inventory: in_stock is surfaced at catalog time, no hard reservation is made at create_checkout, and a checkout with an out-of-stock item simply fails at completion. Slot capacity can follow the same pattern.

---

A minimal additive proposal: schedule on fulfillment.groups

For the non-contention case, an optional schedule block alongside the existing options array on fulfillment.groups would be sufficient — zero changes to existing retail schemas, no new tools, slot selection via selected_slot_id mirrors selected_option_id exactly:

"groups": [
  {
    "id": "group_1",
    "line_item_ids": ["li_1"],
    "options": [
      { "id": "standard-service", "title": "Standard Appointment", "totals": [{ "type": "total", "amount": 8900 }] }
    ],
    "schedule": {
      "timezone": "Europe/Amsterdam",
      "slot_duration_minutes": 60,
      "available_slots": [
        {
          "id": "slot_thu_0900",
          "starts_at": "2026-03-26T09:00:00+01:00",
          "ends_at": "2026-03-26T10:00:00+01:00",
          "capacity_remaining": 2
        },
        {
          "id": "slot_thu_1400",
          "starts_at": "2026-03-26T14:00:00+01:00",
          "ends_at": "2026-03-26T15:00:00+01:00",
          "capacity_remaining": 1
        }
      ],
      "selected_slot_id": null
    }
  }
]

The agent sets selected_slot_id in update_checkout. If the slot is taken by complete_checkout time, the business returns a slot_unavailable message and the agent loops back to update_checkout with a new selection. No new state, no new tools, no new domain.

---

Where hari-lgtm's dev.ucp.bookings is the right answer

For high-contention resources — hotel rooms, event tickets, rental cars — the hold/lease model is correct. capacity_remaining with optimistic locking is not safe when 100 agents are racing for the last seat on a flight. That genuinely needs a separate state primitive (the hold) that precedes checkout.

So the practical question for the TC is whether to solve both cases at once with a new peer domain, or solve the simpler case first with a fulfillment extension and leave dev.ucp.bookings for the contention-heavy verticals. The former is more architecturally complete. The latter gets service commerce working on existing implementations immediately.

We encountered this gap building our procurement extension (ucpready-procurement) — lead time and delivery windows are scheduling problems in disguise, currently worked around via fulfillment description strings. A first-class schedule primitive would close that gap without waiting for a full bookings domain.

Happy to contribute a schema draft for either approach if the TC finds this direction worth pursuing.

[ejoslin]

@yarimal @hari-lgtm @zologic — This is a fantastic thread, and I’ve been wrestling with this exact architectural gap for the "Services" vertical.

I completely agree with @hari-lgtm that temporal inventory requires a distributed lease (Hold with a TTL) before negotiation to prevent race conditions. However, I also respect @zologic's point that we must keep the barrier to entry low for standard, low-contention service commerce (like a local hairdresser).

To see if the "Hold" model was actually too heavy for simple use cases, I went ahead and built a working MCP server prototype to test it against live agentic workflows. It turns out, standardizing the Hold primitive is incredibly clean and handles both low and high-contention scenarios perfectly without touching the existing dev.ucp.shopping state machine.

I have just formally submitted this as an Enhancement Proposal: #317.

How the prototype addresses this debate:

The Race Condition: The HoldSlot schema explicitly implements the TTL lease @hari-lgtm mentioned, generating a temporary hold_id before the agent talks to the user.

The Checkout Overlap: It doesn't reinvent payments. If a deposit is required, the AI uses standard UCP checkout primitives, and passes the resulting token into the final BookAppointment request via an optional payment_reference.

The Simple Case: For @zologic's low-contention scenarios (like our mock Restaurant booking in the repo), the SearchAvailability response simply omits the deposit requirement. The AI agent zips through the Hold -> Book flow in milliseconds without friction.

The Code:
You can view the Draft-07 schemas and run the local Python MCP server here: https://github.com/ligament-oss/ucp-scheduling-extension

I would love for the TC and those in this thread to pull down the MCP server, test it against a local agent (Claude Desktop works great), and jump over to #317 to review the formal architecture. If this aligns with where we want to take the "Services" vertical, I'm ready to shepherd this through the Working Draft process.