TransitPulse

Workflow

Inspiration

Transit disruptions usually do not happen because of one huge problem.

Heavy rain, increasing traffic, a large event, a road closure, or a delayed bus can each be manageable on their own. But when several of these happen together, a small problem can quickly spread across a corridor and become a much bigger disruption.

We wanted to build something that could help an operator see that situation before it becomes a major disruption.

That idea became TransitPulse — an early-warning and decision-support system that combines different real-world signals, identifies rising disruption risk, estimates how the problem could spread, and shows what could happen if an intervention is taken.

How It Works

TransitPulse brings together signals such as weather, traffic, events, road closures, and transit data into a single current data snapshot.

A deterministic risk engine then calculates a 0–100 risk score and shows the contributing factors behind it. If the risk is expected to cross a critical threshold, TransitPulse estimates the available lead time. It then uses a graph-based propagation model to estimate how the disruption could spread to connected nodes.

The interesting part comes next.

Instead of simply recommending an action, TransitPulse can simulate the intervention and compare the before and after states.

For example:

Before: Risk 84/100, estimated delay 22 minutes, 6 affected nodes
After: Risk 61/100, estimated delay 11 minutes, 3 affected nodes

This gives the operator something more useful than a generic recommendation: a measurable view of what the proposed action could change.

AI Agent Layer

The deterministic results are then exposed through a controlled MCP tool layer to three specialized agents orchestrated through Freshworks Agent Studio:

Disruption Monitor Agent — surfaces important changes and retrieves the current situation.
Response Planning Agent — investigates the disruption, explores available interventions, and requests before/after simulations.
Communication Agent — turns the computed facts into operator summaries, action cards, and public alert drafts.

The agents do not calculate the risk themselves or invent numerical results. They act on the facts produced by TransitPulse.

This gives us a simple principle:

Compute first → Agents act on facts → Human decides.

Human in the Loop

We deliberately kept the final decision with the operator.

The operator reviews the recommended intervention and its simulated impact before approving an operational action.

Public communication is also a separate decision. A public alert can be prepared by the Communication Agent, but it is not published until the operator approves it.

This prevents the system from turning an AI recommendation into an automatic operational decision.

What We Learned

One of the biggest things we learned was that an AI agent does not need to make every decision itself to be useful.

Our first instinct was to let an LLM handle prediction and recommendations. But that would make the system harder to audit and harder to defend.

Instead, we separated computation from communication.

TransitPulse's deterministic engines provide the measurable intelligence, MCP provides controlled access to those capabilities, and the Freshworks agents use those facts to investigate, plan, and communicate.

This also made the system easier to reason about: if a number appears on the dashboard or in an agent response, we can trace it back to the underlying deterministic computation.

Challenges

The biggest challenge was deciding what should actually be AI-driven.

A real production system would also need historical incident data, calibration, stronger demand modelling, better propagation models, and validation against real-world outcomes. Building all of that was beyond the scope of a hackathon.

We therefore focused on demonstrating the complete loop:

early warning → investigation → intervention → before/after simulation → human decision → communication

Another challenge was keeping the agents grounded. We designed the MCP layer so agents have controlled access to TransitPulse capabilities rather than direct access to the database or internal calculation logic.

What We Built

TransitPulse is therefore not designed as an autonomous system that makes decisions for a transit operator.

It is an early-warning and decision-support heuristic that helps an operator understand:

What is happening?
Why is the risk increasing?
How could it spread?
What intervention could help?
And what might change if we take it?

The next step would be validating and calibrating the system against real historical disruption data.

For the hackathon, our goal was simpler: demonstrate that AI agents can be useful without giving up traceability, measurable outputs, or human control.