HomePage
Add a report
Report Details
Browser Automation
Follow Up Request
Chatbot for Quick query Resolution
Audit

About the Project

The idea for Relay started with a problem I personally ran into.

I study in Rajasthan, while my home is in Uttar Pradesh. And when I tried figuring out how to raise different civic issues, I realized something surprisingly frustrating: there isn't one simple way to complain. Different states have different portals, different departments, different procedures, and sometimes completely different ways of reaching the person actually responsible for an issue.

The problem wasn't "How do I report this?" It was:

"Where am I even supposed to report this?"

That made me wonder — what if I could just describe the problem once, and have a system figure out the rest?

That became the idea behind Relay.

Starting With the Problem

I started by doing something that turned out to be much harder than I expected: researching how complaints actually reach the people responsible for fixing them.

For different types of issues, I looked at the relevant government departments, portals, contact information, submission procedures, and what happens after a complaint is filed. I wasn't just looking for a list of websites. I wanted to understand the actual sequence of steps a person has to go through.

Then I started mapping those steps into something an agent could execute.

There was a lot of trial and error. Some workflows were straightforward, while others had multiple steps, authentication requirements, or no obvious digital integration at all. Through a lot of research and experimentation, I was able to work out the sequence of actions needed for the system to take a complaint from "something is wrong" to "the right authority has been contacted."

Turning That Process Into Relay

The core idea became surprisingly simple:

You shouldn't have to understand the government system just to report a problem.

You describe what happened, provide the location and any evidence you have, and Relay works out what needs to happen next.

The system first understands the complaint and determines things like its category, severity, and urgency. It then checks whether other people are reporting the same problem.

If 30 people separately report the same pothole, for example, Relay doesn't treat them as 30 unrelated complaints. It recognizes them as one larger community issue and builds a stronger picture of the problem.

From there, it determines the appropriate authority and the best available way to reach them.

The Architecture

One of the things I wanted to avoid was building a system where an AI simply decides what to do and has unrestricted control over everything.

So Relay separates reasoning from execution.

At the top is a coordinator built using Google ADK, which manages the different stages of the workflow. Gemini handles the parts that require understanding and reasoning — such as classifying complaints, comparing reports, understanding evidence, and interpreting authority responses.

Underneath that, deterministic services handle things where predictability matters: impact scoring, escalation rules, jurisdiction checks, permissions, and event processing.

The entire workflow is event-driven using Google Cloud Pub/Sub, so the system doesn't have to do everything in one request. A complaint can move through classification, incident matching, prioritization, authority routing, filing, monitoring, and follow-up as separate stages.

Firestore keeps track of the evolving incident and complaint state, while Cloud Storage stores supporting evidence.

The Biggest Challenge: Government Websites

This was probably the biggest reality check during development.

I initially thought the hardest part would be building the AI.

It wasn't.

The hardest part was actually getting a complaint to the right government system.

Government platforms don't always provide a public API that developers can simply plug into. Every portal can have its own workflow, authentication, forms, and restrictions.

So instead of assuming there would always be an API, I designed Relay around multiple ways of reaching an authority.

If an official API is available, Relay can use it.

If there is an official portal but no usable API, Relay can use a browser workflow powered by Playwright. The agent can navigate the portal, select the appropriate category, fill in the complaint details, and attach evidence.

But the citizen remains in control. If the website asks for an OTP, CAPTCHA, or identity verification, Relay pauses and lets the user take over. The user can see what is happening, complete the required step, and then hand control back to the agent.

And if there isn't a suitable digital filing route, Relay can fall back to a verified institutional email and send an evidence-backed complaint to the appropriate authority.

So instead of building around one particular government platform, I built Relay around the more fundamental question:

"What is the best verified way to get this issue to the person who can actually do something about it?"

From Complaint to Resolution

Another thing I didn't want was for Relay to stop at "Complaint submitted."

That's where the event-driven architecture becomes important.

Once a complaint is filed, Relay keeps track of its progress. If an issue remains unresolved or crosses a defined threshold, the system can prepare a follow-up.

Before consequential actions such as sending a follow-up or escalation, the citizen can review and approve what will be sent.

This creates a human-agent partnership rather than handing complete control to an AI.

The goal is for the citizen to only step in when their involvement is actually needed — while Relay handles the repetitive work in between.

What I Learned

The biggest thing I learned is that building an agent isn't really about making an AI that can do everything.

It's about understanding a real-world process deeply enough to know what should happen next.

A government complaint might look like a simple form, but behind that form are questions about jurisdiction, departments, evidence, urgency, authentication, follow-ups, and accountability.

The more I researched these workflows, the more I realized that the valuable part wasn't just automating one form. It was building a system that could adapt to the messy reality of how public services actually work.

Relay started with a very personal frustration — "Why is it so difficult to figure out where to complain?" — and became an attempt to make that entire process feel as simple as: