Implementing MBTA Transit Conversational Intelligence with Emerging AI Protocols

Sharanya Badrinarayanan¹, *Hema Seshadri, Ph.D.¹˒², Manikandan Meenakshi Sundaram¹, John Zinky, Ph.D.², Neha Save¹, Javier Solis Vindas²

¹ Northeastern University · ² Akamai Technologies · *Principal Investigator

Here is what I want you to imagine as you read this. You’re taking the red line to Harvard, and you’re late for work. It’s been snowing every weekend, and you know that  Boston’s MBTA is dealing with delays and alerts, yet again. Just then, your phone buzzes with a red line alert: “Service delays on the Red Line.”  Your mind is already on solutions, you open Google Maps, and check for a new route.

Your meeting at Harvard starts in an hour, and this delay has added to your overall commute. You are already thinking about taking an Uber to work and asking yourself: “How bad are the delays?” “Should I reroute?” “Where’s the nearest station to where I’m heading?”

As noted in the previous paragraph, many of these questions cannot be answered by a single source; for instance, maps provide only a fraction of the necessary information. Data must be aggregated from multiple sources and synthesised into a response tailored to the user’s specific query.

This complexity raises several critical implementation questions:

• How should we implement raw data integration (e.g., via MCP)?
• How can we design reusable specialist agents for delegating specific sub-problems within an A2A framework?

These, in turn, lead to broader deployment considerations:

• Should this integration be offered as a general public service—similar to web-based maps that often compromise privacy for advertising—or should it reside locally on a user’s device to keep their intentions private?
• Furthermore, how do we secure the agent communication within and beyond organisational boundaries? 

By addressing these questions, we aim to highlight three primary concerns that the MBTA Transit Conversational Intelligence reference architecture is designed to illustrate:

• Custom Information Integration: Synthesising data beyond a single provider.
• Agent-based decomposition: Breaking down complex tasks into manageable sub-problems using specialised agents.
• Secure Deployment: Operating within a safe environment supported by robust infrastructure.

But what if a single AI agent was doing the same thing? How do we architect it? How do you optimise so many intricacies into one agent? So that’s where our focus began.

Your Prompt: “There are delays on the Red Line. I need to go from Park Street to Harvard. Tell me how to get there.” 

Our Solution: Develop a conversational intelligence agent capable of navigating complex prompts involving directions, alerts, and user intent. This agent is powered by live data from the MBTA API, providing real-time access to vehicle positions, service disruptions, arrival predictions, and network-wide route information.

The MBTA API serves 141 stations across the city, handling everything from simple alert lookups to complex multi-step trip planning.

Figure 1: MBTA Transit Conversational Intelligence UI

The frontend is a web application built with HTML/CSS/JavaScript, and FastAPI serves as the backend. Users interact with the reference application through a chat interface that connects to the backend via WebSocket for instant messaging (Fig. 1). 

The interface makes the reference application feel alive with visual elements that respond to real weather conditions, based on actual Boston weather data (Fig. 1). Furthermore, the ‘System Internals’ panel on the right serves as an observability dashboard. Rather than masking the application’s inner workings, it displays processes in real time, making the system entirely inspectable and transparent. 

When you send a message, you can see which routing path was chosen, how confident it was in understanding your intent, how long the response took, and which specialist agents were called to handle your request.  In a future edition of this series, we will dive into the implementation details of our observability frameworks (such as Jaeger), performance metrics, and logging. These insights are designed to benefit both service users and researchers studying the coordination of multi-agent applications.

Figure 2: Multi-Protocol Orchestration Architecture 

The following section introduces the agents within the reference application and outlines their respective responsibilities.

Agents Implemented

The MBTA Transit Conversational Intelligence reference application is powered by four specialised agents: Alerts, StopFinder, RoutePlanner, and the Exchange agent, which coordinates the agents listed below through three communication protocols: A2A, MCP, and SLIM (Fig. 2).

• Alerts agent – pulls live disruption data directly from the MBTA API, parses delay and cancellation entries, and returns a structured summary of what’s affected and by how much.
• StopFinder agent – specialises in location, finds the MBTA stops nearest to a given place using a locally curated stop dataset, and handles the difference between “MIT the campus” and “Kendall/MIT the station”.
• Route Planner agent – focused purely on routing, queries the MBTA API for real-time conditions.
• Exchange agent – the reference application’s coordinator, receives your prompt through the Chat UI, uses an LLM to understand intent, and decides the execution path: simple lookups route through MCP directly to the server tools. At the same time, complex requests go through the StateGraph Orchestrator, which coordinates multi-agent workflows via SLIM on A2A. Either way, the Exchange agent unifies the response and returns it to you.

