How AI agents investigate booking discrepancies across systems

Agent Swarm can run a scheduled discrepancy check across the booking systems you already own, have an AI agent gather the evidence behind each flagged booking, and stop at a named operations owner who decides what happens next. It does not change a booking, issue a refund, message a customer or move money on its own. The split it already uses for reports across several data sources, a deterministic fetch followed by agent synthesis, also fits a single reservation (Reports from Multiple Sources).

Fit, and the cases that do not need it

It fits an operations business where revenue arrives as bookings and software supports the work, such as a travel operator or a holiday rental business, with a technology team of 20 to 100 engineers inside a company of up to 500 people. The work it takes over is the stretch between "the systems disagree" and "someone decides": reading the records behind a mismatch so a person can act on it. The decision stays with a person.

Three cases do not need it.

A fixed comparison is enough. When the check compares the same fields on the same keys and a report is the whole output, a scheduled query produces that report and an agent adds nothing. An agent earns its place only where a person has to read a record to say what happened.

Your booking platform already reconciles. Booking systems and channel managers ship reconciliation reports, including overbooking alerts and rate or availability mismatches. When one of those covers your mismatches and routes them to a person you already trust, a second check is a duplicate alert that the team learns to skip.

Volume or ambiguity is low. A few exceptions a week that one person already resolves do not justify a comparison script, and neither do mismatches whose cause never changes. Fix that cause in the source system instead.

Illustrative design. This is a hypothetical adaptation of documented patterns, not a ready-made booking integration, a deployment or a customer result.

One flagged booking, step by step

1. Two approved sources disagree. A reservation in the booking system records four nights for two guests at a stated rate. The partner feed, or the payments ledger, records three nights at a different amount. Both systems are approved for the fields shown, so the mismatch sits between them, not against an internal note.
2. A scheduled check compares them. A schedule runs the workflow on a cron expression (Scheduled Tasks). A script node calls both sources over HTTP or SQL and returns one JSON payload of matched pairs and differing fields (Reports from Multiple Sources). Both records carry the same booking reference, so the script matches them as one booking and reports the nights and the amount as differing fields. The comparison runs in code, where the same input produces the same output.
3. Only mismatched keys go further. A booking whose fields agree leaves the run with nothing to do, and the run ends without a message or a case file (No-op When Nothing Changed).
4. An agent gathers the evidence. For each flagged booking, the agent collects both records with their change history, plus the messages around them, and writes a short case note with links: which field disagrees, and what changed when.
5. The operations owner decides. The note goes to the named owner, who can correct the record or escalate it to whoever owns the partner feed. Leaving it unchanged is a recorded decision with its reason, not a default.
6. The outcome is recorded. Whatever the owner chose, the case note keeps the reason, and the next run reads it so the same pair is not raised twice.

The terms that decide the design

Source of truth. Name the system that wins per field. Dates and property come from the booking system, money from the ledger. Availability comes from the channel manager. A field with two owners has no owner, and every disagreement about it becomes a meeting.

Matching keys. The booking reference is the strongest key, and the guest and the property or route narrow the search. The dates are not a key. Two systems that disagree about the stay length disagree about a field, and that pair is what the check is looking for: four nights against three is one booking with a date mismatch, never two missing records. Match on the reference first, then on guest plus property, and treat differing dates as the finding, not as a reason to split the pair. Keys are often partial: a partner sends no reference, or a guest name is spelled two ways. Match on the strongest remaining combination, mark the pair as uncertain, and send it to the owner as one suspected booking, rather than dropping it, splitting it into missing records, or forcing a match that hides a duplicate.

Stale or unavailable data. A source that did not answer is a failed check, never a clean one. The run alerts, because a comparison that could not read one side cannot report that nothing mismatched (No-op When Nothing Changed). A source that answers with an old copy of the record hides the same gap, so detect staleness from the data rather than from the response. Compare the record's own timestamp, the updated-at or as-of field the system already stores, against the window the run covers, and check that a changed record arrives with a new timestamp. A record older than that window is stale: keep it out of the agreeing set, raise it as its own finding, and alert the way a failed check does. A stale record that happens to match is not evidence that nothing mismatched.

Missing records. A booking present in one system and absent in the other is its own finding. Treat it apart from a field mismatch, because it is usually the case with the largest exposure. Claim it only after the match has failed on every key, because a booking whose dates moved is one record to reconcile, not two that went missing. When no shared reference exists and the dates differ, send the candidate pair to the owner as one uncertain booking, and say which keys matched and which did not.

False positives. Some gaps are expected. A change that has not propagated yet is not a mismatch, and neither is a payment authorization still in flight. Give the owner a way to mark a pair as expected so the next run skips it, and review those marks on a schedule, or the skip list becomes a second set of rules nobody owns.

Escalation. Name the owner and a backup. Say what context each one receives, which is the case note with both records attached, and the point at which an unanswered case escalates again.

No-change path. When nothing mismatched, the run stays silent. Silence is worth trusting only when it is distinguishable from failure, which is why the failed check alerts and the clean one does not.

The approval boundary

Any change to a booking needs the named owner's explicit approval. A refund, a customer message and a payment each need their own explicit approval every time, including when no booking change comes before them. A duplicate charge an agent finds on its own, a guest who asks for money back, a payment that never touched a reservation: the agent prepares the action and stops. Each irreversible action is its own approval, so approving a date correction does not approve the refund behind it. A human-in-the-loop node pauses the workflow, posts the request and resumes on approve or ends on reject (HITL Gates). The documented guidance asks two things of the gate: enough context to decide without digging, and a timeout so a forgotten case does not wedge the run.

Workflows also carry a validate node that can halt or retry a step whose output fails its check. Property and code match nodes route on facts rather than on a model's reading (Workflows).

Before you build: fill this in

Ten lines, written before the first run:

• Systems in scope, and the owner of each one.
• Source of truth per field, in one table.
• Matching keys, and what happens when a key is partial.
• Check schedule, and the window it compares.
• What counts as a mismatch, and what counts as expected.
• The evidence the agent collects for each case.
• The named owner and the backup.
• The actions that always need approval.
• Who is alerted when a check fails to run.
• Where false positives are recorded and when that list is reviewed.

What is built in, what you configure, what you build

Built in.

• Scheduled workflows that run a process on a cron (Scheduled Tasks).
• Deterministic script nodes that fetch from each source and compare the payloads (Reports from Multiple Sources).
• Property and code match nodes for routing, and validate nodes that halt or retry a step whose output fails its check (Workflows).
• Human-in-the-loop nodes with approvals in Slack or on the dashboard (HITL Gates).
• Agent synthesis over the payload the deterministic steps produced (Reports from Multiple Sources).

Integration configuration. Registering your booking system or partner feed as a script connection. The connection is defined from an OpenAPI spec or a GraphQL endpoint, and an MCP server where the provider ships one. Credentials are stored as a binding that script code never holds (Script connections). That is configuration your team does once per system.

Custom development. The comparison script and the matching rules are yours to write and maintain, and so is any write-back step. Write-back changes production data, so it belongs behind the approval gate.

Agent Swarm has no ready-made booking-system integration. Nothing in the platform knows what a reservation is until your team registers the systems and writes the comparison, and none of this design ships as a package to install.

Where to read next

• Reports from Multiple Sources
• No-op When Nothing Changed
• HITL Gates
• Workflows
• Script connections
• Scheduled Tasks

The field guide on small-company AI operations covers the buying side.