Why Rail Can't Deploy the Agents It Needs

The agentic AI market is exploding, projected to reach around $200 billion by 2034. It’s reported that in some industries, up to 80% of organisations have reported some level of agentic use. Rail isn't one of them.

The gap isn't about tech maturity. The core capability already exists. I've watched pilot projects demonstrate what agentic systems can do when given the right environment. The frustration is that the digital backbone of the railway still reflects an earlier model of information exchange.

Until the system moves from publishing information to enabling interaction, agentic technology will continue to see only part of the picture.

The architecture problem nobody talks about

Agentic systems depend on a reasonably complete picture of the world they're acting in. They need to understand the state of a journey, the status of the network, the facilities at a station, the availability of services, and the options available when something changes.

In rail, that information exists in fragments.

Different organisations hold different pieces of it, and those pieces are rarely connected in a way that allows a system to interpret the journey end to end. The European Union Agency for Railways confirms this: rail data typically lives in isolated and incompatible databases, creating fundamental challenges including data gaps, unaligned definitions, and accessibility barriers.

The industry has done important work around open data. Timetables, disruption messages, and some real-time feeds are available publicly. That transparency has enabled a generation of journey planners and third-party tools. There’s also evidence of greater demand for data through initiatives like the Rail Data Marketplace.

The limitation is that most of these feeds are still designed for one-direction communication. They publish information about the railway. They don't allow a system to interact with it.

An agent needs to do more than observe. It needs to ask questions, test options, and sometimes trigger an action. That might involve reserving assistance, updating a customer booking, confirming whether a station facility is operational, or coordinating a recovery option during disruption.

In many cases the digital pathways that would allow those interactions simply don't exist yet.

When pilots hit the wall

The fragmentation reveals itself quickly once someone tries to move from answering questions to actually doing something for the passenger.

Many early experiments have started with internal tools. Customer service teams testing generative systems to surface information faster, or small pilots designed to answer passenger queries. In the first phase these systems often perform well because they're drawing on published data sources.

The difficulty appears the moment the system tries to act rather than simply explain.

A passenger might ask whether assistance can be arranged at the destination station, or whether a ticket can be adjusted after disruption. At that point the agent needs to interact with operational systems, reservation platforms, or customer records that sit inside different organisations.

The information required to answer the question might exist, but the pathway to retrieve it or update it is fragmented across multiple systems.

In several pilot discussions the turning point has come when teams map out the full journey interaction that an agent would need to support. Someone will inevitably ask a practical question about the next step in the process:

• Can the system confirm that a lift is operational at a particular station?

• Can it update a booking across operators?

• Can it arrange passenger assistance without a manual form?

• 
  

Those questions expose the fact that the digital pathways required for the agent to complete the task are either incomplete or designed only for human interaction.

That moment usually reframes the conversation from a discussion about the capability of agents and to a question about the architecture of the railway's information systems.

Humans as connective tissue

Much of the railway's digital infrastructure was designed with the assumption that a trained member of staff would sit in the middle of the process.

A human operator can navigate across multiple systems, interpret incomplete information, and make judgement calls about what to do next. If a passenger calls a contact centre during disruption, the staff member might check real-time running information in one system, ticket validity rules in another, then refer to local station notices to understand what's happening on the ground.

They may then call a colleague, send an internal message, manually update a booking, and then provide guidance to the passenger.

None of that interaction happens through a single digital pathway. It relies on human interpretation and coordination.

An agent can't operate that way. It needs structured interfaces that allow it to retrieve information and perform an action through a defined request. If the status of a lift is recorded on a spreadsheet maintained by a station team, a human can read it and relay the information. An agent can't do that unless the information is exposed through a system it can query.

The same applies to actions. A staff member can decide to endorse a ticket for onward travel, request assistance for a passenger, or confirm an alternative route during disruption because they understand the context of the situation. The process often involves logging into internal systems that were designed for manual use, or sending an instruction through an operational channel.

The limitations are the shape of interfaces, rather than the intelligence behind them. Human staff bridge gaps between systems through experience and judgement. Agents require those gaps to be formalised into clear digital pathways.

The ownership problem

The resistance rarely begins with the tech itself. Most rail organisations understand that better interfaces and structured data exchanges would improve many parts of the system.

The hesitation tends to appear when the conversation shifts to ownership and responsibility.

The railway isn't a single organisation. It's a network of operators, infrastructure managers, ticketing providers, and rolling stock companies who each manage part of the operational environment. When someone proposes creating new digital pathways, the immediate question becomes who is responsible for building and maintaining them. Even in a future world of Great British Railways, that organisation will only be one part (albeit a major part) of a national system. 

Each system sits within a different organisational boundary and often under a different commercial or regulatory framework.

