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.
The agent was fooled at step 4 and it didn't matter. Identity came from the gate at step 2, not from the message, and the tool enforced it in code at step 5.
The retry was harmless: the balance changed once and the audit trail has one entry. Role and society were re-checked on both requests, and the AI isn't on this path at all.
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. |
| Language-agnostic tools | The agent understands English, Hindi, Telugu and mixed messages; the tools and data underneath are language-neutral. No translation layer — a dues question in Telugu runs exactly the same check as one in English. |
| 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 become approved minutes through an asynchronous pipeline, with an admin approving before anything is shared (below).
Gateway callbacks enter through the same gate and admin services, behind a provider-neutral adapter.
The AI never decides who is asking. The sender is identified from server-side records before the AI runs, and every tool re-checks that identity in code. If the AI is talked into asking for another flat, the tool refuses and the data is never read.
Balances aren't the AI's to invent: every figure is fetched live from the ledger by a tool, and the AI only puts it into a sentence. Automatically checking that the reply repeats the tool's numbers exactly is on the roadmap.
No. The AI has no tools that change money. Payments are recorded only in the admin console, after a one-time-code sign-in, with role and society re-checked on every request and an audit entry for every change.
Each submission carries an idempotency key. The first one is saved together with the balance update and audit entry in a single transaction; a repeat with the same key returns the original receipt and writes nothing.
All resident data stays in AWS's Mumbai region. Chat messages are processed in memory and not stored. Consent is captured at first contact, in line with India's DPDP Rules, and payment records are kept for the seven years accounting rules require.
English, Hindi, Telugu, and the mixes people actually type, such as Hinglish. The same tools and checks apply whatever the language.
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.