I Built My First AI Agent in 3 Hours. Here’s Exactly How I Did It (with n8n)

PRODUCT PROTOTYPE STORIES – MTA Bus Assistant 
Conquering the every day poor MTA bus experience: Using n8n, Gemini & MTA Real-time bus data

Context

Have you ever waited at a bus stop in NYC and felt like you were waiting an eternity for a bus that Google Maps says is about to arrive, but it never does? This everyday scenario is a common one that I and many other new yorkers face every day. 

I started this project to solve a personal pain point: missing the bus and not knowing exactly when the next one would arrive. My solution was to build an agent that uses reliable MTA bus data, so I can simply ask it for real-time updates and get the peace of mind that comes with knowing when to be at the bus stop.

User Story

“As a regularly frustrated bus commuter I want a reliable assistant to tell me when the next buses would arrive and how many minutes I have so that I can more accurately plan my route”

My main goal here was to provide a better experience when it comes to taking the Bus in NYC and improve commuter sentiment around being motivated to take MTA buses.

Development method of choice

My priority here was to be able to easily deploy an Agent application in production and stumbled upon n8n or “Nodemation” which had an engaging interface and a large community of people building projects.

AI Model

For this app, I went with Google’s Gemini and created an API key via Google’s AI studio so I could easily embed this onto my agent’s build

Basic features

1. Chat interface so that I could interact with my agent
2. Connection to MTA’s real-time bus data to identify bus timings for several routes of interest
3. Send email function to be able to inform persons via email on the upcoming bus information
4. Html formatting of the email sent to users in order for it to be easily read in a user-friendly manner

Time it took

The first version of the app prototype consisting of a way to test the connection to Gemini was easily set up within 5 minutes. This was extremely easy to achieve based on the large amount of accessible templates available on n8n. 

Getting connected to the MTA bus data however, was slightly more time consuming as there were several steps to overcome like:

1. Requesting an API key from MTA
2. Deriving the right GET URLs to configure into n8n for the specific bus stops and routes of interest

Which took around 2 hours. This step could have been quicker to overcome with better documentation and examples from MTA’s API documentation.

Connecting n8n to gmail for the ability to send emails out, took around 2 minutes. While the last part which was setting up the agent’s logic via Vibe Coding probably took around 20+ minutes. 

The framework I used to set up the agent was recommended on a Youtube video which looked like this:

• Role – what kind of assistant is it?
• Task – what is it trying to accomplish?
• Input – what data does it have access to?
• Tools – what actions can it take?
• Constraints – what rules should it follow?
• Output – what should the final result look like?

In just about 2.5 hours I was able to build an MTA Bus Assistant, deployed to a dedicated production site and able to be used on-the-go in NYC.

How did the agent fare?

I started by initiating a chat with My Bus Assistant, wanting to know when the next 2 buses were coming and I asked the agent to affirm if the information was true by asking twice.

What was great about this was that the agent was giving me:

• Exact timings of when the next buses would arrive
• Computation of how many minutes I had to walk over and expect to wait at the bus stop
• The second bus time was a great alternative to have in case I wanted to take my time or make a different decision and take a subway instead or walk

Another thing I was able to do was to continue to chat with the agent to get up-to-date information of the buses in order to assess if there was any drift in timing which could help me manage my expectations and give me the right visibility over my waiting situation.

True enough, the buses did actually drift in timing with the estimated arrival of the first bus coming 1 minute later while the second bus was expected to come 2 minutes earlier.

Although strange, I was happy to have this visibility and it kept me calm and made my bus waiting experience a lot more enjoyable. 

1 minute later, I check again and yet again the first bus’ timing drifts 1 minute later. This makes me feel assured that the data is correctly reflecting and the bus was probably stuck at a light or traffic a few streets away. My assistant also advises me to be at the stop right then to be able to catch the bus.

The clock strikes at 6:21pm and the verdict is out: The M10 bus arrives! Just as my agent said.

At this point, I am over the moon and in awe that the agent did its job and I could board the bus feeling at ease.

Although I didn’t need to use the email function in this scenario, I tested it at a different time and got pretty helpful results that gave me good confidence that it would be useful in the future for planning ahead:

Observed limitations

I found that the consistency of the model’s response was not always guaranteed observed through the following:

• At times, the assistant would give me timings of later buses and not the one immediately coming up next. This I overcame by asking the agent to check again and be sure to give me the earliest bus arrivals
• For the emails sent by the agent, even though I had prescribed the agent to send using html formatting, there were certain emails which still got sent details in a JSON format which made it less user-friendly of an experience. This however was a very rare occurrence and 9/10 other times the formatting would be fine.

• In terms of the information sent in the email, sometimes the agent would send me a condensed version of information about the arrival times and how many minutes I would have to make it in time. Other times, the agent would provide detailed information about potential reasons for why the buses might be running late including route detour.

• The agent was not able to continuously monitor bus times and send me a message or email when it detected a bus just 1 minute away. The agent openly shared with me that it depended on me triggering it to provide the right information based on submitting a question on the chat. 

Others:

• UI design of the chat interface hosted on n8n
  • As I was focused on deploying fast, I used the self-hosted option to deploy the MTA bus assistant chat on n8n and there weren’t any alternatives to changing the UI design hence, the overall look was very basic and the font wasn’t the best – but it worked well and that’s the most important thing.

Overall thoughts

In 2.5 hours, I as a Product person was able to build and deploy a chat agent into a production environment using out of the box integrations, chat interfaces with a lot of ease. The only technical thing I had to overcome was getting the API keys from Gemini and MTA and configure the right GET Urls but everything else was a breeze & I am so happy with this output.

This presents many obvious benefits in terms of : 

• For work: Quick ability to build 1st version MVP agents to demo ideas to leadership
• For life: I can now abandon poor user experiences I faced on Google Maps and trade it out for this agent, customized to my needs around specific buses.

I can’t recommend more for anyone to try out n8n and deploy their first agent today.

TLDR

Using n8n, Gemini API & MTA Real-time bus API, a product manager managed to build an AI-powered Bus assistant to predict and plan upcoming bus arrivals on specific routes with no coding required