How government data teams go fully agentic and autonomous
Going fully agentic and autonomous does not mean adding a chatbot to the warehouse. For government data teams, it means climbing from agents that assist, to agents that run the routine work under your governance, to a data back office that largely runs itself: building and fixing pipelines, catching bad data before it reaches a number, keeping definitions and access governed and verifying every outcome, while people set direction and approve what matters. This is what that climb looks like, step by step.
Key takeaways
- •Who this is for. Data leaders and teams at government agencies and their delivery partners.
- •The problem today. Most of the data team's week goes to hand-assembled releases and per-file privacy review.
- •What changes. Specialised agents take that work over across the systems you already run: they catch bad data where it enters, fix it where it lives and verify the number before anyone reads it.
- •What stays with your people. Anything regulated or customer-facing waits for a named approver with the full diff, blast radius and rollback plan in front of them.
- •The result. Data teams that spend their time on more releases, on time.
The PRD for agentic data in public sector
This is the requirements document we would write with you. Everything below expands on it.
| Who | Data leaders and teams at government agencies and their delivery partners. |
| The job | Program data released on time, private and traceable. |
| Environment | Government cloud environments; Databricks or Snowflake; SAS and legacy systems; open data portals; analytics for public websites, and the other platforms your teams run. |
| Constraints | Regulated and customer-facing numbers always go to a named approver; agents run in your infrastructure under the roles you already govern. |
| Success is measured by | Access decision: from about 2 weeks to ~1 h; Documentation: from about a week to ~1 h; Partner layout mapped: from about 3 days to under 1 h; documentation closed autonomously 88% of the time. |
| Owned by | The head of data or CDO, with domain owners as named approvers. |
| Pilot scope | One monthly release at L2. |
What going fully agentic and autonomous means in public sector
- •Put your data pipelines on autopilot. Agents catch bad data where it enters, fix it where it lives and verify the number before anyone reads it.
- •Run the data back office without the busywork. The week that goes to hand-assembled releases and per-file privacy review moves to agents.
- •Scale data without scaling headcount. New sources, partners and data products are onboarded as missions, not projects.
- •Get the plumbing off your plate. Data teams spend their time on more releases, on time.
The shift
Agency chief data offices own release policy for program data, open data and web analytics, often working through contractors and digital-service teams. Every release needs profiling, de-identification and documentation.
Our view: agents should do the repeatable release work inside the agency's environment, with program leads approving every release.
A day on a public sector data team today
A state partner changes its file layout and the monthly release slips a month. A research request waits in a queue. Documentation for last quarter's release is still a draft.
That week is typical, not exceptional. Here is where the time goes, today and with agents on the back office:
Then and now
| Work | Today | With Data Workers |
|---|---|---|
| Releases | Assembled by hand | Missions with checks |
| De-identification | Per-file review | Rules with exceptions |
| Partner files | Broken loads | Mapped on arrival |
| Documentation | Lags | Generated |
| Access | Queues | By agreement |
These are the impact metrics we move:
- •Access decision: from about 2 weeks to ~1 h
- •Documentation: from about a week to ~1 h
- •Partner layout mapped: from about 3 days to under 1 h
Across the routine work:
Use cases, in depth
Monthly releases on time
Today. Analysts assemble and check each release.
With Data Workers. Autopilot runs it with quality, threshold and documentation checks.
What changes. Releases ship on schedule. Read the playbook.
Program data ready for ML
Today. A program wants claims data ready for ML.
With Data Workers. Profiling, de-identification and documentation run as a mission.
What changes. Data is ML-ready in weeks. Read the playbook.
Partner layout changes absorbed
Today. A state system changes its file layout.
With Data Workers. Schema Evolution maps it with tests.
What changes. No broken loads. Read the playbook.
Agents working together: A partner state file that changed layout
Minute by minute
Illustrative example. State files land in a government cloud; releases publish monthly.
| Time | Who | What happens |
|---|---|---|
| Day 2 | State partner | File in new layout |
| Day 2 | Quality Monitoring agent | Layout mapped; totals tie |
| Day 3 | Spellbook Data Catalog | Lead approves |
| Day 5 | Portal | Release published |
How it fits your stack
Data Workers connects to what you already run: Government cloud environments; Databricks or Snowflake; SAS and legacy systems; open data portals; analytics for public websites. Each agent is an MCP server, so the same agents work inside Claude Code, Cursor or Codex and in Slack or Teams through Spellbook. Nothing migrates.
- •Runs in your infrastructure with your credentials and your model key. The hosted Autonomous Data-Conductor sees workflow metadata only, never rows.
- •Uses the access you already govern. Agents act under scoped service identities and your existing roles; every grant goes through provision_access and is logged.
- •Proposes changes as diffs in your dbt project, orchestrator and warehouse, with blast radius, tests and a rollback point, and applies them only at the autonomy level you set for that domain.
- •Open-source core. The Apache-2.0 community edition ships 11 agents and 160+ MCP tools, so your engineers can read exactly what the agents call.
How autonomy expands over the first year
Autonomy is earned per task class. In a mature deployment, it looks like this:
A typical path: month 1 at L1 everywhere; months 2 to 3, L3 and L4 on reversible upkeep; months 4 to 6, new data products built by the swarm; months 6 to 12, wider autonomy where the evidence supports it, with regulated or customer-facing numbers kept at L2.
What happens when an agent is wrong
- •At L2 propose, nothing changes until a named person approves. The proposal shows the full diff, the blast radius and how to roll it back. Unanswered requests expire and escalate.
- •At L3 act, reversibly, every change keeps a rollback point, and Conductor verifies the downstream number after the change. If verification fails, the change is reversed and the domain drops a level.
- •No agent approves or promotes its own work. Autonomy only grows on evidence, per repair class, and repeated errors shrink scope automatically.
- •One org-wide stop halts all autonomous dispatch, and every action lands in a hash-chained audit trail you can export with generate_audit_report.
Governance and regulation
Agencies must protect personal data and document releases. Agents run in the agency's environment and log every action.
Data Workers doesn't make you compliant; your controls, people and assessors do. It supplies controls and evidence wherever agents touch data. Not legal advice.
The alternatives public sector data teams weigh
Build it yourselves. A strong team can wire a coding agent to MCP servers for the warehouse and dbt. The work is everything around it: routing approvals to the right owner, blast radius, rollback, receipts, and current context about every other system.
Observability, catalogs and point tools. Observability alerts, catalogs document, and quality tools test. Data Workers takes their signals, diagnoses, proposes the fix, verifies it and leaves the receipt.
Platform-native agents. Snowflake made its managed MCP server and Cortex Agents generally available on Nov 4, 2025, and Databricks made Genie One generally available on Jun 16, 2026. They are excellent inside their platform; this work crosses the source systems, orchestrator, warehouse and BI, and Data Workers works across all of them.
In this space specifically. Open data portals publish; Data Workers prepares, checks and documents what they publish.
The case for your CTO
What this replaces. The week spent on hand-assembled releases and per-file privacy review.
What your teams get back. Time for more releases, on time, on data that is verified before anyone reads it.
Integration effort. Connecting is configuration, not a migration. The agents attach over MCP to the platforms you already run, under the roles you already govern, inside your own infrastructure.
Risk and control. Autonomy is set per domain, starts at L1 and rises only on evidence. Regulated and customer-facing numbers stay at L2 with a named approver, and one org-wide stop halts all autonomous work.
Why now. AI mandates and transparency rules raise volume.
The first win. One monthly release at L2. The pilot below lays out the scope, what you see each week and the cost.
The climb: from assisted to autonomous to agentic
Our thesis is that the data platform climbs the way analytics did, in stages. In public sector, that climb looks like this:
- •Assisted. Agents work alongside each data team, read the whole stack and propose every fix with a receipt. Regulated and customer-facing numbers always go to a named approver.
- •Autonomous, under your governance. The upkeep behind hand-assembled releases and per-file privacy review runs on its own, domain by domain, as the receipts earn it.
- •The agentic enterprise. The platform largely runs itself. People set direction and standards, and the teams spend their time on more releases, on time.
You choose the altitude, every step is visible and reversible, and the pilot below is the first rung.
The pilot: how public sector data teams start
The pilot is how a team proves the value on its own data before committing.
- •What we connect. Government cloud environments; Databricks or Snowflake; SAS and legacy systems; open data portals; analytics for public websites, over MCP, inside your infrastructure. Nothing migrates.
- •Scope. One monthly release at L2.
- •First week. Agents run at L1 and show the fixes they would have made, with receipts.
- •By week two. Reversible upkeep (reruns, staging fixes, documentation, cleanup) runs on its own; regulated and customer-facing numbers stay at L2 with a named approver.
- •At day 30. We review the impact metrics against your baseline:
- •Access decision: from about 2 weeks to ~1 h
- •Documentation: from about a week to ~1 h
- •Partner layout mapped: from about 3 days to under 1 h
- •the share of documentation closed autonomously, targeting 88%
- •What you decide. Which domain or team goes next. The pilot fee is credited in full against the first year.
- •Cost. Start with a pilot ($7,500 one-time, credited in full against the first year). Scale is from $1,000 a month and Enterprise from $3,000 a month, billed annually, with unlimited seats, no usage meter and no markup on model spend. See pricing.
Use-case guides
- •Program oversight data: Oversight reports run on current, documented data.
- •Budget and expenditure data: Budget execution is visible daily.
- •Constituent operations data: Service levels are measured, not estimated.
- •Grants management data: Grant monitoring catches issues while they can still be fixed.
- •Fraud, waste and abuse data: Investigators get leads built on verified data.
Teams we work with in public sector
FAQ
Can it run in a government cloud? Agents run in your environment.
Who approves releases? A named program lead.
Does it handle legacy systems? Through extracts and partner files.
Where do the agents run? In your infrastructure, with your credentials and model key. The hosted Conductor sees workflow metadata only.
Do we have to migrate anything? No. Your warehouse, dbt project, orchestrator, catalog and BI stay where they are.
Sources
- •USAJOBS, CMS Office of Enterprise Data and Analytics: https://www.usajobs.gov/job/483258500
- •Data Workers pricing: https://dataworkers.io/pricing/
- •Data Workers open-source repository (tool registrations): https://github.com/DataWorkersProject/dataworkers-claw-community
- •Snowflake, managed MCP server and Cortex Agents GA release note (Nov 4, 2025): https://docs.snowflake.com/en/release-notes/2025/other/2025-11-04-cortex-agents-mcp
- •Databricks, Genie One launch (Jun 16, 2026): https://www.databricks.com/company/newsroom/press-releases/databricks-launches-genie-one-all-new-agentic-coworker-every-team