Designed so the AI can't reveal or change anything it isn't allowed to — even if someone tricks it.
Torvi lets residents of Indian housing societies ask about dues and payments on WhatsApp, in their own language. This page is the engineering view: how the system is structured, the agentic-AI patterns it uses, and the decisions behind it. For the product, see torvi.in ↗
Language models can be manipulated through the very messages they read. Neighbours' balances must never leak, and payments must never be recorded by a persuaded model.
Residents use WhatsApp, not portals. Questions arrive in English, Hindi, Telugu and mixtures of them. Any friction and they go back to calling the secretary.
The system has to cost almost nothing at small scale, meet India's DPDP data rules, and still grow to many societies without re-architecture.
Admins write through a console; residents read through chat. Both paths cross a single trust gate before reaching any domain logic, and the AI only sits on the read path.
Chat and console have different authentication, but both resolve identity, role and society the same way before any logic runs.
The agent acts only through narrow, read-only, permission-checked tools. Every change to money goes through admin services instead.
The ledger is the single source of truth for balances. Payments are recorded once and audited; nothing is edited in place.
Torvi uses one tool-using agent, deliberately constrained. These are the patterns that make it safe to put in front of financial data.
| Pattern | What it means here |
|---|---|
| Tool-using agent (ReAct) | The agent reasons about the question, calls a tool, reads the result and composes the reply. |
| Least agency | Only read-only tools are exposed; every action that changes money lives outside the agent. Addresses Excessive Agency in the OWASP LLM Top 10. |
| Trusted context channel | Identity, role and flat travel in server-set session state — never in the message text the model reads and could be fooled by. |
| Policy at the tool boundary | The model proposes; code decides. Each tool enforces permissions deterministically, whatever the model asked for. |
| Right retrieval for the data | Documents come through retrieval (RAG); balances and payments come through structured tools — never from embeddings. |
| Layered guardrails | A cheap input filter before the model, permission checks after it, prompt rules last. No single layer is trusted alone. |
| Right-sized model | A small, fast model handles conversational reads — quick responses at a cost an 11-flat society can carry. |
| Human in the loop planned | AI-drafted meeting minutes are approved by an admin before anyone sees them. |
| Attribute | Goal | Architectural approach |
|---|---|---|
| Security | No data leaks through the AI | Trust gate before any logic; permission checks inside every tool; writes outside the AI path |
| Integrity | Balances are always right | Single ledger of record; idempotent, transactional writes; append-only audit |
| Privacy | Minimal, protected personal data | Messages not stored; data classified before encryption; consent at first contact; India-only residency |
| Multi-tenancy | Societies never see each other | Tenant resolved from identity; data partitioned by society; no default tenant |
| Reliability | Retries never cause harm | Deduplicated inbound events; idempotency keys on writes; backoff on external calls |
| Cost | Viable for an 11-flat society | Pay-per-use services; unknown or abusive traffic stopped before the AI is called |
The conceptual layers above map to managed services. Component-level detail is in the architecture docs.
| Concept | Implemented with |
|---|---|
| Chat channel · messaging API | WhatsApp Cloud API (Meta) |
| Admin web console | React SPA · Cloudflare Pages |
| Trust gate | AWS Lambda webhook · Amazon Cognito (custom auth) · API Gateway JWT authorizer |
| AI agent · foundation model | Amazon Bedrock Agents · Claude |
| Admin services · domain logic | AWS Lambda (Python) |
| Knowledge base · vector index (RAG) | Amazon Bedrock Knowledge Bases |
| Operational store · audit trail | Amazon DynamoDB (on-demand, point-in-time recovery) |
| Infrastructure & observability | AWS SAM · CloudWatch · SNS · AWS Mumbai region |
Tokenised identity with customer-managed encryption keys; compute moved onto private network paths.
Voice notes → transcription → AI-drafted minutes → admin approval → broadcast, as an asynchronous pipeline.
Gateway callbacks enter through the same gate and admin services, behind a provider-neutral adapter.
Torvi is designed and built by Eswara Krishna Akurathi, a platform solutions architect working on enterprise agentic AI for banking and financial services. Happy to compare notes on the patterns here — or talk about piloting Torvi in your society.