How do approvals work in practice?

At L2 propose, a Data Workers agent prepares the change and sends it, with its evidence (what changed and why, the blast radius, the diff, the checks that ran and the rollback path), to the named owner of that data domain, who approves or rejects it in the Spellbook inbox, or on the pull request in GitHub when your team turns on the GitHub pull-request target. The approved change lands through your normal flow, Data Workers verifies the result, and a receipt records who approved it, what changed and how to undo it.

That loop is what Data Workers, the agentic data platform, is built around. Below: each step in the product, one dbt schema change from proposal to receipt, and how coding agents, platform agents and change-management tools handle the same moment.

Key takeaways

• •Every proposal arrives with its evidence. The approver sees the diff, the column-level blast radius across engines and dashboards, the checks that ran and a rollback path recorded before anything runs.
• •Approvals go to a named person in the domain. Rules route each request by action class and domain to a specific user, role or team, the same people who already own that data.
• •People approve where they already work. The Spellbook inbox holds every request in one place; dbt changes arrive as GitHub pull requests once your team turns on the GitHub pull-request target, and go through your branch rules and CI.
• •Unanswered requests expire and escalate. Every request carries a deadline your team sets. Nothing is ever auto-granted because nobody answered.
• •No agent can promote its own work. Promotion to authoritative, Conductor goal approvals, review sign-off and allowlist changes each reject an agent or a self-approver.
• •Every decision leaves a receipt. Approver, diff, checks and rollback path go into a hash-chained audit trail that leadership and auditors can read.

How an approval moves, from proposal to receipt

1. The agent proposes, with evidence. At L2 propose, an agent never applies a governed write directly. It files a proposal that carries what changed and why, the plan, and the evidence an owner needs to say yes quickly. Blast radius comes from blast_radius_analysis, at column level and across engines, down to the dashboards the team records in the context graph; when the fix goes through a pull request, change review's lineage diff adds the dbt exposures. Schema changes are caught from the dbt manifest diff and the pull request, and described with assess_impact. A policy question runs through check_policy before anyone signs. Code changes arrive as a diff for the owner to merge; dbt changes open as a pull request when your team turns on the GitHub pull-request target, with a data review on the PR that compares row counts, schema and values between the old and new builds. Every reversible change records how to undo it before it runs.

2. The request routes by action class and domain. Data Workers sorts every tool into an action class by consequence: reversible enrichment such as descriptions and tags; authoritative assertions such as marking a definition official; changes to the live data stack such as altering a schema, fixing a pipeline or deploying; and the irreversible class, which covers access grants, spending money and deletions. An unclassified tool is treated as a live-stack change, never as enrichment. Your team writes the routing rules on top: which classes need a person in which domain, and who that person is, by user, role or team. The Autonomous Data-Conductor opens autonomy "domain by domain: which agents can write, how far a change may spread, what still comes to a human." Teams set money, access and deletions to wait for a person at every level, and Data Workers holds that floor.

3. A named owner decides where they work. A request is addressed to a specific person, not an anonymous queue. The Spellbook Data Catalog (in preview) gathers everything an agent wants to make official into one inbox, where the owner can "approve it, steer it, send it back, or roll it back after the fact, with the full trace of what the agent saw and why it acted." With the GitHub pull-request target on, dbt changes also live on the pull request in GitHub, where your branch protection, code owners and CI apply exactly as they do for human changes. When one fix spans two clouds, the owner gets a single entry with the full diff across every surface and approves it once.

4. Unanswered requests expire and escalate. Every request is stamped with a deadline when it is filed. Teams set it per rule; the default is one hour. When the deadline passes, the request expires and escalates to the escalation target your team names, and the waiting work stops. A request nobody answered never turns into a yes.