Passenger assistance shows how this misalignment works in practice.

A passenger might book assistance for a journey involving several stations and more than one operator. From the passenger's perspective it's a single request. They expect the system to understand their journey and ensure that staff at each point know what's required.

Behind the scenes the information moves across multiple organisations. The departure station may be managed by one operator, the train service by another, and the destination station by a third party or the infrastructure manager. Each organisation maintains its own operational systems and staff workflows.

One organisation might need to invest in modernising its assistance platform so it can exchange information programmatically with others. The immediate operational benefit, however, might appear somewhere else along the journey. The destination station gains clearer visibility, the passenger experiences a smoother handover.

The real benefit appears at the level of the journey rather than within the boundary of a single organisation.

What works: network level stewardship

Where progress has happened, it usually follows the moment when someone accepts that digital infrastructure needs network-level stewardship rather than being left to individual operators.

The most common intervention is the creation of shared standards and common platforms. In the UK, the rail data ecosystem has evolved around centrally managed feeds such as timetable data and real-time running information, curated at the network level in consistent formats.

A similar pattern appears in European markets around ticketing and distribution. National or regional bodies define the data standards that operators must use, ensuring the passenger experience remains coherent across the network.

What those coordinating bodies are effectively doing is treating information architecture as shared infrastructure.

They define the formats, the governance, and sometimes the platforms that allow different systems to interact. That creates a stable layer that startups, technology providers, and operators can build upon without negotiating separate interfaces with every organisation involved.

The areas where agentic systems still struggle tend to be where that coordination layer hasn't yet developed. Publishing network-level information is one step. Enabling systems to interact across operators, update records, or trigger actions on behalf of passengers requires the same kind of shared framework, but for two-way exchanges rather than one-way publication.

The safety culture paradox

The safety culture in rail exists for very good reasons. The industry operates complex systems where failure can have serious consequences. That creates a mindset where any change to operational systems is approached with caution.

The challenge is that many information systems are connected, directly or indirectly, to operational decision-making. Even something that appears to sit in the customer layer can eventually interact with systems that influence train movements or safety procedures.

New interfaces, data pathways, or integrations must go through extensive testing, security review, and approval processes. Each organisation involved will want to understand the potential impact on their systems and confirm that reliability won't be compromised.

Other safety-critical sectors face the same challenge. Aviation, nuclear power, and energy networks all have strict governance around system changes. The difference is that some of those industries have gradually created clearer layers between operational safety systems and the digital services built on top of them.

Where those boundaries are well defined, innovation in the customer and information layers can move faster without creating risk for the core operational environment.

Rail is moving in that direction, but the architecture is still evolving. Until those boundaries are clearer, every new digital pathway tends to be evaluated through the lens of operational risk, which inevitably slows the pace of change.

What it will take

Passenger expectations are rising. People increasingly experience digital systems in other sectors that anticipate needs and resolve problems automatically. The gap between those experiences and the current rail environment becomes more visible every day.

When major incidents occur, the limitations of fragmented systems become painfully clear. Staff spend enormous effort coordinating information across teams, while passengers struggle to understand what options remain available.

Regulatory direction could shift investment priorities. When governments begin to treat digital capability as infrastructure rather than as optional enhancement, requirements around open data and interoperability standards create conditions that allow new services to develop more quickly.

The catalyst won't be a breakthrough in AI. It will be the moment when the industry collectively recognises that the digital layer of the railway is now as important to passenger experience as the physical infrastructure. In fact, when it comes to journeys across multiple modes of transport, the digital layer really can provide the end-to-end journeys we crave.

Start with interfaces as infrastructure

The most valuable step is to start treating interfaces as infrastructure.

Many rail organisations still think about APIs or system integrations as technical features attached to individual projects. They appear when a new platform is commissioned or when two systems need to exchange information. The result is a patchwork of connections that solve immediate problems but don't create a coherent digital environment.

If an organisation instead decides that its core operational and customer systems must expose structured interfaces as a standard principle, the effect compounds over time. Each new system becomes easier to connect. Data becomes easier to combine. New services can be developed without redesigning the underlying architecture every time.

That shift also changes how projects are specified. Instead of asking only what a system needs to do internally, the question becomes how other systems will interact with it. What information can be queried. What actions can be triggered. What permissions and safeguards are required.

Those considerations form the foundation that agentic systems will eventually rely upon.

Agentic technology will eventually sit on top of that environment, but it will only work well if the pathways already exist. Organisations that begin building those interfaces now are effectively laying the track for capabilities that will appear later.

The interesting signal to watch will be the emergence of the digital interfaces that allow the system to act. Once those pathways become part of the network infrastructure, the pace of innovation will accelerate quickly.