AI agents for passenger rail: assistance bookings, delay claims, and the safety line

A train is cancelled at 07:12 and three things happen at once. Passengers already on platforms need to know what to do. Passengers who pre-booked assistance need to know whether their staff member will still be there. And everyone who ends up more than fifteen minutes late has a compensation claim they may not know how to make.

None of that is the safety-critical work. Signalling, dispatch and the decision to cancel belong to control rooms and the systems built for them. The passenger-facing layer on top is high-volume, repetitive, rule-bound and mostly identical case to case. Which is the shape of work an agent is built for, and why rail operators are among the more interesting places Agentforce is landing.

Rail is not aviation with tracks, though, and the instinct to reuse an airline playbook is where most of these projects go wrong. When a flight cancels, the airline owns re-accommodation onto another flight, a constrained rebooking problem.

Rail’s rules are different. Tickets are often carrier-agnostic within a network, compensation is a statutory scheme paid regardless of fault, and the most sensitive interaction is arranging physical assistance for a disabled passenger rather than a rebooking. That assistance carries a legal duty an agent must never assume it has discharged.

Get the boundaries right and an agent absorbs an enormous amount of load. Get them wrong and you have automated a discrimination risk. This post takes a UK-shaped rail operation, where the rules are most explicit.

Start from what is already real

Two public deployments anchor this in reality rather than a pitch deck.

Amtrak runs Salesforce as operational infrastructure, not CRM alone. Its train-turnaround operations app, TOPS, is built on the platform and coordinates the safety checks for readying long-distance trains, backed by a 40-plus-person internal Salesforce team. Rail treating Salesforce as a system of operation, in other words. The TOPS work is platform and Service Cloud work, not a customer-facing autonomous agent, and should not be cited as one.

The clearer agent example is Northern, one of the UK’s largest operators. In Salesforce’s published customer story, Northern built an Agentforce assistant for accessibility. When a passenger requests assistance, the agent gathers the essential travel details, origin and destination stations and intended travel times, and creates a Service Cloud case routed to the contact centre.

It grounds its answers on real-time station data from Darwin, the GB rail industry’s official live-train-information source, and on knowledge articles retrieved through the Data 360 vector database.

Salesforce frames the project as a response to a roughly 45% rise in assistance demand, and publishes target outcomes, on the order of 5,000 assistance conversations a year and a hoped-for NPS lift, as goals rather than audited results. Treat those numbers as a vendor-stated driver and stated objectives, not proven ROI.

What is worth copying is the design: the agent gathers and raises, the operator confirms and fulfils. Hold that pattern in mind, because it is the whole game for the highest-stakes workflow.

Workflow one: booking passenger assistance

Passenger Assist is the service that arranges a staff member to help a disabled or older passenger board, change trains and alight. In Great Britain it sits on hard regulatory ground. Every licensed operator must publish and follow an Accessible Travel Policy approved by the Office of Rail and Road as a licence condition, and the Equality Act 2010 requires operators to make reasonable adjustments and not to discriminate.

A missed assist is not a service miss. It can be a legal breach that exposes the operator to compensation, including for injury to feelings.

That reality dictates how much of this an agent can do. The bookable facts are well defined and suited to an agent. Since April 2022 the industry accepts assistance requests up to two hours before the journey, any time of day, and passengers can also Turn Up and Go with no booking at all, with operators still obliged to make every effort to help subject to staff availability on the day. So the agent’s lane is the intake:

Identify the journey. Capture origin and destination stations, date, and the specific trains or intended travel times, the same fields the national Passenger Assistance app collects.
Capture the assistance type from a controlled list: wheelchair ramp, help changing trains, guidance for a visually impaired passenger, help with luggage. Not free text the fulfilment team has to re-interpret.
Reuse a stored profile. If the passenger has recurring needs on file, grounded from their unified profile in Data 360, pre-fill them instead of asking again.
Raise the case and route it to the team and stations that must action it, which is precisely Northern’s published pattern.

Now the line the agent must not cross. It can raise the request. It cannot confirm the assistance is guaranteed. A confirmation with a booking reference comes from the operator once a trained staff member is arranged.

An agent that says “your assistance is booked and confirmed” when no human has committed to it has manufactured a duty-of-care failure, and if it implies certainty in a two-hour-notice or Turn-Up-and-Go scenario that depends on real-time staffing, it is misleading a vulnerable passenger.

Encode this as a scope boundary and an escalation protocol. The agent completes intake, says plainly that the request has been submitted and what happens next, and hands anything ambiguous, short-notice edge cases, complex multi-operator journeys, distress, to a person with the case fully populated. The lesson is the same as corporate-travel duty of care: the agent does the assembly, and a human owns the commitment that carries legal weight.

Workflow two: disruption answers grounded in live running data

The most common question during disruption, is my train running and from which platform, is also the easiest for an agent to get catastrophically wrong if it answers from memory. A model that guesses a platform number sends someone with a mobility need to the wrong end of a station. This workflow lives or dies on grounding.

GB rail has an unusually mature open-data estate to ground on, and it is all reachable by API.

Darwin is the official train-running information engine: real-time arrival and departure predictions, platform numbers, delay estimates, cancellations and schedule changes, available through the Darwin Push Port XML stream and a SOAP web service. The National Rail live departure boards run on it.

The Rail Data Marketplace is now the industry’s access platform, exposing Darwin alongside Knowledgebase, which covers station facilities, disruption and engineering works, and the journey planner, with feeds delivered as files, APIs, or Kafka streams.

Internationally, GTFS-Realtime is the common denominator, with three entity types worth knowing: Trip Updates for delays, cancellations and reroutes, Service Alerts for station, line or network disruption, and Vehicle Positions.

