Case study · Streetcar and light rail operations
An AI orchestration layer over legacy systems: a streetcar and light rail case study
By Robert G. · 5 October 2026 · 8 min read
Real client work, anonymized
The client is a large urban transit operator running streetcar and light rail services. We do not name this client, and we leave out anything that could identify them: location, exact size, dates, people, system and project names, quotes and images. Every figure is labeled with what it is: an initial pilot result, a measured result or an illustration. Diagrams marked illustrative are not the client's actual design.
This agentic AI case study is about one idea: connect an operator's many existing systems through a hub, and add a multi-step agentic system on top of it. It ran as a pilot, and initial testing showed a 20% efficiency gain in resourcing and a 10% time improvement.
The situation
A large streetcar and light rail network runs on many systems that were built at different times for different jobs: planning, operations and resource systems. Each does its job. When something goes wrong in the middle of the day, the problem crosses several of them at once, and a person has to hold the picture together.
The work ran as a pilot.
The hub connected the operator's own planning, operations and resource systems and its customer information, together with outside sources: city and public transport information, other train operators and traffic data.
An AI integration hub, not a replacement
There are two ways to approach a problem like this. One is to replace the systems with a new one that does everything. The other is to leave them in place and build a layer that connects them. Replacing the systems is slow, risky and hard to do while services keep running. A hub avoids that: each system keeps its role and its owners, and the hub adds a shared view and a place where cross-system decisions can be prepared.
It is also easier to defend. Each connection can be tested and limited on its own, and people who own a system can see exactly what the hub reads from it and what it may send back.
- 1Planning
- 2Operations
- 3Resources
- 4Customer information
Illustrative: these are abstract groupings, not the client's actual systems, their number or their architecture. The hub connects to each through its existing interfaces; none of them is replaced.
How a multi-step agent loop works
Here is the general pattern, which is the pattern and not a description of the client's system. A multi-step agentic system does not make one big decision. It works through small steps, each with a limited job:
- Read state from the connected systems: the current position, what is available, what is planned.
- Detect a conflict, such as a delay that threatens a planned connection.
- Propose a re-plan: one or more options that resolve the conflict.
- Check each option against the rules the operator has defined, such as safety and resource limits.
- A person approves or changes the option.
- Publish the approved change to the downstream systems, and record what was done and why.
Splitting the work this way keeps each step testable. It also makes the point of human control explicit, instead of leaving it to a vague promise that someone will be watching.
Our recommendation, in general, is to give each step to its own agent with one narrow job, and to let a person approve any plan change before it goes live and override a proposal. Not every step needs an AI model: re-planning, for example, often suits classical optimization better.
Results
Initial testing while the pilot was running showed two results:
- Efficiency in resourcing
- 20% gain
- Time
- 10% improvement
These are initial figures from testing during the pilot, not a long-run result. We do not publish the baseline or the method, to keep the client anonymous.
What is usually hard
In this kind of integration, two things are usually hardest. The first is data quality and timing across many sources: each system describes the same situation with different detail and at a different moment, so the hub has to decide how current and how trustworthy each input is before anyone can act on it. The second is trust in automated proposals: people responsible for live operations need to see why an option was proposed and how it was checked before they will rely on it.
What applies to any operator
These lessons are our view, drawn from this kind of work in general. They are not findings about the client.
- Start by listing who owns each source. A hub is only as current as the systems it reads. Knowing who can answer for each source is the first piece of integration work.
- Decide where a person approves before you build. It is much easier to relax an approval point after seeing how the system behaves than to add one afterwards.
- Keep rules outside the agents. Operating rules written down in one place can be reviewed by the people responsible for them and changed without rewriting an agent.
- Measure the baseline first. A claimed gain with no baseline cannot be checked, so measure yours before you start. Our ROI guide explains how we think about evidence for value.
- Someone has to direct the work. Multi-system projects stall when nobody owns the decisions.
Frequently asked questions
How can AI connect legacy operational systems without replacing them?
By sitting between them. A hub reads from each system through the interfaces it already has, keeps a shared picture of the current state, and sends approved changes back out through the same interfaces. The existing systems keep their roles. What changes is that something can now see across all of them.
What is an AI orchestration layer?
It is the part of the design that coordinates steps across systems and agents: what runs next, what a step may read and change, what needs a person’s approval and what gets recorded. It is not a replacement for the systems it coordinates.
What is a multi-agent system, and when is it used instead of one model?
A multi-agent system splits a job among several agents, each with a narrow task and defined limits. It tends to suit work with distinct stages, such as detecting a problem, proposing a fix and checking it against rules, because each stage can be tested and limited on its own. A single model can be enough when the job is one step.
How does AI help streetcars and light rail run on time?
In general terms, by spotting a conflict earlier, comparing more re-planning options than a person can in the time available, and checking each option against operating rules before a person decides. It supports the people who run the network. Whether it improves on-time service in a given operation is a question for measurement, not a promise.
What data does an operations hub need?
In general, the plans, the live operating position, the availability of resources and the information shown to customers. The first piece of work is usually finding out who owns each source and how current it is.
Where do people approve or override agent decisions?
We recommend that every change that affects live operations passes a named person, and that the hub records who approved what. Which points an operator chooses to automate later is a decision for the operator, made after the first version has shown how it behaves.
What efficiency gains are realistic?
In the pilot, initial testing showed a 20% efficiency gain in resourcing and a 10% time improvement. These are early figures, and what you can expect elsewhere depends on your baseline, so we do not offer a general figure. For your own operation, measure the current state first, run the change alongside it, and judge any figure, ours included, against its baseline and period.
Plan yours
Agentic AI Canvas helps a team describe its systems, goals and approval points in one place and produce a plan people can review before anything is built. It does not run the systems or the agents. Start a planning conversation, or look at the workflow examples, which are illustrative planning examples, not client work. More work is on the case studies page.