Regulatory disclosure data teams: audit-ready datapoints, no scramble
Going fully agentic and autonomous does not mean letting software write your sustainability report. For regulatory disclosure data teams, it means climbing from agents that assist, to agents that run the routine work under your controls, to a disclosure data back office that largely runs itself: keeping the datapoint inventory mapped to source systems, tying disclosed metrics to the ledger and the operating systems, testing controls and compiling evidence, while named owners keep every conclusion, every disclosed figure and every sign-off. This is what that climb looks like, step by step.
Key takeaways
- •Who this is for. The team that owns the disclosure data behind a sustainability report: the datapoint inventory that comes out of the materiality assessment, the mapping from each datapoint to its source systems, the inputs to digital tagging, and the controls and evidence an assurance provider will ask for.
- •The problem today. The datapoint list lives in a spreadsheet, the mapping lives in people's heads, a renamed field in an HR or energy system silently changes a disclosed number, and when the auditor asks for support on a sample, someone spends two weeks rebuilding it.
- •What changes. Every datapoint is mapped to its source and tied to the ledger or operating system it comes from, source-system changes are traced to the datapoints they touch the day they happen, and evidence for each datapoint is compiled as the work runs, not after the year closes.
- •What stays with your people. Materiality conclusions, methodology choices, estimates, every disclosed figure and every sign-off: the CFO, the sustainability lead and the audit committee own them. Agents map, reconcile, test and compile. They do not conclude, approve or file.
- •The result. A disclosure data team that arrives at the reporting date with a tied datapoint set and an evidence pack, and spends its year improving data quality instead of reconstructing it.
The PRD for agentic regulatory disclosure data teams
This is the requirements document we would write with you for your team. Everything below expands on it.
| Who | Sustainability reporting, regulatory disclosure data, ESG data governance, finance close, internal audit and assurance readiness teams |
| The job | Arrive at the reporting date with every datapoint mapped, tied and supported, whichever framework asks for it. |
| Environment | ERP and general ledger; HR and payroll systems; energy, fleet and facilities data; procurement and supplier portals; a sustainability data or reporting platform; Snowflake, Databricks or BigQuery; dbt; Airflow or Dagster; a digital tagging tool; the evidence repository internal audit and the assurance provider use. |
| Constraints | Materiality conclusions, methodology and estimate choices, disclosed figures and sign-off always go to named owners. Nothing is filed or published by an agent. Evidence must trace to source and be reproducible for an assurance provider. |
| Success is measured by | Datapoint re-mapping after a system change: from about 2 days to ~3 h; auditor sample request answered: from about 2 weeks to ~3 h; comparability check after a boundary change: from about a week to ~2 h; catalog and datapoint documentation upkeep closed autonomously 88% of the time. |
| Owned by | The Head of Sustainability Reporting or the Director of Regulatory Disclosure, with the CFO, the sustainability lead and internal audit as named approvers. |
| Pilot scope | One disclosure topic (for example energy and workforce datapoints) mapped, tied and evidence-packed at L2. |
What going fully agentic and autonomous means for regulatory disclosure data teams
- •Put your disclosure data pipeline on autopilot. A changed field, unit or hierarchy in an HR, energy or finance system is traced to the datapoints it touches the day it happens, so a Friday system change never becomes a wrong number in the annual report.
- •Run the disclosure back office without the busywork. The work that fills the year today moves to agents: refreshing the datapoint-to-source mapping, tying metrics to the ledger and operating systems, rerunning control tests and assembling evidence for sample requests.
- •Scale disclosure without scaling headcount. A new framework, a new jurisdiction or a wider reporting boundary adds datapoints, not a new spreadsheet and a new project team. The same inventory serves every framework that asks for the same fact.
- •Get the plumbing off your plate. A team that spends the year on data quality, methodology and the story the numbers tell, not on rebuilding support for last quarter.
Who this is for
The team that sits between sustainability, finance close and internal audit. At a listed group preparing a sustainability statement under the EU's CSRD and the ESRS, it is the data side of the reporting team: the people who hold the datapoint inventory that came out of the double materiality assessment and make sure each datapoint has a source, an owner, a method and a control. At a group with investors or lenders who expect ISSB-aligned reporting (IFRS S1 and S2), it is the same team answering a second set of questions from the same data. At a company with California exposure, it also feeds the emissions and climate-risk reports the California laws describe.
The titles: Head of Sustainability Reporting, Director of Regulatory Disclosure, ESG Data Governance Lead, Sustainability Controller, Head of Sustainability Data, and the finance, internal audit and assurance-readiness leads who work with them. They answer to a CFO, a Chief Sustainability Officer and, ultimately, an audit committee, and they work in the same quarter-end rhythm as finance, with a harder evidence standard than most of the business has ever applied to this data.
For the data upstream of this team, see the sibling playbook for climate and sustainability data teams, which owns emissions, energy and supplier data. This playbook starts where the datapoint inventory begins. For the wider group of ESG teams, see the ESG and sustainability data teams landing page.
The rules keep moving; the datapoint inventory has to cope
Sustainability disclosure rules changed more in 2025 and 2026 than in the five years before. We do not state thresholds, dates or scopes here, because they will be out of date before you read them. What we can say is what you should confirm with your advisers for each regime, and why a data team should build for change rather than for one version of one rule.
- •EU CSRD and ESRS. The EU adopted a stop-the-clock directive in April 2025 that postponed the first reporting year for companies in the second and third waves by two years, and the Commission and EFRAG have been simplifying both the scope of the directive and the standards themselves. Check the current scope, the current ESRS datapoint set and the current assurance level with your advisers. The European Commission's CSRD page and EFRAG's sustainability reporting page are the places to start.
- •ISSB, IFRS S1 and S2. The standards are issued and a growing number of jurisdictions have adopted them or are building them into local rules. Which one applies to you depends on where you list, borrow and operate. The IFRS Foundation's page for IFRS S2 is the source for the standard itself.
- •California SB 253 and SB 261. SB 253 covers emissions reporting and SB 261 covers climate-related financial risk reports. The state's regulator has been setting the first reporting deadlines, and enforcement of SB 261 was paused by a federal appeals court pending litigation. Check the current status with counsel, starting from the California Air Resources Board program page.
- •The SEC climate rule. The SEC's 2024 climate disclosure rule is not a current planning basis: it was stayed, the SEC stopped defending it, and the Commission has moved to rescind it. Treat any plan that depends on it as needing a fresh check with counsel.
- •Other jurisdictions. More countries are writing their own climate and sustainability disclosure rules, mostly aligned to ISSB, some to the ESRS. Check each jurisdiction where you have reporting entities.
For the data team the practical consequence is the same whichever way each of these lands. Your datapoints get added, removed and renamed; the boundary of who reports changes; a datapoint that was voluntary becomes mandatory somewhere. A team that maintains the inventory by hand re-does that work every time. A team whose inventory is mapped to source, tested and versioned absorbs it as a change request.
The product you ship
- •The datapoint inventory: every disclosure requirement that survived the materiality assessment, with its definition, unit, period, owner and the framework paragraphs it answers, as a governed data product.
- •The datapoint-to-source mapping: for each datapoint, the systems, tables, extracts and manual inputs it comes from, the calculation, and the control that proves it.
- •Boundary and comparability data: the reporting entities and consolidation scope for each period, so prior-year figures can be restated on the new boundary and compared.
- •Connected information: the links between sustainability datapoints and the financial statements (capital expenditure, revenue exposure, provisions) that finance and the auditors need to see agree.
- •Tagging inputs: each datapoint carries the unit, period, entity and context your digital tagging tool needs, so tagging is a mapping exercise and not a data-cleanup project.
- •The controls and the evidence: the control matrix for the disclosure data, the results of each test and the evidence pack for each sampled datapoint, ready for internal audit and the assurance provider.
Where the week goes
- •The inventory drifts from the systems. The materiality assessment produces a list. The systems keep changing underneath it, and the list does not know.
- •Fields and units change without warning. An HR system upgrade renames headcount fields; a utility portal switches kilowatt-hours to megawatt-hours at two sites; a plant is reclassified in the cost-centre tree.
- •Tie-outs are manual and late. Headcount to payroll, energy to invoices, capital expenditure to the fixed-asset register: each is a spreadsheet, run once, in the last week.
- •Boundaries and methods change. An acquisition, a divestment or a methodology update means restating prior years, and the comparison breaks if the old and new versions are not kept side by side.
- •Evidence is assembled after the fact. The auditor selects a sample, and the team rebuilds the trail from emails, extracts and screenshots.
- •Frameworks multiply. Each framework asks for overlapping facts in slightly different forms, and each gets its own spreadsheet.
- •Access is sensitive. Draft figures before publication are material, non-public information, and the auditor needs access to support without access to everything.
Add it up and rework and evidence assembly are most of the team's year. Here is how a typical week splits today, and once agents own the back office:

