You're on Kiro. Here's how Data Workers builds on your specs
Your engineers already build from Kiro specs. Connect Data Workers over MCP and every spec carries live data context, while each data change goes through approvals and receipts.
Your engineers already build from specs in Kiro. A feature starts as requirements.md, becomes design.md, and breaks into tasks.md that Kiro runs in dependency waves before it opens a pull request. Steering files in .kiro/steering/ hold your stack and conventions, hooks in .kiro/hooks/ run a lint or a test the moment the agent saves a file, and MCP servers extend the agent with your own tools. The same harness answers in the Kiro IDE, the Kiro CLI and Kiro Web, so a .kiro/ folder committed to the repo gives every engineer the same agent. Administrators set models, MCP and permission policies in the Kiro console, which now also holds the settings tab for Amazon Q Developer. AWS even ships its Amazon EMR Spark troubleshooting and upgrade agents as Kiro powers. For building software from a clear plan, that setup is excellent. The open question for a data team is what happens when a spec changes a column that a Glue job, a QuickSight dataset and three dbt models still read.
That's where Data Workers comes in. Kiro is the spec-driven builder. Data Workers, the agentic data platform, is the data crew behind the spec: it knows what the change touches and carries it into production, scoped, approved, verified and recorded. Connected over MCP, Kiro writes its design from Data Workers' governed context, and every change to data goes through Data Workers' approvals and receipts. Nothing about Kiro changes. Your engineers keep their specs, steering and hooks.
Key takeaways
- •Kiro writes the plan and the code; Data Workers carries the data change. Kiro stays where engineers write specs, run tasks and review. Data Workers supplies lineage, owners and blast radius to the design phase, then applies the approved change in the warehouse and verifies it downstream.
- •Three files to start. One
mcpServersentry per agent in.kiro/settings/mcp.json, one steering file that says when to call Data Workers, and one hook that runs the impact check when a model or migration changes. - •Two locks on every write. Kiro's Supervised mode,
permissions.yamland MCP registry gate the tool call on the engineer's machine; Data Workers' per-domain guardrail gates the change to the warehouse. No agent approves its own work. - •One config, every surface. The IDE and the CLI read the same
.kiro/folder, and Kiro Web loads the repo's steering, hooks andmcp.jsoninto its cloud sandbox, so a spec started in the browser gets the same impact checks as one started in the editor. - •Climb one domain at a time. Start at L1 observe (impact sections in every design.md), move to L2 propose, then L3 act reversibly where the record earns it.
Kiro is the spec-driven builder. Data Workers is the data crew behind the spec.
Kiro knows your codebase and your intent. It reads the repo, your steering files and AGENTS.md, turns a request into requirements and a design, and works through the tasks. What it can't see from the repo alone is the live estate: which Redshift tables a dbt model really feeds, which Glue job exports a column to finance, which QuickSight dataset still selects it, and who owns each one. Data Workers keeps that in one governed context graph and does the data side of the work through 20+ specialist agents.
Here is one spec, end to end. This is an illustration, not a customer case.
| Time | System | What happens |
|---|---|---|
| 09:10 | Jira | A ticket asks to split orders.amount into net_amount and tax_amount for VAT reporting. |
| 09:12 | Kiro | An engineer starts a Feature Spec; Kiro drafts requirements.md with acceptance criteria. |
| 09:15 | Kiro | The design phase touches models/orders.sql, so the Data Workers hook fires and Kiro calls assess_impact on the Data Workers MCP server. |
| 09:16 | dbt | Data Workers reports amount is read by fct_revenue and two finance marts. |
| 09:16 | AWS Glue | It also finds the finance_export Glue job selecting the column for a nightly S3 drop. |
| 09:17 | QuickSight | And the Revenue weekly dataset behind the CFO dashboard. |
| 09:18 | Kiro | design.md records the blast radius; tasks.md fixes all four readers before the column changes. |
| 09:55 | GitHub | Kiro finishes the tasks and opens the pull request. |
| 09:57 | GitHub | Data Workers posts the blast radius and the rollback plan on the pull request. |
| 10:20 | GitHub | CI passes and the analytics lead approves the pull request. |
| 10:28 | Spellbook | The platform owner approves the Redshift migration. |
| 10:31 | Redshift | The owner applies the migration Data Workers drafted, with its rollback SQL on file; Data Workers queues the rerun of the affected models. |
| 11:05 | QuickSight | Revenue totals match the pre-change baseline, the next finance_export run succeeds, and the receipt is recorded. |
Without that context, the same spec produces a clean design, passing tests and a pull request that breaks the finance export on the first nightly run. With it, the design already names every reader, the engineer approves one pull request, the owner approves one change, and nobody chases anyone in Slack.
| Job | What Kiro does | What Data Workers does |
|---|---|---|
| Understand the request | Turns the ticket into requirements and acceptance criteria; reads steering and the repo | Adds live data context: lineage across dbt, Redshift, Glue and QuickSight, owners and usage |
| Design the change | Writes design.md with architecture and sequence | Supplies the impact report and the list of every reader the design must account for |
| Write the change | Runs tasks.md in waves across models, SQL and Glue scripts | Proposes the migration and the reader fixes as tasks, with blast radius attached |
| Gate the action | Autopilot or Supervised mode, permissions.yaml rules, autoApprove lists and the MCP registry | Routes data changes to the domain owner by policy, with blast radius and rollback in front of them |
| Apply to production | Opens the pull request for a person to review and merge | Applies the approved migration or rerun in the warehouse, with rollback ready |
| Verify and record | Runs tests and hooks; keeps checkpoints and the session | Checks the changed tables against baselines, then dashboards and downstream runs, writes a receipt to the audit trail |
Why doesn't Kiro just do this itself?
Focus and risk. Kiro built a strong product for one job: turning intent into well-planned, tested code. Its design reflects that. The harness works on a repository, checks tool calls against permission rules on the engineer's machine (or runs in an isolated cloud sandbox on Kiro Web), and delivers changes as pull requests that a person reviews. Kiro's own documentation is clear that the MCP toggle, the registry and permission policies are enforced on the client. That is exactly right for a coding agent.
Changing production data across systems is a different product. It needs to know that a column feeds a Glue job and a QuickSight dataset that live outside the repo. It needs a blast radius before anything runs, an approval routed to the owner of that domain rather than to whoever wrote the spec, a rollback path inside Redshift, a check that the dashboard totals still match afterwards, and a receipt an auditor can read. It also means taking responsibility for changes in systems Kiro doesn't run. A sensible coding-agent vendor leaves that to the server on the other end of the MCP connection. That server is Data Workers.
Every tool owns a slice. Data Workers covers the whole lifecycle
Kiro goes deepest on planning and writing pipeline code. Data Workers covers every stage of the data lifecycle around that code. Each point tool adds another console, contract and handoff; Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail.
| Stage | Data Workers | Kiro | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 5 | Kiro reads steering files, AGENTS.md and the code itself. Data Workers keeps one governed graph of tables, owners, lineage and usage across platforms. |
| Analytics & Insights | 8 | 4 | Kiro can write a query or a notebook on request. Data Workers answers business questions from governed metric definitions. |
| Data Quality | 8 | 5 | Kiro writes tests from a spec's acceptance criteria and hooks run them on save. Data Workers runs quality checks on the data and repairs failing ones. |
| Observability & Incidents | 8.5 | 3 | Kiro watches its own agent run through hooks and notifications. Data Workers detects data incidents, traces the cause and closes them with a receipt. |
| Pipelines & Ingestion | 8.5 | 9 | Kiro's home stage: specs turn requirements into design and tasks, and the agent writes and refactors pipeline code across the repo. Data Workers builds and reruns pipelines behind approval. |
| Schema & Migration | 8 | 6 | Kiro writes migration code and DDL as spec tasks. Data Workers assesses the impact, drafts each migration with its rollback SQL for the owner to apply in approved waves. |
| Governance & Access | 8.5 | 3 | The Kiro console governs the agent: models, MCP registry and permission policies. Data Workers proposes least-privilege grants on your data platforms behind approvals. |
| Security & Privacy | 8 | 5 | Kiro offers kiroignore, capability permissions and customer-managed keys for its own agent. Data Workers' pull request review flags new columns whose names or annotations look sensitive, and leaves a receipt on every data change. |
| Cost / FinOps | 8 | 2 | Kiro reports credit usage of Kiro. Data Workers traces Snowflake credits to the query and dbt model behind them and drafts the fix for the model's owner. |
| MLOps & Models | 7.5 | 4 | Kiro writes training and feature code. Data Workers keeps the data under models healthy and connects to MLflow and W&B. |
How Kiro and Data Workers work together
Kiro stays on top, where engineers write specs, run tasks and review. Data Workers sits underneath over MCP: the Data Context Wizard answers from the governed graph, the Data-Agents Swarm does the work, the Autonomous Data-Conductor runs each fix end to end, and Spellbook Data Catalog (in preview) is where people review, roll back and audit.
Connect the MCP server. Every Data Workers agent is a standard MCP stdio server, and Kiro reads the same mcpServers shape as the clients in our client setup docs. Clone the open-source core (dataworkers-claw-community, Apache 2.0), run npm install, and add the agents you want to .kiro/settings/mcp.json in the repo (or to ~/.kiro/settings/mcp.json to use them in every workspace; workspace settings win when both exist). Open it from the command palette with "Kiro: Open workspace MCP config (JSON)". Kiro reconnects servers when you save. The autoApprove list lets the read-only lineage, freshness and impact tools run without a prompt. Example (Kiro mcp.json):
{
"mcpServers": {
"dw-context-catalog": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-context-catalog"],
"autoApprove": ["trace_cross_platform_lineage", "blast_radius_analysis"]
},
"dw-schema": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-schema"],
"autoApprove": ["assess_impact"]
},
"dw-incidents": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-incidents"]
},
"dw-quality": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-quality"]
}
}
}In the CLI, /mcp in a session lists the loaded servers and their tools. For a team, run Data Workers as a remote server over Streamable HTTP and add it with a url and headers entry, keeping the token in the environment with Kiro's ${VAR} expansion, for example "Authorization": "Bearer ${DW_TOKEN}" against https://<your-data-workers-host>/mcp.
Add a steering file. Steering is how Kiro learns your conventions, and a file with inclusion: fileMatch loads only when the agent works on matching files. Example (.kiro/steering/data-workers.md):
---
inclusion: fileMatch
fileMatchPattern: ["models/**/*.sql", "migrations/**", "glue/**"]
---
- In the design phase of any spec that changes a model, table or Glue job, call assess_impact and list every downstream reader in design.md.
- Add a task to fix each reader before the task that changes the column.
- Before trusting a query result, call get_incident_history for open incidents on the tables it reads.
- Before the pull request, call run_quality_check on changed models.
- When something is described as broken, start a Bugfix Spec from diagnose_incident.Add a hook. Hooks make the check happen even when nobody remembers the steering. A PostFileSave hook with an agent action injects a prompt whenever the agent saves a model or migration. Example (.kiro/hooks/dw-impact-check.json):
{
"version": "v1",
"hooks": [{
"name": "Data Workers impact check",
"trigger": "PostFileSave",
"matcher": "(models/.*\\.sql|migrations/.*)$",
"action": {
"type": "agent",
"prompt": "Call assess_impact for the file you just changed and update design.md with every downstream reader."
}
}]
}Set the gates. Kiro's IDE runs in Autopilot by default; for repos that change production data we recommend Supervised mode, which yields for approval after each turn with file edits. In permissions.yaml, allow the Data Workers read tools and set ask on anything that changes data, such as dw-schema/apply_migration. On the enterprise side, an administrator can list Data Workers in the MCP registry in the Kiro console (Settings, Shared settings, MCP Registry URL). The registry format accepts streamable-http remotes, so the remote Data Workers server is the clean entry. Permission policies in managed-settings.json, deployed by MDM, can force ask on data-changing tools across the fleet. Kiro Web runs each session in an isolated cloud sandbox, where the registry and permissions.yaml don't apply by design; there, point the repo's mcp.json at the remote Data Workers server. On every surface, Data Workers' own guardrail then decides whether the change itself needs an owner's approval.
One request, from L0 to L4. Take one request an engineer types into Kiro: "the orders_daily freshness check failed again, fix it". Here is what happens at each level, set per domain.
| Level | What happens when the engineer asks |
|---|---|
| L0 manual | Kiro helps the engineer read logs and write a patch by hand. Data Workers isn't in the loop. |
| L1 observe | Kiro starts a Bugfix Spec and calls diagnose_incident. Data Workers answers: the Glue load job timed out after a source API change, two dashboards are stale, and the owner is the finance data team. bugfix.md starts from that cause. |
| L2 propose | Data Workers drafts the fix (a retry and timeout change on the job plus a backfill plan) with its blast radius. Kiro runs the tasks and opens the pull request; the owner approves. |
| L3 act reversibly | For this pre-approved class of fix, Data Workers reruns the load and the backfill itself, with rollback ready, and records the receipt. The engineer sees the result in Kiro. |
| L4 autonomous | Freshness incidents in this domain run end to end without waiting: detect, fix, verify, record. The owner reviews receipts in Spellbook and can dial the domain back at any time. |
If your AWS estate is the bigger picture, our guide to Data Workers on AWS covers Redshift, Glue and the rest of the stack.
What changes for your team
Engineers keep Kiro and their spec habits. What changes is the work around each data change: the hunt for who reads a column, the Slack thread to find an owner, the manual backfill, the evidence an auditor asks for months later.
The data platform team stops being the human lookup service for lineage and ownership. Analytics engineers get a design.md that already names every reader. Owners approve changes in one place with the blast radius in front of them. And the audit trail builds itself from receipts instead of screenshots.
Keep Kiro, or consolidate?
Keep Kiro if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
For most data teams, Kiro stays. It is how engineers turn requests into plans and code, and Data Workers is built to sit underneath it. What teams tend to consolidate are the extra tools around data changes: the separate lineage lookup, the impact-analysis script someone maintains, the spreadsheet of who owns what, the manual runbook for backfills. Data Workers runs that work with one context, one approval flow and one audit trail, and it serves every other MCP client from the same agents. If parts of your team still work in the Q Developer plugins, read You're on Amazon Q Developer; for teams on another editor, You're on Cursor; or start from the hub, Your company just rolled out AI assistants. Now what?.
The case for your CFO
You already pay for Kiro, and your engineers ship planned, tested code faster because of it. The outcome Data Workers adds is that the data changes those specs produce are right the first time: fewer broken dashboards, fewer failed finance exports, and less senior engineering time spent tracing who reads what.
The risk story is plain. At L1, agents only read and explain. At L2, they propose and a named owner approves. At L3, they act only on pre-approved, reversible classes of change, with rollback ready. Every action leaves a receipt with who asked, who approved, what changed and how to undo it. Our safety guide covers exactly what an agent can and can't do at each level, and the security and deployment guide covers where your data goes.
Why now: your engineers already ask Kiro to write specs that touch data code every week, and Kiro Web and its new Workflows run more of that work in the background. The question is whether those changes land with context and an approval trail or without them. Building that layer in house is possible, and our build-vs-buy guide lays out what it takes.
The first win is an impact section in every spec's design.md for one dbt and Redshift repo, at L1, with no change to how anyone works. What stays the same: Kiro, Redshift, Glue, dbt, QuickSight and your IAM and permission systems. Nothing is migrated. Our ROI guide shows how to size the return.
The sentence to repeat upstairs: "Our engineers keep Kiro and its specs; Data Workers makes every data change those specs produce scoped, approved, verified and recorded."
Getting started
Start with a pilot: connect Data Workers to Kiro in one repo, add the steering file and the hook, and run one domain such as freshness incidents or schema changes from L1 to L2 with your own engineers and owners. See pricing for the pilot terms; the pilot is credited in full against the first year.
FAQ
Does Data Workers replace Kiro's specs or autonomous mode? No. Kiro's specs, tasks and autonomous mode keep planning and writing the code. Data Workers adds the data context to the design and carries the approved data change into the warehouse, then verifies and records it.
Workspace or user mcp.json? The workspace file, .kiro/settings/mcp.json, travels with the repo, so every engineer and every Kiro surface that opens it gets the same servers. The user file, ~/.kiro/settings/mcp.json, suits one engineer across many repos. If both define a server, the workspace entry wins.
Our admins turned on the MCP registry. Will Data Workers still load? Only if it is in the registry. In registry mode Kiro hides servers that aren't listed, including ones defined in mcp.json. Ask your administrator to add the remote Data Workers server as a streamable-http entry; engineers can then add their own token through a header override without editing the registry.
Can Kiro's agent change production data on its own? Only within the autonomy level you set for that domain. Kiro's Supervised mode, permission rules and registry gate the tool call, and Data Workers' guardrail gates the change itself. At L2 a named owner approves every change; at L3 only pre-approved, reversible classes run, each with rollback ready and a receipt.
We're moving from Amazon Q Developer. Does anything change? The Data Workers side doesn't. AWS ends support for the Q Developer IDE plugins on April 30, 2027 and points teams to Kiro. Q Developer and Kiro both take MCP servers, and the Kiro console now holds the Q Developer tab for MCP settings, so one administrator manages both. Kiro adds steering, hooks and specs, which is where the Data Workers checks plug in.
How do we keep credentials out of the repo? Use Kiro's ${VAR} expansion in env for local servers and in headers for the remote server, so the committed mcp.json holds only variable names. Data Workers uses its own scoped credentials to each platform, so engineers never paste warehouse keys into Kiro.
Which data platforms does this work with? Data Workers runs control-plane connectors for Snowflake, Databricks and BigQuery, reads dbt metadata, and connects to AWS Glue, Redshift, QuickSight and the rest of your stack over each tool's API or MCP server today.
Sources
Kiro capabilities and statuses are current as of October 2, 2026, from Kiro's own documentation: How Kiro works (unified harness, .kiro/ scopes; checked 2026-10-02), Specs (checked 2026-10-02), Steering (inclusion modes, team steering; checked 2026-10-02), Hooks and Hook types (checked 2026-10-02), MCP, MCP configuration and MCP registry (checked 2026-10-02), Permissions and Autopilot (checked 2026-10-02), Enterprise MCP governance and permission policies (client-side enforcement; checked 2026-10-02), Kiro Web and Kiro Web powers and MCP (cloud sandbox; registry not applied to Web sessions; checked 2026-10-02), Migrating from Amazon Q Developer (checked 2026-10-02) and the changelog (IDE 1.2.4 with Workflows, Sep 30, 2026; Kiro Web Workflows, Sep 30, 2026; CLI 2.27.0, Oct 1, 2026; checked 2026-10-02). AWS: MCP governance for Q Developer (Kiro console, Q Developer tab; checked 2026-10-02) and Amazon EMR Spark troubleshooting and upgrade agents as a Kiro power (Apr 3, 2026; checked 2026-10-02), and Amazon Q Developer IDE plugins end of support (April 30, 2027; checked 2026-10-02). Data Workers setup follows the client setup docs and the open-source dataworkers-claw-community repository (start-agent.sh and the agent tool definitions for assess_impact, trace_cross_platform_lineage, blast_radius_analysis, run_quality_check, diagnose_incident, apply_migration and rollback_migration; checked 2026-10-02). Product names and statuses change quickly; if we've got something wrong, tell us and we'll fix it.