Inspiration

Government scholarships and welfare schemes are often easier to find than to actually apply for.

As students, we experienced how fragmented the process can be: information is spread across different portals, eligibility rules can be difficult to interpret, required documents are easy to overlook, and application progress becomes another thing to manage.

We wanted to solve the part that existing discovery tools largely leave to the user.

Instead of building another directory or chatbot that says "you may be eligible," we wanted an agent that could take the process further: understand the user's situation, find relevant opportunities, check eligibility, work with their documents, prepare an application, identify what is still missing, and keep the application state organized.

That became Iva.

What it does

IVA is an agentic assistant for government schemes and scholarships.

A user can describe their situation naturally instead of knowing the exact name of a scheme. IVA can then coordinate a multi-step workflow:

Discover → Evaluate → Verify → Prepare → Review → Track

The agent can:

discover relevant government schemes and scholarships evaluate eligibility using structured scheme rules distinguish eligible, not eligible, and insufficient information identify required and missing documents verify scheme/source provenance prepare application fields from profile and document evidence show where each populated field came from identify missing information and documents maintain application state and progress resolve an application's status using the authenticated user's actual application stop at sensitive steps such as OTP, identity verification, CAPTCHA, and final submission

The important part is that IVA is not simply generating these results in conversation.

Gemini operates as the reasoning and orchestration layer through Google ADK, while deterministic backend tools handle structured operations such as eligibility evaluation, document matching, application state, identity, and status.

For the demo, we also provide isolated scenarios that let judges see the difference between a fully verified applicant and an applicant with missing documents.

How we built it

IVA uses a multi-layer architecture:

Next.js / React ↓ FastAPI backend ↓ Google ADK Agent ↓ Gemini ↓ Specialized tools/services ↓ Firestore + government data sources

Gemini handles interpretation, reasoning, orchestration, and explanation.

Google ADK provides the agent runtime and context propagation.

Our backend tools handle deterministic operations such as:

scheme discovery eligibility evaluation personalized ranking document matching document verification state application preparation application persistence application status source/legitimacy checks

Authenticated identity is propagated through the ADK runtime using ToolContext.user_id, rather than allowing the model to invent internal IDs.

We also designed the application around provenance. Form fields can retain their value, source, verification state, and editability, so a value coming from a verified document is not treated the same way as an unverified profile value.

We used AI throughout development for scaffolding, debugging, test generation, data-pipeline iteration, and Firestore integration, then validated those changes through automated tests and end-to-end checks.

Challenges we ran into

The hardest problems were not simply getting Gemini to answer questions. They were making the entire workflow reliable.

Accomplishments that we're proud of

At one point, the model could see a user_id parameter but had no trusted mechanism for receiving it, which allowed it to invent values such as user_1234.

We changed this so authenticated identity comes from the application runtime and is injected into tools through ADK's ToolContext.

What we learned

Our biggest lesson was that agentic systems are more about system design than prompt design.

A capable model is useful, but it should not be responsible for facts that the application can determine reliably.

We learned to make clear boundaries between:

model reasoning deterministic business logic authenticated identity persistent state external evidence user-controlled actions

We also learned that agentic workflows need explicit failure states.

"Insufficient information" is much more useful than forcing the model to choose between yes and no.

Another major lesson was the importance of observability and provenance. Users should be able to understand not only what IVA filled in, but where the information came from and whether it has been verified.

What's next for Iva

Inspiration

Government scholarships and welfare schemes are often easier to find than to actually apply for.

As students, we experienced how fragmented the process can be: information is spread across different portals, eligibility rules can be difficult to interpret, required documents are easy to overlook, and application progress becomes another thing to manage.

We wanted to solve the part that existing discovery tools largely leave to the user.

Instead of building another directory or chatbot that says "you may be eligible," we wanted an agent that could take the process further: understand the user's situation, find relevant opportunities, check eligibility, work with their documents, prepare an application, identify what is still missing, and keep the application state organized.

That became IVA.

What it does

IVA is an agentic assistant for government schemes and scholarships.

A user can describe their situation naturally instead of knowing the exact name of a scheme. IVA can then coordinate a multi-step workflow:

Discover → Evaluate → Verify → Prepare → Review → Track

The agent can:

discover relevant government schemes and scholarships evaluate eligibility using structured scheme rules distinguish eligible, not eligible, and insufficient information identify required and missing documents verify scheme/source provenance prepare application fields from profile and document evidence show where each populated field came from identify missing information and documents maintain application state and progress resolve an application's status using the authenticated user's actual application stop at sensitive steps such as OTP, identity verification, CAPTCHA, and final submission