Time spent on new data products and better coverage moves from 12% of the week to 38%. A good part of the rest becomes review: people steer, challenge and approve agent work instead of doing it by hand.
Then and now
| Work | Today | With Data Workers |
|---|---|---|
| Datapoint inventory | A spreadsheet that ages | Mapped to source, versioned, current |
| Source-system changes | Found when a number looks wrong | Traced to affected datapoints the day they happen |
| Tie-outs | Run once, near the deadline | Run daily and kept as evidence |
| Boundary changes | Prior years overwritten | Versioned, prior periods restated side by side |
| Auditor sample requests | Weeks of rebuilding support | Compiled from the record, reviewed, released |
| Draft figure access | Shared in files and email | Role-scoped, time-boxed, logged |
These are the impact metrics we work toward for regulatory disclosure data teams:
- •Datapoint re-mapping after a system change: from about 2 days to ~3 h
- •Auditor sample request answered: from about 2 weeks to ~3 h
- •Comparability check after a boundary change: from about a week to ~2 h
Across the routine work in this domain:

The biggest change is the evidence work: it stops being a project that starts when the auditor calls and becomes a by-product of work the agents did anyway. Work that waited in queues finishes in hours, because agents detect, trace and verify in one pass.
Use cases, in depth
The datapoint inventory that follows the systems
Today. The inventory is a spreadsheet owned by one person. The mapping to source is partly written down, partly remembered, and wrong the day after an HR or energy system changes.
With Data Workers. The Schema Evolution agent catches the renamed field or changed unit, the Data Context & Catalog agent lists every datapoint the change touches, the Quality Monitoring agent re-ties each to source and the Data Access & Governance agent holds the mapping change for the data lead. The full workflow is described in the CSRD and ISSB disclosure data use case.
What changes. The inventory is true between reporting dates, not only on them.