5. No agent can promote its own work. The guard sits in the write path at the four places where an agent could otherwise sign for itself. Promotion to authoritative or canonical (the mark_authoritative tool and graph writes) requires a named human and rejects an agent id or the acting agent. The Conductor rejects an agent-shaped approver when a goal it proposed is activated. A review whose verdict is high risk can be signed off only through a governance review (request_governance_review). Changes to the workspace allowlist reject an agent self-grant. As the Spellbook page puts it: "Nothing becomes official without a signature."

6. The change lands, is verified, and leaves a receipt. An approved change goes through your normal path: the PR merges, CI and the job run. Data Workers then verifies the result: post-checks re-validate the affected assets against their quality and contract assertions, and a fix that does not pass goes back to a person instead of being marked resolved. The receipt goes into a tamper-evident, SHA-256 hash-chained audit trail: who asked, what changed, what was checked, who approved and how to undo it. generate_audit_report assembles those records for a quarter or an auditor, and rollback_migration reverses an applied schema migration and can dry-run the rollback first.

Approvals live at L2 propose, where every governed write waits for a person. At L3 act reversibly, agents apply undoable changes and the owner reviews after the fact; at L4 autonomous, the irreversible class still waits for a person under the rule teams set on day one. The Conductor ships observe-only, and each domain climbs when its owner decides. See autonomy levels from L0 to L4.

A dbt schema change, approved in a pull request: an illustration

Here is one approval end to end, on Postgres, Fivetran, Snowflake, dbt, GitHub, Looker and Spellbook. It is an illustration, not a customer record or a measured result. The orders domain runs schema fixes at L2 propose, and the team's rule gives the domain owner four hours before the request escalates to the platform lead.

The owner steered the change instead of rejecting it, and the evidence updated in place. The approval happened in GitHub under the team's usual code-owner rule. Had she been out, the request would have escalated to the platform lead at 12:32. For the wiring, see Data Workers and dbt.

How other tools handle approval

Every option below is a sensible design for the job it was built to do. The difference is who approves, what they see, and what scope the approval covers.

Coding agents. Claude Code's Manual mode "Prompts for permission on first use of each tool." In auto mode, "a second model, the classifier, reviews actions instead of you," and from v2.1.283 auto mode is the starting mode for interactive terminal and VS Code sessions; administrators can turn it off in managed settings (checked Oct 2, 2026). Cursor's run modes are Auto-review, Allowlist and Run Everything; its docs call Auto-review "the safest useful setup for most people" and add that "Auto-review is not a security boundary." Cursor's PR Routing & Approval assigns reviewers by code ownership and commit history and "can approve low-risk PRs when your criteria are met," while noting it "does not replace a full code review" (checked Oct 2, 2026). These approvals protect a developer's session and a repository, which is the right scope for writing code.

Platform agents. Databricks Genie Code offers Ask every time, Allow in current chat, Always allow and Auto-approve. Its docs say "the default mode for every chat is Auto-approve" on first use, call it "a productivity feature, not a security boundary," advise keeping it off "when working with production data," and say "You remain responsible for reviewing Genie Code's results" (checked Oct 2, 2026). The approver is the person in the chat, inside one platform.

Change-management tools. Jira Service Management adds an approval step to a workflow status, with approvers set per request type, per service or from Change Advisory Board members (checked Oct 2, 2026). GitHub branch protection can require approving reviews, code-owner reviews and approval of the latest push "by someone other than the person who pushed it" (checked Oct 2, 2026). These are strong records of who signed. They rely on the person filing the change to supply the evidence.

Data Workers works with all of them. Coding agents connect to it over MCP and get the same governed context, the pull request stays in GitHub under your branch rules, and a change ticket can carry the receipt. What Data Workers adds is the part a data change needs: the blast radius across systems, routing to the domain that owns the data, a deadline that escalates, verification after the change lands, and one receipt across the whole lifecycle. A team can build that on its own with a coding agent and vendor MCP servers; our build-vs-buy page lays out what that takes.

The guardrails around each approval are covered in is it safe to let AI agents change production data?, the people who approve in who owns the agents, the undo path in how to roll back an AI agent change, and what the hosted Conductor sees in where does our data go?. Our resources on human-in-the-loop approvals, approval workflows for agent-generated SQL and audit trail requirements for data agents go deeper.

