The situation
An apartment community's committee runs on the same infrastructure most of them run on: a WhatsApp group, a spreadsheet somebody's cousin set up, and one person's memory. Bills go out. Payments come in. Somebody asks in March what was decided about the water tank in November, and three people give three answers.
The problem is not that the data doesn't exist. It exists — scattered across chat history, receipts and one increasingly overloaded treasurer. The problem is that nobody can ask it anything. Every query costs a human being an evening.
The obvious move — put it in an app — fails on adoption. Committee members are not going to log into a portal. They are already in WhatsApp. Any system that asks them to be somewhere else has lost before it starts.
What was built
Smriti — Sanskrit for that which is remembered — is an agent that lives where the committee already lives.
- WhatsApp as the entire front end. No new app, no login, no training session.
- A structured store underneath. SQLite holding bills, payments, threads, bylaws and decisions — real records, not a chat log with search over it.
- Skills for the actual jobs: bill generation, payment status, cash position, reconciliation, bylaw lookup, historical thread retrieval.
- A committee dashboard for the views that don't fit in a chat message.
- A deterministic core doing the work the model shouldn't: identity, arithmetic, and the write path.
Built on BizClaw, self-hosted, running in one building.
Physically unable to write
Where this system can be wrong
An agent with a database is an agent that can corrupt a database. The usual answer is to instruct it not to — a line in the prompt saying only read, never write. That is not a control. It is a request, made to a probabilistic system, about people's payment records.
So the query path was rewritten to remove the capability rather than discourage it. It opens the database with SQLite's read-only flag. Three independent layers now sit between the agent and a write:
- A prefix check rejecting anything that isn't
SELECTorWITH— fast, with a readable error. - The read-only database mode itself — the physical guarantee, enforced by SQLite rather than by policy.
- The driver's own single-statement enforcement, which rejects smuggled input like
SELECT 1; UPDATE ...before it reaches the database at all.
All three were tested against the live database, including the negative cases: a direct UPDATE rejected, a smuggled multi-statement rejected, and the target row confirmed unchanged afterwards.
So the claim is literal rather than rhetorical: on this path, the AI is physically unable to edit records. Not instructed not to. Unable.
What happened
Smriti runs live in one building today, in daily use by the committee, on the community's real records. The queries that used to cost someone an evening now cost a message.
The write path — logging a payment or a note from WhatsApp — still exists, deliberately, handled separately from the query path with its own script. Reading and writing were split precisely so that the broad, open-ended, model-driven surface is the one that cannot cause damage.
We're careful here not to quote hours-saved or rupees-recovered figures. We could estimate them; they wouldn't be measured, and a case study that opens with an invented number has already told you what kind of firm wrote it.
What made it repeatable
A system that runs in one building is a favour. A system that deploys to the next one is a product.
An export script generates a deployment package: it collects the scripts, derives a genericised configuration, carries the documented skills, and flags anything undocumented. Every export is checked for leaked identifiers — the source building's name, absolute host paths, local IP addresses — before it travels.
The engagement shape
- Discovery — what's actually being asked, and of what records. Usually smaller and more specific than the initial brief.
- A bounded first build on one real dataset, in the channel people already use.
- Hardening — the write path, identity, authorisation. Where the value is, and the step most AI pilots skip.
- Packaging — export, documentation, checks, so instance two doesn't need us.
Typically weeks, not quarters. The deliverable is a system your team operates, plus the package that lets it be deployed again.
What's still open
Named, not hidden. A case study that admits open items is worth more than one that doesn't.
- Dashboard authentication. Needed before a real bank account number lives behind it. Today the discipline is procedural: prospects see the public demo and a sample conversation, never a live dashboard URL.
- Chat authorisation. WhatsApp identity is a phone number. “Log this payment” should only be honoured from committee members' numbers — enforced in the deterministic core, not the prompt.
Both are on the deployment checklist for building two. Neither affects the building running today, because the damage they'd prevent is damage the read-only path already can't do.
Next case study
BizClaw →