An auditor's sample request answered from the record
Today. The assurance provider selects forty datapoints. The team spends two weeks finding extracts, re-running queries, taking screenshots and explaining why this year's number does not equal last year's method.
With Data Workers. The Data Context & Catalog agent traces each sampled datapoint to its source systems, the Quality Monitoring agent attaches the latest tie-out and test results, the Observability agent pulls who changed what and who approved it, and the Data Access & Governance agent compiles the evidence pack for a person to review before release. See audit-ready sustainability reporting and the broader audit evidence on demand transformation.
What changes. Assurance is a review of evidence that already exists, not a search for it.

A reporting boundary change without a broken comparison
Today. An acquisition closes in the third quarter. Someone overwrites the entity list, and the prior-year comparison no longer ties to what was published.
With Data Workers. The Pipeline Building agent keeps the old and new boundary as versions side by side, the Quality Monitoring agent proves the published prior-year figures still reproduce under the old version, and the Data Context Wizard updates the governed definition of the reporting boundary with its provenance. The sustainability lead approves the restated comparatives, with the full diff.
What changes. Comparability is a property of the data, not a spreadsheet someone defends in January.
For the supplier and emissions inputs that feed these datapoints, see scope emissions data and supplier ESG data.
For finance, internal audit and the audit committee
The disclosure data team is judged by the people who rely on its numbers: finance, who need sustainability datapoints to agree with the financial statements; internal audit, who test the controls; and the audit committee, who oversee the process. The same record serves all three. The tie-out results show finance where the datapoints agree with the ledger. The control test history shows internal audit what ran, when and with what result. The approval trail shows the audit committee who decided what. Finance teams who already run month-end close on agent-compiled tie-outs will recognise the pattern; this extends it to the data behind the sustainability statement. The companion use cases on audit and controls data and regulatory reporting describe the finance-side equivalents, and the risk and regulatory reporting data playbook covers the sister team at banks and insurers.
Agents working together: the year-end close