Each agent is specialised and can therefore handle prompts about a particular domain topic: alerts, routes, stops, and coordination. What makes the MBTA Transit Conversational Intelligence smart, however, is not any single agent; it is how multiple agents communicate with each other. The following section breaks down the three protocols that wire these agents together and explains how the application determines, in real-time, which one to use.

Emerging AI Protocols Implemented

The reference application combines three protocols with LLM-powered intelligent routing: A2A, MCP, and SLIM. In Part I of this blog series, we introduced the technical foundations that underpin this reference architecture. We deep dive into each of these to explain how they work within the application in the section below.

Agent-to-Agent (A2A) Protocol Approach

A2A is an open protocol for communication and interoperability between agents, especially in multi-agent systems. A2A empowers engineers to build agents that interact with one another, as humans might delegate tasks. This ensures that any agent created using the protocol can integrate and collaborate across different systems, frameworks, and organisations.

Our approach utilises the A2A protocol (by Google) over SLIM transport (by Cisco), layering its own methods and message structure on top of the standard JSON-RPC 2.0 format, so that the exchange agent can delegate to a specialist agent and receive a structured response.

Model Context Protocol (MCP) Approach

MCP is a standardised way for AI applications to interact with external systems. MCP defines three core primitives: 

• Resources: Context and data, for the user or the AI model to use
• Prompts: Templated messages and workflows for users
• Tools: Functions for the AI model to execute

Alongside A2A, our reference application also implements the MCP from Anthropic, which provides a standardised way for AI models to connect securely to external data sources and tools. Where A2A defines how agents talk to each other, MCP defines how agents access tools, resources, and prompts. Think of MCP as the universal adapter that makes our transit expertise accessible to any AI application that needs it.

In our architecture, MCP servers expose MBTA API functionality as callable tools that the Exchange agent can invoke directly (Fig. 1). When a user prompt is received, the Exchange agent utilises MCP to access live transit data, stop locations, and routing algorithms as if they were native functions. This means that any MCP-compatible client can utilise the same MBTA transit tools we use, whether it’s our custom Exchange agent, Claude Desktop, or any other application that supports MCP.

A2A and MCP together define what agents say and what they can access, but SLIM addresses how those messages travel securely between agents. We will delve into the details of how MCP works in comparison to SLIM in future posts.

Secure Low Latency Interactive Messaging (SLIM), a Transport Layer Approach

SLIM is an end-to-end encrypted, secure agent messaging transport with authentication and authorisation handled through MLS groups and application-level identity mechanisms. for agent messages. This implementation utilises MCP and A2A over SLIM provided by the AGNTCY framework.

AGNTCY uses SLIM, an encrypted, authenticated transport layer designed for agent-to-agent communication. Think of A2A as the language agents use, and SLIM as the secure channel they use to communicate. As highlighted earlier, when the Exchange agent dispatches a message to the Alerts agent or the Route Planner, that message travels over SLIM in (Fig.1). SLIM is part of the emerging AGNTCY standards-based framework for agent discovery, identity, messaging, and observability, meaning future agents built by another organisation that also speaks SLIM can automatically plug into our reference application, without the requirement of custom integration work on either side.

In this post, we demonstrated how three protocols work in tandem to power MBTA Transit Conversational Intelligence, specifically the Alerts, StopFinder, RoutePlanner, and Exchange agents. We explored how A2A standardises agent collaboration and delegation, supporting the discovery and structured task handling essential for coordination. Additionally, MCP provides standardised access to transit data and tools, while SLIM ensures every message remains secure in transit. Together, they create a flexible architecture in which specialist agents collaborate to answer complex, real-world queries. 

In the next post, we explore the infrastructure that makes agent collaboration trustworthy and discoverable. We introduce the agent AI digital passport, a structured metadata record that gives each agent a verifiable identity and declares its capabilities. We demonstrate how these passports are stored in a private agent registry built on MongoDB and deployed on Akamai Connected Cloud (Linode), and how agents utilise this registry to discover one another. We will also examine the switchboard, which enables Multi-federated agent discovery across different registries and how it implements automatic schema translation.