The case for your CFO

The outcome is faster data fixes with the same sign-off discipline you already trust. Agents do the triage, tracing, drafting and verification; the owner's job shrinks to reading a complete proposal and saying yes, steer or no. Changes that used to wait for someone to investigate arrive ready to approve.

The risk story is the approval loop itself. Each domain runs at the level its owner sets. Every governed write at L2 waits for a named person, with the diff, blast radius, checks and rollback path attached. Money, access and deletions are set to wait for a person at every level. Requests that sit unanswered expire and escalate; nothing auto-grants. No agent can promote its own work. Every decision leaves a hash-chained receipt naming the approver. Nothing is migrated: dbt, GitHub, Snowflake, Looker and your identity provider stay as they are.

Why now: coding and platform agents are already proposing changes to your data, each approved by whoever is at the keyboard. Routing data changes to the owners of that data, with evidence and a receipt, gives the business one standard before those approvals multiply.

The first win is one domain, such as schema changes or freshness fixes, at L2 propose with a named owner. Start with a pilot: $7,500 one-time, and the pilot is 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, model it in the ROI calculator, and read the ROI of agentic data operations.

The sentence for upstairs: "Every agent change to our data reaches the person who owns that data with the evidence attached, and nothing lands without their name on the receipt."

FAQ

Who approves an agent's change? The named owner your routing rule sets for that domain and action class: a user, a role or a team. For code changes, the pull request also follows your GitHub branch protection and code-owner rules.

What happens if nobody answers? The request expires at its deadline and escalates to the escalation target your team names. The work waits; it is never auto-granted.

Can an agent approve its own change? No agent can promote its own work. Promotion to authoritative, Conductor goal approvals, high-risk review sign-off and allowlist changes each reject an agent or a self-approver, and pull requests follow GitHub's own rules on who may approve.

What does the approver actually see? What changed and why, the column-level blast radius across engines and dashboards, the diff, the tests and policy checks that ran, and the rollback path. In Spellbook the owner also sees the trace of what the agent saw and why it acted.

Can I change or reverse a decision later? Yes. An owner can roll back an approved change from the Spellbook inbox, and the new receipt links to the original so the record shows both.

How does this show up for auditors? Every request, decision and change sits in a tamper-evident audit trail, and generate_audit_report assembles it for a period or a domain.

Sources

• •Databricks, Genie Code agent mode, approval modes and auto-approve: https://docs.databricks.com/aws/en/genie-code/agent-mode (checked Oct 2, 2026)
• •Anthropic, Claude Code permissions: https://code.claude.com/docs/en/permissions (checked Oct 2, 2026)
• •Anthropic, Claude Code permission modes (auto mode starting mode from v2.1.283): https://code.claude.com/docs/en/permission-modes (checked Oct 2, 2026)
• •Cursor, Run Modes and Auto-review: https://cursor.com/docs/agent/security/run-modes (checked Oct 2, 2026)
• •Cursor, PR Routing & Approval: https://cursor.com/docs/approval-agents (checked Oct 2, 2026)
• •GitHub, About protected branches (required reviews): https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches (checked Oct 2, 2026)
• •Atlassian, Jira Service Management, set up approval steps: https://support.atlassian.com/jira-service-management-cloud/docs/set-up-approvals/ (checked Oct 2, 2026)
• •Atlassian, Jira Service Management, what is change management: https://support.atlassian.com/jira-service-management-cloud/docs/what-is-change-management/ (checked Oct 2, 2026)
• •Data Workers, Spellbook Data Catalog: https://dataworkers.io/product/spellbook-data-catalog/ (checked Oct 2, 2026)
• •Data Workers, Autonomous Data-Conductor: https://dataworkers.io/product/autonomous-data-conductor/ (checked Oct 2, 2026)
• •Data Workers pricing: https://dataworkers.io/pricing/ (checked Oct 2, 2026)