Every disclosure data team knows the weeks before the annual report. Source systems are upgraded in the same quarter that the reporting boundary changes, finance reclassifies cost centres, and the draft datapoint set is due to internal audit before anyone has had time to check it. This is the same morning run by Data Workers.
The setup
The group reports a sustainability statement with about two hundred datapoints in scope after its materiality assessment. The data lives in an ERP and general ledger, an HR and payroll system, utility and energy feeds from sites, a fixed-asset register and a supplier portal. It lands in a warehouse, is modelled in dbt and orchestrated by Airflow, and feeds the sustainability reporting platform, the digital tagging tool and the evidence repository internal audit uses. Autonomy in Autopilot:
- •Documentation upkeep, mapping changes to staging and source-system change detection: L2 today; a candidate for L3 on evidence.
- •Datapoint-to-source mapping changes, tie-outs that feed a disclosed figure, boundary versions: L2, held for the sustainability data lead.
- •Materiality conclusions, methodology and estimate choices, disclosed figures, sign-off: L0, with people.
The team scheduled one mission a week earlier: "Re-tie the disclosure datapoints after the HR and energy system changes, and refresh the evidence."
06:00: the loads arrive
The overnight loads from the HR system, the site energy feeds and the ERP land. The HR system upgrade over the weekend renamed two headcount fields. A utility portal has switched one site's energy feed from kilowatt-hours to megawatt-hours. Finance has moved a plant to a different cost centre.
06:03: spot the changes
Connectors agent confirms every source load completed and reports one site feed as late.
Schema Evolution agent detects the renamed HR fields and the changed unit on the energy feed, and says what made each change.
06:10: find what they touch
Data Context & Catalog agent runs a blast-radius analysis from the changed fields into the datapoint inventory: nine datapoints across the workforce and climate topics depend on them, and one connects to the financial statements through the cost centre change.
06:25: propose the mapping
Pipeline Building agent drafts the updated staging models for the renamed fields and the unit conversion, with tests that prove last quarter's published figures still reproduce.
06:40: prove it ties
Quality Monitoring agent runs the checks the team relies on:
- •Headcount ties to payroll within the agreed tolerance, under the new field names.
- •Energy by site ties to invoices in the ledger, except for one site.
- •The cost centre move does not change the total for the reporting entity.
06:55: explain the break
Incident Debugging agent traces the one site's energy variance to the unit change: the feed switched to megawatt-hours while the model still reads kilowatt-hours, a thousand-fold difference. It proposes the correction and lists the affected periods.
07:15: protect the draft
Data Access & Governance agent checks that the evidence workspace is role-scoped, so the assurance provider sees support for the sampled datapoints and not the draft figures for everything else. Every access grant and revoke is logged.
07:30: update meaning, then verify
Data Context Wizard updates the governed definitions of the affected datapoints with the new source fields and a note of the change, with provenance. Autonomous Data-Conductor checks the outcomes: the nine datapoints re-tie, the prior-year figures reproduce under the old mapping, and the evidence pack for the nine is refreshed. Because mapping changes and tie-outs that feed a disclosed figure sit at L2, Conductor sends one decision to the sustainability data lead: the full diff, the tie-out results and the one site correction.
08:10: approved
The sustainability data lead approves the mapping and the unit fix and asks for the energy variance note to go to the sustainability controller. Conductor applies the change and publishes. No datapoint value is changed by an agent: the corrected feed flows through the same calculation, and the disclosed figure remains the sustainability lead's to confirm.
09:00: internal audit opens the pack
Internal audit receives the refreshed evidence for the nine datapoints with the change record, the tie-out results and the approval. Nobody files a ticket.
What stays behind
- •Versioned mapping with tests, so last year's figures reproduce under last year's method.
- •A signed record of every change: who proposed it, who approved it and how to roll it back.
- •Updated Spellbook Data Catalog pages for every affected datapoint and source.
- •A reusable mission. Next quarter's system change runs the same way, and the team can move more of the routine work to L3.
Minute by minute
This is an illustrative example. The datapoint set lives in a warehouse modelled in dbt under Airflow; the sustainability platform, the tagging tool and the evidence repository read from it. Mapping changes and tie-outs that feed a disclosed figure are at L2.
| Time | Who | What happens |
|---|---|---|
| 06:00 | Source systems | HR, energy and ERP loads land after weekend changes |
| 06:03 | Schema Evolution agent | detect_schema_change finds two renamed fields and one unit change |
| 06:10 | Data Context & Catalog agent | blast_radius_analysis lists nine affected datapoints |
| 06:25 | Pipeline Building agent | generate_pipeline drafts the remapping with parity tests |
| 06:40 | Quality Monitoring agent | run_quality_check ties headcount and energy to source |
| 06:55 | Incident Debugging agent | get_root_cause traces one site to a unit mix-up |
| 07:15 | Data Access & Governance agent | check_policy confirms the evidence workspace scope |
| 07:30 | Spellbook Data Catalog | Mapping change held at L2 with the full diff |
| 08:10 | Spellbook Data Catalog | Sustainability data lead approves |
| 09:00 | Internal audit | Refreshed evidence for nine datapoints is ready to review |
The agents on the job
| Agent | What it does on disclosure data | Tools it calls |
|---|---|---|
| Connectors and Data Ingestion | Land ERP, HR, energy, fixed-asset, supplier and platform feeds and confirm every load | get_connector_status, get_dbt_run_history, get_dbt_test_results |
| Schema Evolution | Detects renamed fields, changed units and new codes in source systems and maps them in | detect_schema_change, assess_impact, check_compatibility, generate_migration |
| Pipeline Building | Builds and versions the mapping, boundary and calculation models in dbt, with tests | generate_pipeline, validate_pipeline |
| Quality Monitoring | Ties each disclosed metric to the ledger or operating system and keeps the results | run_quality_check, get_anomalies, set_sla, create_quality_tests_for_pipeline, get_quality_summary |
| Incident Debugging | Traces a variance in a disclosed metric to the change that caused it | diagnose_incident, get_root_cause |
| Data Access & Governance | Scopes and logs access to draft figures and evidence, and compiles the evidence report | check_policy, provision_access, request_governance_review, generate_audit_report |
| Data Context & Catalog | Keeps the inventory documented with owner, lineage and consumers, and finds what a change touches | trace_cross_platform_lineage, blast_radius_analysis, define_business_rule, generate_documentation |
| Observability | Provides the audit trail of what agents and people changed | get_audit_trail |
Data Context Wizard holds one governed definition of each datapoint, each unit and each reporting boundary. The sustainability platform, the dashboards and every agent answer from the same definitions, so the number in the report, the number in the model and the number in the evidence pack never disagree. Autonomous Data-Conductor verifies the numbers that matter before they go to internal audit. Spellbook Data Catalog makes each datapoint and its sources discoverable in plain English for reporting, finance and audit.
What goes on autopilot
Once a domain has earned it, this work runs on its own, and each item removes a problem your team deals with today:
- •Source-system changes are traced to the datapoints they touch the day they happen, so a renamed field never becomes a wrong disclosed number.
- •Disclosed metrics are tied to the ledger and operating systems every day, so the support exists before anyone asks for it.
- •Control tests run on schedule and keep their results, so internal audit reviews history instead of asking for a rerun.
- •Documentation for each datapoint and source stays current, so the next person to inherit the inventory is not starting from a conversation.
Where your people stay in charge
Agents never get blanket access. Each domain has its own autonomy level, set by you, and it only rises when the receipts show the agents are reliable. Everything starts at L1, observing only; reversible upkeep such as documentation, staging fixes and reruns is usually first to run on its own.
- •Materiality conclusions and the double materiality assessment stay with the sustainability lead and the people who ran it. Agents can show which datapoints depend on a conclusion; they do not draw one.
- •Methodology, estimates and judgements stay with named owners. The agents show the inputs and the sensitivity; they do not choose the method.
- •Disclosed figures are confirmed by the sustainability lead and the CFO before anything is published. Agents prepare and tie; they do not publish.
- •Sign-off, assurance engagement and filing stay with the audit committee, the CFO and the people who file.
Once a deployment has matured, here is how that ladder plays out across task classes:

