Commute Copilot Bangalore

Inspiration

Bengaluru commute is not just about distance. A 7 km route can take 20 minutes or 70 minutes depending on traffic, rain, metro access, parking, events, school timings, and the time of day.

Most people make this decision based on guesswork, checking multiple apps, asking friends, or just taking a chance.

We wanted to build an AI commute agent that does this reasoning for the user.

The idea behind Commute Copilot Bangalore is simple:

Don’t just show a route. Explain the decision.

The agent should be able to say:

Leave in 18 minutes. Take Metro to MG Road and walk the last kilometre because traffic risk is high near Domlur, parking is unreliable, and the weather risk is manageable.

What it does

Commute Copilot Bangalore is a multi-agent commute intelligence system for Bengaluru.

Given a source, destination, and target time, it recommends:

when to leave
which route to take
which transport mode to prefer
what risks to consider
what alternate options exist
why the recommendation makes sense

The system considers:

weather conditions
traffic hotspots
route alternatives
metro feasibility
last-mile walking effort
parking difficulty
local commute context
past decision logs

The final output is not just a route. It is a transparent commute decision with reasoning and confidence.

How we built it

We built the system using a multi-agent architecture.

The main agent is the Supervisor Agent, which receives the user query and coordinates with specialist agents.

The system includes:

Weather Agent: checks weather and walking risk
Route + Traffic Agent: compares route options, congestion risk, parking difficulty, and reliability
Transit Context Agent: checks metro, BMTC, and last-mile feasibility
Supervisor Agent: combines all evidence and generates the final recommendation

For retrieval and grounding, we used Elasticsearch on Elastic Cloud Serverless to store structured and unstructured commute data. This includes traffic hotspots, metro context, sample route data, parking notes, and decision logs.

We used Jina Embeddings v5 to convert commute context into vector embeddings so the system can retrieve semantically relevant information like:

evening commute to MG Road during rain
traffic-heavy areas near Domlur
routes similar to Spice Garden to MG Road

For LLM reasoning, we used Amazon Bedrock. The agents use Bedrock models to reason over retrieved context and produce clear, structured recommendations.

Kibana is used to visualize indexed commute data and decision logs for debugging and demo storytelling.

Challenges we faced

One major challenge was deciding what should be handled by live APIs, what should be stored as structured data, and what should be retrieved using vector search.

For example, exact values like weather, duration, and route distance should not come from embeddings. They should come from structured APIs or stored fields.

But contextual information like traffic advisories, local commute notes, event impact, and similar past decisions works well with semantic retrieval.

Another challenge was designing the multi-agent flow without overcomplicating the system. We initially considered separate agents for every factor, but simplified it into three specialist agents and one supervisor agent.

We also had to keep the project demo-friendly. Instead of building a large frontend, we focused on the actual agent reasoning, Elasticsearch retrieval, decision logging, and Kibana dashboard.

What we learned

We learned how to design a practical multi-agent system where each agent has a clear responsibility.

We also learned how Elastic can be used beyond basic search. In this project, Elasticsearch acts as a hybrid retrieval layer for structured search, semantic search, and decision logging.

We explored how Amazon Bedrock can be used as the reasoning layer for agentic applications and how retrieval-grounded agents can provide more trustworthy answers than generic LLM responses.

Most importantly, we learned that for real-world agent systems, the quality of data and the clarity of tool design matter as much as the LLM itself.