State Modernisation
Wrapping a 20-Year-Old Database in Agents
· 9 minute read
A twenty-year-old database can feed an agent through a replica, a view and a refuse-list. It cannot survive an agent that UPDATE-s past the form that held the validations.
The table names still shouted 2005: TBL_APP_MST, TBL_APP_DTL, a trigger called TRG_DONT_TOUCH. The form that wrote them checked seven conditions an officer could still recite. The vendor's agent, given a database tool, generated an UPDATE that set STATUS='A' because a citizen had asked whether the file could be expedited. The trigger fired halfway. Demand and the web status diverged. The wrap had become a wound.
Wrapping is the right idea. You do not rewrite a land, treasury or scholarship core to get a retrieval agent. You put a controlled surface in front of it. The surface is a replica or a view, a documented schema slice, a tool list that cannot write, and an encoding story for Indic text. SQL access with a cheerful model sitting on top is not a wrap. It is a second, worse client.
This guide is for integrators and departmental technical committees. It assumes the legacy audit in the previous article did not say no-go. It is written on 17 August 2026. It is not engineering advice you can paste as a warranty, and it is not legal advice.
The wrap is a surface, not a login
Give the agent a service account that can SELECT on a replica or a set of views. Revoke INSERT, UPDATE, DELETE, EXECUTE on procedures that mutate. If the database product makes that hard, put a thin API in front and do not give the model a connection string. Name columns in the view the way officers speak, and keep the mapping table in the file. A model that sees FLG_X = 3 will invent folklore. A view that exposes application_stage with a coded enum documented in a signed data dictionary will still be wrong sometimes — but you can see why.
Do not wrap SELECT * FROM the citizen table. Project the fields the workflow needs. Purpose limitation is easier when the column list is short.
| Pattern | Use when | Do not use when |
|---|---|---|
| Read replica + views | Status and history questions; lag is known and disclosed | The citizen will act on a payment or mutation that can change in minutes |
| Signed extract / warehouse | Analytics, backlog, officer briefing | You pretend the extract is live |
| Official API / stored proc read | The owner will version it | The proc secretly writes |
| RPA on the old form | You are desperate and the form is the only validation | You need volume or honesty; RPA is brittle and still a write |
| Direct SQL write by the model | Never | Always |
Encoding, keys and ghosts
Old Indian databases mix UTF-8, UTF-16, and vendor encodings for Hindi, Telugu, Tamil, Bengali. A wrap that does not test khata, khasra, and citizen-name fields will retrieve garbage and the model will politely correct a name. That correction is a records event. Test with real (lawfully processed) samples in a masked set. Primary keys are often composite, recycled, or meaning-bearing (a district code baked into an ID). Do not let the agent invent a join. Publish allowed joins as views. Ghost rows — cancelled, test, migrated, TEMP2 = 7 — must be filtered in the view, not explained away in a prompt. Prompts drift. Views are reviewable.
Transactions the model cannot see
A twenty-year core often commits in two steps, or posts to a log table the form reads back. An agent that reads only the master table will announce success while the detail table is empty. The wrap must expose the same done definition the form uses. Locking: a long retrieval transaction on OLTP is how you recreate 2008's month-end freeze. That is why the replica exists. Time: store the as-of timestamp on every answer that came from the wrap. As of 14:02, replica lag 8 minutes belongs in the officer-facing UI.
Security of a second client
The agent is a new client of a crown-jewel database. It gets its own credential, rotation, and break-glass. It does not get the APP password from 2011. Prompt injection against a tool-using agent is a data exfiltration path. Even a SELECT-only account on a wide view can dump a district. Keep the view narrow. Rate-limit. Log every query the tool issued, not only the chat. CERT-In's 180-day log floor applies to this new client. So does DPDP if the rows are personal data. Embeddings of the wrap's output are another copy. Decide if they may exist.
- No production connection string in a vendor laptop, ticket, or demo VM that leaves the SDC.
- Masked replica for development. Real replica for production reads.
- Query allow-list if you can: stored reads, not free SQL.
- Kill-switch that only drops the agent's credential, not the department's forms.
Two rooms you can walk into
The wrap either respected the form or replaced it badly.
Objections you will hear — and what to do with them
These are the lines that stall the file. Answer them in the room, then put the answer in the note.
Views will be stale the day the schema changes.
Then version the views with the same CAB that changes the form. A wrap without an owner ages into a lie. Ownership is cheaper than a rewrite.
The model is smart enough to write safe SQL.
It is not a competent officer and it is not your trigger library. Smart SQL that skips a stamp is the failure mode.
RPA is faster to deliver.
RPA is a write through the form, which is safer than SQL, and still a production client that breaks when a pixel moves. Use it only as a last resort and never as a retrieval layer.
We will move to a new core next year, so the wrap is throwaway.
Next-year cores slip. Design the views as if they will live four years. If the new core arrives, you have a contract to reimplement.
A five-week wrap that does not UPDATE
If the legacy audit was a no-go, do not start this clock.
- Week 1: pick the three questions the agent may answer. Design views that contain only those fields. Write the as-of and lag rule.
- Week 2: stand a replica or extract. Test Indic samples and ghost-row filters. No OLTP reads.
- Week 3: service account, revoke writes, query logging, kill-switch drill. Masked dev copy.
- Week 4: tool interface = those three reads only. Injection test on the village-walk prompt.
- Week 5: officer UI shows as-of. Citizen wording approved by the department. CAB entry for view ownership.
How this shows up in the file
Subject: Wrap of the named system for a read-only agent. Surface named (replica, views, API). Privilege: SELECT only. Tools: the three named reads. No free SQL. As-of timestamp mandatory. Ghost rows filtered in the view. Credential rotation and kill-switch tested. Embeddings allowed or forbidden. This wrap does not replace the form as the write path.
What we will and will not claim
Prcept AI will call your views, not your OLTP, and we will refuse a database write tool. If an integrator proposes free SQL just in staging, mark the design down. Staging credentials have a way of becoming production folklore.
This article is informational field guidance for Indian universities and public institutions, not legal, procurement, audit or engineering advice. Confirm against the live Gazette, GFR, state financial rules, GeM terms, UGC text, GIGW, DPDP commencement, departmental manual and your counsel before you file it.
How to sequence this in a state, not a slide
“Wrapping a 20-Year-Old Database in Agents” is a department problem. A P4 System Integrator should name the legacy system, the officer who owns the file, and the citizen charter clock before buying “legacy integration AI agents”.
A twenty-year-old database can feed an agent through a replica, a view and a refuse-list. It cannot survive an agent that UPDATE-s past the form that held the validations. Do not invent league tables of states. Read tenders and policies. Election Model Code of Conduct can freeze a rollout. NIC is a partner, not a villain. SDC readiness is GPU, power, ops and egress — not a logo.
- Audit the legacy store first.
- Keep mutation and money as officer actions.
- Map SLAs to the citizen charter.
- Budget change requests after go-live.
Close this loop before the next CAB
Put “Wrapping a 20-Year-Old Database in Agents” on the next change-advisory or bid-opening agenda as a single line item with an owner. If it cannot earn a line item, it will not earn a control. The owner should be a P4 System Integrator, not “the vendor.”
Revisit the item when the model, the GeM term, the region, or the SI changes. “legacy integration AI agents” is not a one-time workshop. It is a watch item. Date the last check. Unsigned watch items are souvenirs.
Questions this usually raises
- Can an AI agent query a twenty-year-old government database directly?
- It can read a narrow, documented surface — replica, view or API — with SELECT-only credentials. It must not run free SQL on OLTP and must not write. Direct access to the operational schema is how you skip validations and leak villages.
- What about stored procedures that already exist?
- Read procedures that the owner will version can be tools. Mutating procedures stay with the form and the officer. Inspect each proc; names lie.
- How do we handle replica lag?
- Measure it, print as-of on the officer screen, and refuse questions that cannot tolerate that lag — typically payments and mutations.
- Is RPA an acceptable wrap?
- As a last-resort write-through-the-form, sometimes. As a retrieval layer, no. It is brittle and still needs logs, identity and a kill-switch.
- Do embeddings of database rows count as another copy?
- Yes. Decide purpose, retention and whether they may exist at all. A wrap that copies the crown jewel into a vector store is a new database you did not audit.