Public-Sector Agentic Patterns

FlowRidge

The architect’s baseline assumption in public sector is that the agent’s decisions will be scrutinized — by journalists, by ombudspersons, by courts, by civil-society organizations, by affected citizens. The architectural response is not to obscure; it is to design so the agent can be explained end-to-end without awkward surprises.

The regulatory backbone

EU AI Act Article 5 — prohibited uses. Social scoring by public authorities, emotion recognition in law-enforcement workplace or education (narrow exceptions), real-time remote biometric identification in public spaces (narrow exceptions), predictive policing based solely on profiling. Any proposed public-sector agent needs Article 5 review before Calibrate exit.

EU AI Act Annex III — public-sector high-risk. Access to essential private + public services (III.5), migration + border-management (III.7), administration of justice + democratic processes (III.8). Many public-sector agents fall inside Annex III and carry the high-risk conformity-assessment burden (Article 23).

UK Algorithmic Transparency Recording Standard (ATRS). Mandates standardized publication of algorithmic-tool use by UK central government departments. Every departmental algorithmic tool deserves an ATRS record covering purpose, data, training, evaluation, human oversight, and contact.

Administrative-law due-process principles. Most jurisdictions have a common-law or civil-law tradition of procedural fairness in public decisions: the subject must know a decision is being made, know the basis, have an opportunity to respond, and have a route to appeal. Agentic systems do not change these obligations; they complicate satisfying them.

Procurement rules. FedRAMP (US federal cloud use), state IT procurement, UK G-Cloud, EU OJEU thresholds, supplier-of-record obligations. The architect plans the agent’s infrastructure choices around procurement compliance.

FOI / transparency. Freedom of Information obligations may compel disclosure of agentic-system design, decision logic, and decision logs — subject to exemptions. Design with eventual disclosure in mind.

Five sector-specific architecture patterns

Pattern 1 — Transparency and explanation surface

Every citizen-facing agent produces outputs accompanied by explanation surfaces:

What the agent is — named, with its purpose, with the Article 50 disclosure.
What data informed the response — citation to source documents where the agent answers factual questions; reference to source data where the agent uses case-specific information.
How to escalate — named path to a human decision-maker.
How to contest — the formal appeal route if a decision is made against the citizen’s interest.
How to request information — data-subject-access and FOI routes.

Pattern 2 — Appeal and contestability paths

Public-sector agents interact with GDPR Article 22 (automated individual decision-making) and with domestic due-process law. The architect wires contestability into the system rather than into a separate back-office process:

The agent flags any decision-type in Article 22 scope and routes to a human-review path by default.
Where an agent-informed decision stands, the citizen has a named path to contest.
The contest path has service-level targets aligned with the domestic administrative-law timeline.
Contest outcomes are logged and fed into evaluation (Article 17).

Pattern 3 — ATRS-ready documentation

The architect produces ATRS-ready documentation as a design artifact, not a compliance afterthought. ATRS records cover:

Tool purpose and decision type.
Decision-making process (how the tool fits in the human decision flow).
Datasets used (training, retrieval, evaluation).
Impact assessment (risks, mitigations, monitoring).
Human oversight (who supervises, how).
Governance and ownership (team, contact).

Even non-UK deployments benefit from ATRS-style documentation; it is the most concrete public-facing documentation standard at this time.

Pattern 4 — Article 5 prohibited-use screening

A public-sector architect screens every proposed agent against Article 5 at Calibrate. Three failure modes to catch early:

Social-scoring drift. An agent that ranks citizens “for public-authority use” is prohibited under Article 5.
Predictive-policing creep. An agent predicting offence risk solely from profiling is prohibited.
Law-enforcement biometric use. Real-time remote biometric identification is near-prohibited with narrow exceptions.

Agents adjacent to these categories — benefits-fraud detection, security triage, immigration assessment — are often in scope of other high-risk classifications and require careful scoping.

Pattern 5 — Open-source and supplier-neutrality design

Public-sector buyers prefer supplier-neutral architectures because procurement rules require them and because long-term lock-in is politically hazardous. The architect designs with:

Model portability. The agent is designed to run on more than one LLM provider; prompt templates are tuned for the primary but testable on the alternate.
Standard protocols. Tool interfaces use OpenAPI / MCP-style manifests, not vendor-specific shapes.
Framework neutrality. The runtime is LangGraph, Semantic Kernel, or an open-source runtime the buyer can support independently if the supplier changes.
Data portability. Memory stores, retrieval indices, and audit logs are in open formats or exportable.

Documented failure cases

Public-sector AI has a longer documented history of algorithmic-harm than most sectors. Three cases shape the architect’s priors:

