The operating model

How Tabi runs.

Forty-two humans. One thousand two hundred agents. Six regional pods. One shared inbox.

Headcount · 42 humans

The org fits in one room.

Engineering 16 · 38%
Field Ops (regional pods + walkers) 14 · 33%
Product & Design 6 · 14%
GTM 4 · 10%
Finance & Legal 2 · 5%

For reference: Booking Holdings operated with roughly 27,000 people in 2024 — a ratio of about 640 humans to every one of ours. We do not replicate their org. We replicate the outcome.

Revenue per employee · annualised
€1.9M

Per human on the team. Agents do the throughput; humans do the judgment.

ARR run-rate Q1 '26€79.8M
Humans42
Agents in production~1,200
The agent stack

Six agents, each replacing a team.

Every agent absorbs a function that used to require a department. Humans step in only where judgment or a face-to-face handshake is required.

01 · Verification

Verification agent

Keeps every property's "walked by us" status fresh — scrapes operator updates, cross-references prefectural filings, flags listings for human re-visit when photos or capacity drift.

02 · Recovery

Replace-in-place agent

Watches cancellations, overbookings, minpaku enforcement actions. Matches affected guests to verified equivalents within twelve minutes, books, absorbs the price gap.

03 · Communication

Language bridge agent

Bidirectional EN ↔ JP with context memory — knows the family, the trip, the ryokan's register of politeness. The ryokan hears fluent Japanese. The traveler writes English.

04 · Memory

Memory agent

Stores preferences per traveler and per companion — partner is vegetarian, six-year-old hates futons. Applied silently on every future booking.

05 · Itinerary

Itinerary stitcher

Flights, shinkansen, ryokan, takkyūbin luggage handoff, restaurant reservations. One thread, one timeline, no tabs.

06 · Dispatch

Dispatch agent

Routes every inbound call to a human in the prefecture the caller is physically standing in. No IVR maze. 24/7 coverage. <60s SLA.

~1,200 agent instances in production Evals run on every deploy Humans-in-the-loop only above €500 delta
How we charge

You pay when the trip is delivered.

A flat fee per completed trip. Nothing on lookup. Nothing on failure. No commission on rooms, no mark-up on rail.

Booking.com takes 15–25% from the property. We take a fixed €210 from the traveler, at the moment the door closes behind them. That's the whole model.

Trigger
Charge
Margin
Trip completed (guest checks in, stays through)
€210
72%
Replace-in-place triggered, trip completed
€210
48%
Lookup, planning, itinerary draft
€0
Trip fails (we couldn't recover it)
€0
Unit economics

The one number we chase.

Trips that close without a human touching them
87%

The other 13% hit a regional pod. Of those, 94% resolve inside one phone call. No ticket systems. No escalations.

Revenue / completed trip
€210
Gross margin
68%
CAC · returning family
€48
Payback · first trip
1.2 trips
What we don't have

Teams we deliberately skipped.

Every Booking.com function we chose not to build has a mechanic in its place. Not a gap — a different shape.

What Booking.com has
We don't have it
What we have instead
Global chain-hotel BD team
No one chasing Marriott or IHG inventory.
Independent ryokans, machiya, and family-run inns — inventory sourced prefecture by prefecture through the Verification agent and regional walks. Supply Booking.com can't structurally sell.
500-person content operations
No content farm writing property descriptions.
Every write-up is auto-drafted from the Verification agent's visit report (photos, notes, capacity checklist) and reviewed by the regional concierge who walked the property. One reviewer per region.
24/7 global call center
No multi-thousand-seat contact centre.
Six regional concierge pods — Tokyo, Osaka, Kyoto, Sapporo, Fukuoka, Naha. Four humans each. Twenty-four total. The dispatch agent routes every call to the pod in the caller's prefecture. Answered in <60s, English or Japanese, 24/7.
Category & pricing managers
No humans re-pricing inventory.
The Verification agent and itinerary stitcher score inventory freshness every 90 seconds. Humans intervene only on edge cases flagged by evals.
Quarterly planning org
No sprint ceremonies, no roadmap decks.
PMs prototype in Claude Code, ship into production behind evals, read LangSmith traces. See PM of the Future.
How a decision flows

A real morning. Thursday, 9 October 2025.

One Kyoto machiya is flagged non-compliant by the prefectural government at 09:47. A family of four is the next guest. They are due on the doorstep in thirteen minutes. Here is the full trace.

09:47 · signal
Verification agent detects minpaku flag

Kyoto Prefecture's enforcement API returns a new non-compliance notice. Property ID 1184. Agent marks it red. No human touched anything.

09:47 · trigger
Replace-in-place agent opens a thread

Scans verified inventory within 4 km of Gion that can accept 4 guests, arriving by 10:30. Returns three options. Scores them on price gap, family-room capacity, walk time from Gion-Shijō station.

09:48 · confirm
Ryokan Tsubaki holds the family-room

Language bridge agent negotiates the hold in Japanese. Agent confirms family-room availability for the next two nights and a late check-in. Booking confirmed at €0 price delta — Tabi absorbs the €68 difference.

09:49 · execute
Auto-executed · no human in loop

Below the €500 human-review threshold. Dispatch agent queues a driver from the Kyoto pod rank. Family receives one calm message on their phone.

09:52 · human touchpoint
Kyoto pod · Yuki places the call

Only now does a human get involved — Yuki calls the family to confirm they are okay, check if the kids need food, confirm driver location. Total pod touch time: 4 minutes.

10:03 · resolved
Family at Ryokan Tsubaki · keys in hand

Total elapsed time from signal to resolution: 16 minutes. One of 18,400 trips. 11 of those minutes were the drive.