nagarikdesu: NagarikAI: The AI Clerk That Turns Complaints Into Bureaucratic Pressure

A civic-tech prototype for Bengaluru that translates plain-language grievances into formal letters, routes them to the right department, and makes the complaint feel actionable before the LLM even runs.

8 min read • View on GitHub • More from radmm

A citizen speaks a messy complaint into a civic desk while a formal letter emerges on the other side and is stamped toward departmental files. The scene explains the core idea: software that translates everyday frustration into bureaucratic language the state is more likely to process. — NagarikAI is less a chatbot than a translation layer. It turns a complaint into something that looks ready for a clerk, a department, or an escalation chain.

Key Takeaways

NagarikAI’s real trick is not complaint intake. It is converting informal grievance into bureaucratic language that can travel farther inside a civic system.
The live parsing preview changes the product from a dead-end form into an interactive classification step that shows users who should own the problem before they submit it.
The architecture is intentionally thin at the AI layer and rigid underneath, with structured output, local persistence, and civic domain mappings doing most of the heavy lifting.
The prototype feels credible because it behaves like a workflow, not a demo, but it would still need real storage, integrations, and auditability to matter in production.

The complaint becomes a letter

The sharpest thing about NagarikAI is that it does not ask citizens to become better writers. It asks the system to accept a better-formatted complaint. A sentence like “water leaking near my apartment gate” comes back as something more official, more urgent, and more legible to a department desk.

That shift matters because civic portals fail in a predictable way. People describe a problem in human language, then hit a form that expects institutional language. NagarikAI sits in the gap and acts like a clerk who knows how to translate frustration into paperwork.

The project’s own system prompt pushes in that direction. It asks the model to behave like a legal-expert civic advocacy agent, which is a strong cue that the output should not sound chatty or generic. It should sound like pressure.

Why that feels different from a normal AI wrapper

Most AI apps add fluency. NagarikAI adds leverage. The generated letter is not just a nicer version of the input, it is a document that can plausibly be routed, escalated, or forwarded without a human rewriting the whole thing.

That is why the repo feels more civic than conversational. The LLM is not the product. The product is the conversion from grievance to administrative artifact.

Why live parsing changes the product

The NewReport flow does something subtle and useful: it classifies the complaint as the user types. Issue type, urgency, and responsible authority appear before submission, which turns the form into a preview of how the state will read the problem.

That matters because it reduces uncertainty. Traditional civic portals ask you to guess the right category first. NagarikAI shows the guess in real time, so the user can correct course before the complaint disappears into the wrong queue.

Live parsing makes the invisible rules visible. The user sees classification, routing, and urgency before the LLM finishes the full letter.

User action	Traditional portal behavior	NagarikAI behavior	Why it matters
Describe a problem	Enter a vague complaint into a rigid form	Type the issue in plain language	Lower friction at the first step
Choose a category	Guess the correct department	See live classification suggestions	Fewer dead ends and wrong routes
Submit	Hope it lands somewhere useful	Receive a structured letter and urgency level	The complaint gains administrative shape
Track impact	Often no visible community context	Issue can surface in a ranked civic workflow	The problem feels shared, not private

A close-up of a complaint being typed on one side and instantly separated into issue type, urgency, and department on the other. The illustration explains how live parsing shows the hidden classification layer before submission. — The best UX choice in the repo is making routing visible while the user is still typing. That turns classification into guidance instead of a surprise.

How NagarikAI is wired

The architecture is simple in the right way. server.ts acts as a structured-output proxy to Gemini, App.tsx coordinates the workflow and persistence, and types.ts plus data.ts define the civic domain the app is allowed to talk about.

// server.ts
const response = await ai.models.generateContent({
  model: 'gemini-3.5-flash',
  contents: prompt,
  config: {
    responseMimeType: 'application/json',
    responseSchema: {
      type: 'object',
      properties: {
        formalLetter: { type: 'string' },
        urgency: { type: 'string' },
        departmentId: { type: 'string' }
      },
      required: ['formalLetter', 'urgency', 'departmentId']
    }
  }
});

That schema is the key design choice. Instead of letting the model improvise, the app forces it into a civic-shaped envelope. The result is easier to trust, easier to store, and easier to route.

The frontend does the rest of the work. Reports and alerts persist in localStorage, which is crude but effective for a prototype. The app behaves like a civic workflow the moment it remembers what happened last time.

The civic model underneath the AI

The most important data in the repo is not the prompt. It is the mapping layer. Issue categories, urgency levels, and department assignments turn a vague complaint into a local administrative object.

Domain piece	What it represents	Why it matters
Issue categories	Roads, water, electricity, safety, and similar civic buckets	Keeps the model inside recognizable municipal language
Urgency levels	How quickly the problem needs attention	Turns emotion into triage
Department mapping	Who should receive the report	Makes the output actionable in local government terms
Multilingual support	English, Kannada, and Hindi	Broadens access without changing the civic logic

That localization is the real differentiator. Bengaluru is not treated as a generic city-shaped placeholder. The app assumes the user needs a system that knows how civic services are actually named and split apart.

Community score ranking strengthens that model. It says this is not just one private complaint. It is part of a visible civic queue, which makes the report feel more social and more pressurized.

What it gets right about adoption

A prototype earns trust by behaving like a real product. NagarikAI does that through local persistence, fallback responses when the API is unavailable, and UI that keeps moving even when the network or key is missing.

That is practical design, not decoration. A civic app cannot be brittle, because the user is already bringing urgency and frustration into the session. The interface has to absorb some of that pressure.

Design choice	Prototype benefit	Product signal
localStorage persistence	Reports survive refreshes	The app remembers context
mock fallback responses	The flow still works without the API	The product is resilient
live parsing preview	Users understand routing early	The system feels explainable
multilingual UI	More people can file complaints	The product is meant for a real city

What it would need to become real

The gap between prototype and deployment is still large. A production version would need a real database, authenticated user accounts, audit logs, and some kind of integration with government systems or email gateways.

It would also need stronger trust signals. Once a system starts converting complaints into formal language, people will want to know exactly what was sent, where it went, and whether anyone can tamper with it.

Still, the core insight is strong. NagarikAI is not interesting because it uses AI in a civic setting. It is interesting because it uses AI to make the state’s language available to ordinary people.