Datapoint documentation upkeep closes autonomously 88% of the time. For materiality conclusions and sign-off, autonomous closure is 0% by design: agents support the decision with evidence and a named person makes it.
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.
- •L3 and L4 are where a domain can go next, on its own review record: acting on its own, with a rollback point on every change. Only the domain's owner raises its level, and if people start reverting the agents' changes, the domain pauses itself.
- •No agent approves or promotes its own work. Autonomy only grows on evidence, per repair class, and repeated errors shrink scope.
- •One org-wide stop halts all autonomous dispatch, and every action lands in a tamper-evident audit trail you can export with
generate_audit_report. - •A wrong mapping is a finding, not a disclosure. Because nothing reaches a disclosed figure without a named approver, an agent error shows up as a rejected proposal or a failed tie-out, not as a number in the report.
How it fits your stack
Data Workers connects to what you already run: your ERP and general ledger; HR and payroll systems; energy and facilities data; supplier portals; Snowflake, Databricks or BigQuery; dbt; Airflow or Dagster; and the sustainability reporting platform and tagging tool you chose. Each agent is an MCP server, so the same agents work inside Claude Code, Cursor or Codex and in Slack through Spellbook. Nothing migrates.
- •Runs in your environment with your credentials and your model key, in your cloud, your VPC or on-premises on the Enterprise tier. The hosted Autonomous Data-Conductor sees workflow metadata only, never rows.
- •Alongside your reporting platform. The platform holds the disclosure workflow, the framework library and the narrative. Data Workers keeps the data under it mapped, tied and supported. Your catalog stays the system of record if you already run one; Data Workers reads from it and adds what it does not hold.
- •Uses the access you already govern. Agents act under scoped service identities and your existing roles; every grant goes through
provision_accessand 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.
- •Tagging stays in your tagging tool. The agents prepare the unit, period, entity and context for each datapoint; the tagging and the filing remain with your tool and your people.
- •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.
Governance and regulation
Sustainability disclosure is a regulated output, so the controls around the data matter as much as the data. Data Workers keeps access to draft figures role-scoped with check_policy and provision_access, holds every mapping change that feeds a disclosed figure for a named approver, and records every change in a tamper-evident audit trail. For how that audit trail is built to be read, see audit trail requirements for autonomous data agents; for the lineage side, see data lineage for compliance and automated data lineage. The post on how Data Workers helps with SOX, GDPR and the EU AI Act covers the wider control story.
Data Workers doesn't make you compliant with CSRD, ESRS, ISSB, California law or any other regime; your controls, people, advisers and assessors do. It supplies controls and evidence wherever agents touch data. Scope, timelines and assurance levels change; confirm the current position for each regime with your advisers. Not legal advice.
The alternatives regulatory disclosure data teams weigh
Build it yourselves. A strong data 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.
Sustainability reporting platforms. They hold the disclosure workflow, the framework library, the narrative and the collaboration between owners. They do not own your HR, energy, ERP and supplier systems, and they depend on the data arriving mapped and tied. Data Workers sits under them and keeps that data correct.
Spreadsheets and consultants. Consultants can build the first inventory and the first mapping. The maintenance is the part that does not scale, because every system change and every boundary change reopens it.
Warehouse-native and observability tools. Observability tools alert, warehouse-native agents help inside one platform, and quality tools test. This work crosses source systems, orchestration, warehouse and reporting platform. Data Workers takes their signals, diagnoses, proposes the fix, verifies it and leaves the receipt. See also the best practices for agentic regulatory disclosure data.
The case for your CTO and CFO
What this replaces. A spreadsheet inventory, hand-maintained mapping, tie-outs run once a year and a two-week scramble every time an auditor selects a sample.
What your team gets back. A disclosure data team that spends its year on data quality, methodology and coverage instead of rebuilding support.
Integration effort. Connecting is configuration, not a migration. The agents attach over MCP to the warehouse, orchestrator, dbt project and source systems you already run, under the roles you already govern, inside your own environment. Your engineers can read every tool the agents call in the open-source core.
Risk and control. Autonomy is set per domain. Everything starts at L1, observing only; reversible work moves up only when the receipts justify it; anything that feeds a disclosed figure stays at L2 with a named approver; conclusions and sign-off stay with people; and one org-wide stop halts all autonomous work.
Why now. The rules are changing in scope and timing, assurance expectations are rising, and the same data has to serve more than one framework. A mapped, tested, evidence-ready inventory absorbs each change; a spreadsheet pays for each one again.
The first win. One disclosure topic mapped, tied and evidence-packed 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, and that the hard part of data work was never knowing what to do but doing it. For regulatory disclosure data teams, the climb looks like this:
- •Assisted. Agents work alongside your team. They read the whole stack, map datapoints to source, show what needs doing and propose every fix with a receipt; anything that feeds a disclosed figure goes to a named approver.
- •Autonomous, under your governance. Routine work runs on its own: source-system changes are traced to the datapoints they touch, disclosed metrics are tied to the ledger and operating systems every day, and control tests and evidence run on schedule. Your team governs the agents instead of doing the upkeep.
- •The agentic enterprise. A disclosure data team that arrives at every reporting date with a tied datapoint set and an evidence pack. People set direction, make the judgements and sign; the platform carries out the rest.
You choose the altitude, every step is visible and reversible, and the pilot below is the first rung.
The pilot: how regulatory disclosure data teams start
The pilot is how your team proves the value on its own data before committing.
- •What we connect. Your ERP and general ledger, HR and payroll, energy and facilities data, the warehouse, dbt and the orchestrator, over MCP, inside your environment. Nothing migrates.
- •Scope. One disclosure topic (for example energy and workforce datapoints) mapped, tied and evidence-packed at L2.
- •First week. Agents run at L1 across the scoped domain. They map every pipeline, definition and lineage path from datapoint to source and show the fixes they would have made, with receipts, so your team sees the value before anything changes.
- •By week two. Source-system change tracing, daily tie-outs and datapoint documentation start running on reversible work. Mapping changes and anything that feeds a disclosed figure stay at L2 with a named approver.
- •At day 30. We review the impact metrics against your baseline:
- •Datapoint re-mapping after a system change: from about 2 days to ~3 h
- •Auditor sample request answered: from about 2 weeks to ~3 h
- •Comparability check after a boundary change: from about a week to ~2 h
- •the share of catalog and datapoint documentation upkeep closed autonomously, targeting 88% as the deployment matures
- •What you decide. Whether to expand to the next disclosure topic or framework. 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.
The pilot is the start of a longer curve:

