Avismara Hugoppalu
← All projects

Conversational agent · building now

Akshara

A zero-UI conversational agent for small and mid Indian schools. Parents, students and teachers message one number in natural language — text or voice, in English, Kannada or Hindi — and a scoped LLM agent answers from the school's own data. No app, no new UI. The channel is the interface.

Role
Founder / solo engineer
Stage
Architecture + skeleton (Phase 0)
Domain
Conversational agents · education
Why it matters
Where it gets real

The problem

School communication in India runs on chaotic WhatsApp groups. Parents can't query anything — they call the office, repeatedly, for marks, attendance, homework, the next holiday. There's no system of record they can actually talk to.

Akshara's wedge is zero adoption friction: parents already live in WhatsApp. So the product is a conversation, not an app — and the hard problems move from UI to the agent layer underneath.

The agent engineering

This is the part that makes it a platform problem, not a chatbot. The agent never talks to a data source directly — it talks to a uniform tool surface, and a gateway routes each call by source type:

  • MCP live-read for schools whose data lives in a Google Sheet — read through to their sheet as the source of truth, no copy held.
  • Structured store exact reads from a canonical Postgres store for data we ingest from PDFs, ERPs or Drive.
  • RAG over pgvector semantic search across notices, circulars and policy documents.
  • Access control at the tool boundary a parent can only ever retrieve their own child's data — enforced in code, not in the prompt, so no jailbreak can talk its way past it.

Evaluation is the spec

A wrong answer about a child is trust death, so grounding accuracy ≥95% is the primary, non-negotiable quality bar — the agent answers strictly from grounded tool results and says “I don't have that” on a miss, never inventing. Off-topic questions are declined by design (it's a scoped school-ops assistant, which also keeps it inside Meta's platform rules).

This is exactly the kind of problem my curiosity keeps dragging me toward: define the system by the evaluation it has to pass, then build to the metric.

Built to be cheap and portable

GPT-4o-mini by default with a per-student query cap keeps unit economics at roughly ₹2/student/month — the model provider is a swappable seam, not a hard dependency. A ChannelAdapter seam means the same core ships on Telegram (free, the build/demo vehicle) or WhatsApp (metered) with a one-config switch; the agent never knows which channel it's on.

Status

Top-level architecture and the skeleton are in place — interfaces and seams defined, bodies marked by build phase. Phase 0 (Telegram + agent + live Sheets read) is what I'm building into now. The market validation, unit economics and go-to-market live in a companion research dossier.

Stack
Swift 6Vapor 4MCP Swift SDKGPT-4o-miniFluent + PostgrespgvectorTelegram / WhatsAppFly.io (India region)