The architecture that makes this safe is retrieval, not recall. Real-time running data streams into Data 360 or is fetched on demand, and the agent is configured to answer disruption questions only from that retrieved data, never from the model’s training.

For station facilities and policy questions, ground on Knowledge through a Data 360 retriever, which is how Northern grounds on knowledge articles.

For the live “where is my train” question, wire a deterministic call to the running-data feed. A Flow HTTP callout to the Darwin or RDM API is the no-Apex path. Return what the feed says, with the caveat that Darwin’s predictions are heuristic and platforms can change.

One integration caution the demos skip: predictions are volatile and feeds go down. Design for the degraded case. When the running-data call fails or times out, the agent should say it cannot confirm live status and point to the staffed channel, not fall back to stale or invented information.

Workflow three: starting the Delay Repay claim

Compensation is where an agent recovers cost while improving the passenger experience, because the current process is a friction machine and most eligible passengers never claim. The scheme is well enough defined to automate the assembly of a claim end to end, provided the agent keys its logic to the specific operator and ticket, because the thresholds vary.

Under Delay Repay, the industry compensation commitment, the two common variants pay differently.

Delay Repay 15 operators pay 25% of the single fare for a 15 to 29 minute delay, 50% for 30 to 59 minutes, 100% of the single fare for 60 to 119 minutes, and 100% of the return fare for 120 minutes or more, where a return was held.

Delay Repay 30 operators, LNER and ScotRail among them, have no 15 to 29 minute band at all: 50% for 30 to 59 minutes and 100% at 60 minutes and above. A 25-minute delay pays nothing under DR30.

Two properties make this cleanly automatable. Delay Repay is paid regardless of the cause of the delay, so the passenger does not have to prove fault, only a valid ticket and a qualifying delay. And there is a defined 28-day claim window from the journey. So the agent can:

Establish eligibility from the journey and the actual delay pulled from the running-data feed, applying the correct band for that operator’s scheme. Get DR15 and DR30 confused and you quote a refund the passenger is not owed, or miss one they are.
Assemble the evidence the claim needs: ticket proof, whether a photo, the mobile ticket barcode or the booking reference, plus journey date, origin and destination, and scheduled versus actual times.
Pre-fill and submit the claim, or hand the passenger a one-tap confirmation, well inside the 28-day window.
Escalate the disputes. Split-ticket journeys, multi-operator itineraries and contested delay attribution are where the rule gets fuzzy. Route those to a human rather than letting the agent adjudicate.

A note for anyone porting this outside GB: do not assume a statutory schedule exists. In the US, Amtrak’s service recovery is largely discretionary, with travel vouchers offered case by case and no published fixed table of delay lengths and cash refunds. An agent there assembles a request and sets expectations plainly rather than asserting an entitlement. Encode the local scheme. Never hard-code Britain’s bands into another market.

The data foundation that makes all three work

None of these workflows is a prompt-engineering problem. Each is a data problem wearing a conversational coat. The agent needs three streams unified and retrievable: CRM and case data, meaning who the passenger is, their stored assistance profile and their history; rail retail data, meaning the ticket, the journey and the fare basis, which in the GB market is fragmented across train operators and licensed third-party retailers under Rail Delivery Group settlement and is mid-reform as retailing consolidates under Great British Railways; and real-time running data from Darwin or RDM.

Data 360 is the layer that brings the first two together and makes the third groundable, the same unify-then-ground pattern behind a booking agent that does not invent a fare.

Two design choices repay the effort. Make disruption an event, not a question, wherever you can. An event-triggered agent that reacts to a cancellation feed can notify affected passengers with assistance bookings before they call, which is the single biggest lever on contact-centre load during disruption. And decide deliberately where voice belongs. Accessibility is exactly the context where a phone or in-app voice channel is the accessible channel rather than a nice-to-have, and where getting the grounding right matters most.

Understanding the basics

Can an AI agent book passenger assistance on a train?

It can take the booking. An agent can collect the journey, the assistance type and the passenger’s stored needs, and raise and route the case to the stations that must action it. It should not tell the passenger the assistance is confirmed, because that confirmation depends on a trained staff member being arranged, and in Great Britain a missed assist can breach the operator’s Accessible Travel Policy and the Equality Act 2010.

What data does a rail agent need to answer “is my train running”?

Live running data, never the model’s memory. In Great Britain that means Darwin, reached directly or through the Rail Data Marketplace, which also carries Knowledgebase for station facilities and disruption. Elsewhere it usually means a GTFS-Realtime feed. The agent should answer only from the feed and say so plainly when the feed is unavailable.

How does Delay Repay work, and can an agent file it?

Delay Repay pays a percentage of the fare based on how late the passenger arrived, regardless of the cause, within a 28-day window. Delay Repay 15 operators start paying at 15 minutes; Delay Repay 30 operators start at 30. An agent can establish eligibility from the running-data feed, assemble the ticket evidence, and pre-fill the claim, and should escalate split-ticket, multi-operator and disputed cases to a person.

Design so the agent never promises alone

The pattern that survives production in rail is the one that survives everywhere. The agent makes the high-volume, high-friction work disappear and hands the consequential decisions, the ones with a safety or legal edge, to a person, with the context already assembled.

In rail, that edge is a passenger standing on a platform who needs help that was promised. Copy the gather-then-confirm pattern, ground every disruption answer on the live feed, automate Delay Repay to the operator’s exact scheme, and unify the data before you write a single topic.

If you run a rail operation and want the assistance, disruption and compensation workflows scoped against your own feeds and rules, talk to us, or start with the Agentforce readiness assessment.