By month 12, more than 38% of agent actions run fully autonomously and manual work falls below 10%, while disclosed figures, conclusions and sign-off stay with named owners.
FAQ
Does Data Workers prepare the sustainability report? No. It keeps the data under the report mapped, tied and supported. The report, its conclusions and its sign-off stay with your reporting team, the CFO and the audit committee.
Does it work for CSRD, ISSB and California at once? The datapoint inventory is built around facts and their sources, so one fact can serve every framework that asks for it. Which frameworks apply to you, and when, is a question for your advisers.
Can it do the XBRL or digital tagging? It prepares the inputs: unit, period, entity and context for each datapoint, checked against source. The tagging and filing stay in your tagging tool.
Will an agent ever change a disclosed number? No. Anything that feeds a disclosed figure is proposed with a full diff and approved by a named person, and the figure itself is confirmed by the people who own it.
Does it replace our sustainability reporting platform? No. It sits under it and keeps the source data correct. For the upstream emissions and supplier data, see the climate and sustainability data playbook.
Where do the agents run? In your environment, with your credentials and model key. The hosted Conductor sees workflow metadata only.
Do we have to migrate anything? No. Your ERP, warehouse, dbt project, orchestrator, catalog and reporting platform stay where they are.
Sources
- •Data Workers pricing: https://dataworkers.io/pricing/
- •European Commission, corporate sustainability reporting (CSRD): https://finance.ec.europa.eu/capital-markets-union-and-financial-markets/company-reporting-and-auditing/company-reporting/corporate-sustainability-reporting_en
- •EFRAG, sustainability reporting (ESRS): https://www.efrag.org/en/sustainability-reporting
- •IFRS Foundation, IFRS S2 Climate-related Disclosures: https://www.ifrs.org/issued-standards/ifrs-sustainability-standards-navigator/ifrs-s2-climate-related-disclosures/
- •California Air Resources Board, corporate GHG reporting and climate-related financial risk program: https://ww2.arb.ca.gov/our-work/programs/california-corporate-greenhouse-gas-ghg-reporting-and-climate-related-financial-risk