AI-enabled interfaces that interact with citizens and public servants — invoking DPI Workflows, not acting autonomously. Constrained, accountable, and governed by design.
A Public Agent is an AI-enabled assistant — software-based, AI-assisted human, or a hybrid of both — that interacts with citizens or officials within defined rights-based boundaries, and activates DPI Workflows to complete tasks.
Use LLM/SLM to understand what a citizen is asking for, in any language, via any channel
Activate pre-approved workflows to deliver services — identity verification, eligibility, benefits, registration
Use foundational blocks (translation, OCR) and sector-specific blocks (eligibility, fraud detection)
Route low-confidence cases, exceptions, and complaints to a human caseworker with a case ID
Send status updates via preferred channel (SMS, WhatsApp, voice)
Every data pull requires a consent token — verified by the workflow, not assumed
Record updates require a governance step in the workflow — the agent cannot write directly to registries
Agents can only activate workflows that have been pre-approved and audited
All decisions above a confidence threshold remain with human authorities
A Public Agent must work for every citizen — including those with limited connectivity or literacy. Channel design is a governance principle, not a technical afterthought.
Primary channel for urban and semi-urban users. Supports text, voice notes, and document submission.
Critical for low-literacy users. speech_to_text() + translate() blocks enable voice in local dialects.
Fallback for feature phones and low-connectivity zones. No data connection required. Async queue.
For users with reliable connectivity. Richer interface, document uploads, case tracking.
Notifications and confirmations. Lowest common denominator for all mobile users.
Assisted mode for citizens without devices. Agent operates through a public servant as intermediary.
A machine-readable spec for a Public Agent, including its model configuration, channels, workflow bindings, and governance constraints.
Public Agents can run on any language model — from large frontier APIs to small on-device models. The choice is not just technical; it has direct implications for sovereignty, cost, latency, and inclusion. Neither type is universally better. Each has a role.
GPT-4o, Claude 3, Gemini 1.5 Pro, Llama 3 70B+
Broad knowledge — handles open-ended queries, complex reasoning, and edge cases with less fine-tuning
Strong multilingual base — reasonable performance across many languages without specialised training
Faster to prototype — good default behaviour out of the box for pilots and demos
Data sovereignty risk — cloud-only APIs send citizen data to third-party servers; requires careful PII handling
High cost at scale — per-token pricing becomes significant across millions of citizen interactions
Latency and connectivity — dependent on reliable internet; unsuitable as primary model for low-connectivity contexts
Unpredictable outputs — larger context windows and generality increase risk of off-scope responses in constrained workflows
Phi-3 Mini, Gemma 2B/7B, Llama 3 8B, Qwen2 1.5B, Mistral 7B
On-premise deployment — runs entirely within government infrastructure; citizen data never leaves the country
Low cost at scale — fixed infrastructure cost; no per-token billing across millions of interactions
Low latency — local inference means fast responses even in constrained network environments
Task-focused fine-tuning — small models specialised on a narrow task (eligibility checking, document extraction) outperform large generalist models on that task
Predictable behaviour — narrower scope means fewer off-topic or hallucinated responses within governed workflow steps
Local language fine-tuning — SLMs can be fine-tuned on local dialect corpora that large model providers do not cover
More upfront investment — requires GPU infrastructure, fine-tuning pipelines, and technical capacity to evaluate and maintain models
Government AI does not need to be brilliant — it needs to be reliable, bounded, and governable. A Public Agent executing a benefits eligibility workflow does not need to discuss philosophy or write poetry. It needs to understand a citizen's request, extract structured fields, call the right workflow step, and escalate when uncertain. A 3–8 billion parameter model fine-tuned on that specific task, running on sovereign infrastructure, is more appropriate than a frontier LLM accessed via a third-party API — and it will be cheaper, faster, and more controllable at the 10 million interactions that matter.
Data stays within national infrastructure. No dependency on foreign API availability, pricing changes, or terms of service. The government owns the model and its outputs.
Smaller models are easier to swap. The DPI Workflow spec declares the model adapter — changing from Llama to Mistral or a locally developed model requires no workflow rebuild.
SLMs can be fine-tuned on Swahili dialects, Amharic, Bahasa, or Kinyarwanda corpora that large providers do not prioritise. Inclusion is a governance imperative, not a feature request.
A model you control can be inspected, re-evaluated, and red-teamed by your own team. Black-box third-party models make it harder to satisfy accountability requirements to citizens and legislatures.
At 5 million citizen interactions per month, per-token API costs become significant budget line items. Fixed infrastructure costs for on-prem SLMs are predictable and decrease per-interaction as usage grows.
SLMs in the 1–3B range can run on commodity hardware, enabling AI-assisted services in district offices without reliable internet — extending the reach of Public Agents to the last mile.
adapter: "ollama", "openai", "vllm"). Start with what you can deploy today — even a cloud LLM for a pilot — and migrate to a sovereign SLM as capacity grows. The workflow does not change. Only the adapter does.
As modular capabilities mature, there is a natural progression toward multi-agent orchestration — multiple agents collaborating by sharing context, coordinating across workflows, and dynamically decomposing complex tasks that a single agent could not achieve alone.
DPI provides the shared digital rails to meet these requirements: common protocols, registries, and governance frameworks that ensure agents and workflows operate securely and transparently. This is how the framework evolves — from single-workflow agents to coordinated, multi-sector service delivery — without sacrificing accountability.
→ See how to build a Public Agent with code or no-code tools
Agents invoke Workflows, which call Blocks. The framework is a stack: Agents at the top, infrastructure at the bottom.