NYC MyCity chatbot, wrong-law answers (March 2024, The Markup). A well-resourced government chatbot returned advice to business owners that, if followed, would have caused them to break the law (advising discrimination against tenants on source-of-income grounds, advising against paying the required tipped-minimum wage). The architectural lessons: government-specific content safety requires domain-specific evaluation batteries; off-the-shelf LLMs trained on generic content fail domain-specific accuracy tests; transparency about what the tool can and cannot do is necessary but not sufficient.

Dutch SyRI benefit-fraud algorithmic-harm court ruling (2020, District Court of The Hague). The Hague court halted the Dutch Systeem Risico Indicatie (SyRI) benefit-fraud-detection system for human-rights violations — disproportionate interference with private life under ECHR Article 8, with insufficient safeguards against discriminatory effect. Predates modern agentic systems but is the seminal public-sector algorithmic-harm precedent and shapes EU AI Act high-risk classification.

UK Post Office Horizon / Fujitsu accounting system (1999–2019; Post Office Offences Act 2024). Not an AI system but a public-sector-adjacent algorithmic-harm case at immense scale; sub-postmasters wrongly prosecuted based on system outputs. The architectural lesson that carries forward: systems whose outputs have legal consequences require structural contestability and independent evidentiary review, not just vendor assurance.

Three public-sector use cases, classified

Use case A — Citizen-facing information assistant (generic benefits information).

Regulatory tier: typically not Annex III; subject to Article 5 screen; ATRS-publishable.
Architecture: retrieval-grounded agent; citation in every answer; clear handoff to a human adviser; no decision-making.

Use case B — Benefits-eligibility decisioning agent.

Regulatory tier: Annex III.5 access-to-essential-services high-risk; Article 22 GDPR likely in scope.
Architecture: HITL on adverse decisions; Article 14 evidence pack; contestability path; appeal process SLA-tied; fairness evaluation.

Use case C — Immigration-case-triage agent (support, not decide).

Regulatory tier: Annex III.7 migration high-risk; enhanced fairness and error-analysis requirements; cross-border data rules.
Architecture: human-in-the-loop from the beginning; agent provides research synthesis, not decisions; detailed audit trail; case-specific transparency surface.

Procurement and supplier-neutrality in practice

The supplier-neutrality pattern (Pattern 5) needs concrete expression in procurement. The architect supports the procurement team with:

Statement of Requirements. Framework-neutral statements that specify outcomes and interfaces (OpenAPI, MCP, OpenTelemetry) rather than specific vendors.
Evaluation criteria. Published scoring on portability, exit cost, open-format support; not just feature parity.
Pilot-to-production portability tests. Evidence that the piloted system can run against alternative components; proof-of-concept of framework portability.
FOSS + commercial pairing. Where a commercial product is chosen, the procurement specifies that the product’s data, configurations, and logs remain exportable in open formats.
Sovereignty clauses. Where sovereignty matters (central-government, judicial, national-security-adjacent), procurement specifies processing geography, national-cloud deployment, or self-hosted options.

UK G-Cloud, US FedRAMP, Canada’s Digital Standards, Singapore’s GovTech, and EU Member States’ digital-sovereignty programmes all have evolving positions on agentic AI; the architect tracks these actively.

Open-data and algorithmic-transparency reference

UK ATRS portal (https://www.gov.uk/algorithmic-transparency-records). Public repository of UK central-government algorithmic tools. The architect reads existing entries to calibrate disclosure depth, vocabulary, and structure. ATRS records are a useful concrete anchor when the project lacks a template.

Anti-patterns to reject

“The chatbot is just a convenience; it’s not making decisions.” If citizens rely on its outputs, it is functionally making decisions about their interactions with government. Treat it accordingly.
“We’ll fix the prompt after launch.” Government launches are scrutinized; content safety is a launch-blocker.
“We picked the big model because it’s best.” Supplier neutrality is a public-sector design constraint; single-vendor lock-in may violate procurement rules.
“FOI exemption will cover the model weights.” Perhaps; but design decisions, evaluation reports, and decision logs are not exempt from FOI in many jurisdictions.
“Ombudsperson route is the same as contestability.” An ombudsperson is a downstream remedy; contestability is a structural property of the first-instance system.

Learning outcomes

Explain public-sector agentic constraints — EU AI Act Articles 5 and Annex III, ATRS, administrative-law due process, procurement rules, FOI.
Classify three PS use cases against EU AI Act Annex III and apply the appropriate transparency + contestability pattern to each.
Evaluate a PS design for transparency-surface completeness, contest-path adequacy, supplier-neutrality design, and ATRS-readiness.
Design a PS agentic plan including the Calibrate Article 5 screen, the ATRS documentation, and the citizen-facing transparency + contest surfaces.