Public bodies are, on paper, ideal ground for agents: large volumes of records, readings and repeat decisions. What holds most of them back is not the technology. It is that the records have rules about where they live and who may touch them.
Why regulators suit agents
A regulator’s daily work is full of tasks agents handle well: reading applications against a checklist, summarising inspection and monitoring reports, drafting routine correspondence, and flagging the cases that need an officer’s attention. The work is high in volume, structured enough to check, and costly when it backs up.
It is also work where being wrong carries public consequences, which is why the architecture matters as much as the model.
The constraint: records have rules
Government records usually come with requirements about where they are stored, who can access them, how long they are kept and how access is recorded. Those rules do not relax because a new tool has arrived, and they should not.
The common mistake is to treat the agent as the centre of the design and move the data to it. That turns every agent into a new data store, each needing its own approval, security review and retention policy.
The pattern: data stays put, the agent comes to it
Turn it around. Records stay in the environment that is already approved for them. The agent reaches them through narrow interfaces that expose only what a task needs: this application, these fields, read-only unless a person approves a change.
Each interface is logged. Every read, every proposed action and every approval is recorded with the officer or service account responsible, so an accountable person can always see what the agent did and why.
The rule to design around
Move the agent, not the records. Expose only what each task needs, and log every request.
How we build narrow, logged interfaces with MCP
Multi-cloud as a residency tool
Multi-cloud is usually sold on resilience. In the public sector its more practical value is placement. Different record sets may be approved for different environments, and the best model for a task may be offered somewhere else. A multi-cloud design lets each workload sit where its rules allow, with one shared control layer for identity, logging and policy across all of them.
Before naming any provider or region in a design, check the current official rules that apply to the records involved. They differ by country, by department and by type of data, and they change.
Why agentic AI needs more than one cloud
Dashboards: one view for accountable officers
Officers who answer for decisions need to see what agents did without reading logs. A dashboard showing open cases, what each agent proposed, what a person approved and what is still waiting gives them that view. It also turns agent activity into something a department can review, report on and improve.
Where Focus20 fits
We design residency-safe architectures for public-sector agents: where each workload runs, how agents reach records, what is logged and how officers see it. We are currently providing multi-cloud architecture support to the Maharashtra Pollution Control Board for its agentic AI implementation, blockchain layer and dashboards.
Read about the MPCB engagement
Questions we get
Can government data be used with hosted AI models?
Often, within the rules that apply to that data. The answer depends on the records, the jurisdiction and the hosting option, so confirm it against the official guidance and with the data owner before any design is final.
What should stay where it is?
The system of record. Agents read and propose through interfaces; the authoritative copy of each record stays in its approved environment.
How should a department start?
With one high-volume, easy-to-check task, such as summarising reports or checking applications for completeness, where a person approves every outcome before it leaves the department.