The important part is that IVA is not simply generating these results in conversation.

Gemini operates as the reasoning and orchestration layer through Google ADK, while deterministic backend tools handle structured operations such as eligibility evaluation, document matching, application state, identity, and status.

For the demo, we also provide isolated scenarios that let judges see the difference between a fully verified applicant and an applicant with missing documents.

How we built it

IVA uses a multi-layer architecture:

Next.js / React ↓ FastAPI backend ↓ Google ADK Agent ↓ Gemini ↓ Specialized tools/services ↓ Firestore + government data sources

Gemini handles interpretation, reasoning, orchestration, and explanation.

Google ADK provides the agent runtime and context propagation.

Our backend tools handle deterministic operations such as:

scheme discovery eligibility evaluation personalized ranking document matching document verification state application preparation application persistence application status source/legitimacy checks

Authenticated identity is propagated through the ADK runtime using ToolContext.user_id, rather than allowing the model to invent internal IDs.

We also designed the application around provenance. Form fields can retain their value, source, verification state, and editability, so a value coming from a verified document is not treated the same way as an unverified profile value.

We used AI throughout development for scaffolding, debugging, test generation, data-pipeline iteration, and Firestore integration, then validated those changes through automated tests and end-to-end checks.

Challenges we ran into

The hardest problems were not simply getting Gemini to answer questions. They were making the entire workflow reliable.

Identity propagation

At one point, the model could see a user_id parameter but had no trusted mechanism for receiving it, which allowed it to invent values such as user_1234.

We changed this so authenticated identity comes from the application runtime and is injected into tools through ADK's ToolContext.

Eligibility vs. missing information

A simple boolean was not enough.

A user can be neither clearly eligible nor ineligible if important information is missing.

We therefore introduced:

Eligible Not Eligible Insufficient Information

with matched rules, failed rules, and missing information.

Documents as evidence

A profile value and a document-backed value should not have the same trust level.

We built document provenance and verification metadata so application fields can indicate whether they came from a profile or supporting evidence.

Keeping state consistent

The same application is represented across the Agent, frontend, documents, forms, and status views.

We had to make sure these components used the same authenticated user, application ID, scheme ID, and persisted state rather than maintaining disconnected copies.

Model failures

Gemini quota limitations created a practical reliability problem during development.

We implemented a configurable Gemini fallback chain so retryable model failures can move to another configured Gemini model while preserving the same logical request and session.

Accomplishments that we're proud of

We are most proud that IVA evolved beyond a conversational prototype into a tool-driven workflow system.

Some of the things we achieved:

A central Google ADK + Gemini Agent Core rather than separate AI implementations for each interface Multi-step tool orchestration across discovery, eligibility, documents, applications, and status Deterministic eligibility logic instead of asking Gemini to calculate government rules from memory Authenticated user identity propagated through ADK context Scheme-to-application status resolution without exposing internal IDs to the model Document-aware form preparation with source and verification metadata Per-user demo scenarios for demonstrating both successful and incomplete application flows Safe document ownership and application ownership checks A mock government portal used to demonstrate the workflow without pretending to access unavailable government APIs Automated regression coverage across the major backend workflows

Most importantly, the system can demonstrate a complete path from:

"What can I apply for?"

to:

"Here is what you qualify for, what I prepared, what is still missing, and what you need to do next."

What we learned

Our biggest lesson was that agentic systems are more about system design than prompt design.

A capable model is useful, but it should not be responsible for facts that the application can determine reliably.

We learned to make clear boundaries between:

model reasoning deterministic business logic authenticated identity persistent state external evidence user-controlled actions

We also learned that agentic workflows need explicit failure states.

"Insufficient information" is much more useful than forcing the model to choose between yes and no.

Another major lesson was the importance of observability and provenance. Users should be able to understand not only what IVA filled in, but where the information came from and whether it has been verified.

What's next for IVA

The current system focuses on the core workflow from discovery to application preparation.

The next step is to make IVA broader and more deeply connected to real-world government workflows.

We want to expand:

live official scheme/source ingestion document extraction and verification asynchronous application monitoring notification and reminder workflows broader phone/IVR accessibility integrations with additional legitimate government services and portals richer long-running agent state and background execution

The long-term goal is to make IVA less like a place where users ask about government benefits and more like an agent that can help them actually obtain them safely and with the user remaining in control of sensitive decisions.

Built With

Share this project:

Updates