Odyssey

Inspiration

We all love to travel whether that be to go home to be with family or to explore new places and try something new. But, the one consistent problem is that we have to browse through so many websites, like booking.com, Expedia, and the Amtrak app, to find the perfect combination of the best flights, trains, hotels/AirBnBs, and experiences in a way that is affordable for us. This is not just stressful, but time consuming. For all of us, time is valuable.

Inspired by this, we decided to create Odyssey to help us simplify traveling and focus on high quality, enjoyment, and a relaxing experience personalized for us.

What it does

Odyssey is a platform where users can chat with our agentic system to discover the most optimal plan for their upcoming trip. The agents in our system each converse with one another and resolve conflicts between them to create a trip plan that works best for the user. While our platform does the heavy lifting of finding the necessary information, it also hands control over to the user to actually review the plans, make changes to accommodate their preferences, and ultimately, do the actual bookings. Additionally, the system proactively asks questions to the user to clarify details and create the best travel experience.

How we built it

For many travel-based applications, the architecture usually is a supervisor agent that routes the conversation to the correct subagents and runs them sequentially. While this approach is good, it leaves room for the user’s constraints such as the budget to be ignored. To prevent this, we decided to approach this problem using the idea of undirected connection between agents. This led us to use coffeeAgntcy’s lungo demo as our starting point to build off for Odyssey.

We used LangGraph to build the six agents in our system: hotels agent, flights agent, budget agent, trains agent, activities agent, and weather agent. Each agent has a specialized goal that it optimizes for, a specific method for improving its response based on the constraints of other agents, and a specific method for objecting to other agents if it is not satisfied. All the agents except the weather agent use their own tools to get data from our mock data. The weather agent connects to the pre-existing weather MCP that lungo uses.

To allow the agents to communicate with one another, we used SLIM (Secure Low-Latency Interactive Messaging). Each agent runs independently and registers on SLIM as an A2A server with its own address. For every trip, the gateway of the platform opens a new SLIM connection and invites the agents that are live and healthy. Each live agent is able to see the user’s messages and take turns scoring the current trip plan, until all the agents are satisfied with the plan. By using SLIM, we allow the connection between the agents to be undirected.

Once the plan is finalized, it is sent to the user and the user has the option to send the plan to their email via our custom email MCP that we built with FastMCP that composes the body and subject line of the email. The user can add their email address and click send on the email to get a copy of the plan.

Challenges we ran into

While we were building Odyssey, we ran into issues with having the agents communicate with one another reliably. As we ran the six independent agents on the shared SLIM connection, it exposed problems and edge cases that we needed to rework into our design. For example, if one agent failed, the entire platform would hang. To mitigate this, we added timeouts and made a failing agent pass its turn with an objection instead of stalling the entire negotiation.

Furthermore, the SLIM connection was flooded with messages as every agent received every user message and would each reply to every message. To prevent context-bloating, we introduced strict turn-taking to ensure that only one agent was talking at a time and reduce the noise in the channel.

Accomplishments that we're proud of

We are proud of the gateway we built that our agents are communicating across and our optimization algorithm that allows them to negotiate a well rounded trip itinerary that satisfies the main goals of the user’s trip request. We accomplished our goal of allowing the user max flexibility while still creating a reliable trip itinerary by training our agents to accept feedback and recompute a new trip that accommodates any new changes.

What we learned

Through building the Odyssey, we gained a strong understanding of the various hierarchies and organization frameworks in multi-agent systems. We also got hands-on experience with A2A undirected connections with Cisco’s SLIM and designing how decisions in multi-agent systems are taken by the agents. Finally, we were able to work with a different framework like LangGraph to create small agents, each with reasoning capabilities.

What's next for Odyssey

Currently, we are working out of a small mock database for weather, activities, and locations but in the future, we would like to add APIs to access real time updates and information for a wider range of destinations, conditions, and tools to maximize accessibility to the users. In addition, we also want to add user history to create a sense of familiarity and expand personalization as the user plans more trips.