You're on Amazon Q Developer: give it governed data context and approved data changes
Your engineers already ask Amazon Q Developer in VS Code, JetBrains and the terminal. Connect Data Workers over MCP and Q answers from governed data context, while every data change goes through approvals and receipts.
Your engineers already work with Amazon Q Developer. They open the Q chat panel in VS Code or a JetBrains IDE, ask about a Glue job or a Redshift query, accept inline suggestions, and run agentic coding requests against the workspace. Some of them work from the terminal, where the Q CLI has become the Kiro CLI on the same subscription. Your admins run the Pro tier through IAM Identity Center, and from the Q Developer tab in the Kiro console they decide whether MCP is on and which servers sit in the registry. Q Developer is good at the job AWS built it for: understanding, building and operating AWS applications from the editor. Data Workers is the agentic data platform that sits behind it. Connected over MCP, Q Developer answers from your governed data context, and every change to production data goes through Data Workers' approvals and leaves a receipt.
Key takeaways
- •Amazon Q Developer is the AWS coding agent. Data Workers is the data team it calls. Q writes and explains the code; Data Workers brings the context across Redshift, Glue, dbt and BI, owns the change in production and proves it worked.
- •One MCP entry, every Q surface. Q in the IDE reads
.amazonq/mcp.json, and the Kiro CLI reads the same project folder, so one server definition reaches the editor and the terminal. - •Two locks on every write. Q asks before any tool you set to Ask; Data Workers applies its per-domain guardrail, keeps a rollback point and writes the receipt.
- •Admins stay in charge. The MCP toggle and registry in the Kiro console decide whether Data Workers is allowed at all; Data Workers decides who may approve each data change.
- •It carries over to Kiro. AWS offers Kiro as the next step for Q Developer users, and the same Data Workers server works there unchanged.
Amazon Q Developer is the AWS coding agent. Data Workers is the data team it calls.
Q Developer reads your workspace, writes Glue and Spark code, generates SQL in Redshift query editor v2, and knows AWS services deeply. What it doesn't hold is the state of your data estate: which table is canonical, who owns it, what reads it downstream, what changed overnight in the app database, and who must approve a fix to finance data. That is what Data Workers holds. The Data Context Wizard keeps one governed context graph across Redshift, Glue, S3, dbt, orchestration and BI. The Data-Agents Swarm (20+ specialist agents) does the data work. The Autonomous Data-Conductor runs each fix end to end: detect, diagnose, fix, review, verify, remember. Spellbook Data Catalog (in preview) is where people review, approve, roll back and audit.
Here is one request, end to end. It is an illustration, not a customer case.
| Time | System | What happens |
|---|---|---|
| 02:10 | Aurora PostgreSQL | An app release renames orders.discount to discount_amount |
| 02:40 | AWS Glue | The orders_to_redshift job maps the missing column to null and succeeds |
| 03:15 | Amazon Redshift | 18,400 rows land in analytics.orders with null discounts |
| 05:00 | dbt | The run passes; fct_net_revenue is overstated |
| 08:45 | Amazon Quick | The revenue dashboard shows a jump nobody can explain |
| 08:52 | Q Developer (VS Code) | An analytics engineer asks: "Why did net revenue jump overnight?" |
| 08:53 | Q Developer | Q calls Data Workers over MCP (diagnose_incident, trace_cross_platform_lineage), both set to Always allow |
| 08:54 | Data Workers | Traces the jump to the rename; blast radius is 4 dbt models and 2 dashboards |
| 08:57 | Q Developer | Q asks to run remediate, set to Ask; the engineer approves |
| 09:10 | Spellbook | The finance data owner approves the change, as the finance domain requires |
| 09:12 | AWS Glue | Data Workers fixes the column mapping and reloads the night's orders, keeping a rollback point |
| 09:31 | dbt | dbt rebuilds; totals match the source; tests pass; receipt written |
| 09:40 | Amazon Quick | The dashboard is right before the finance review |
The engineer never left VS Code. Q Developer did what it does best: took the question, picked the right tools, showed the plan and asked before the one call that changes data. Data Workers did the data work: it found the cause in the app database, measured the blast radius through Glue, Redshift and dbt into Amazon Quick, routed the change to the person who owns finance data, made the fix reversibly and proved it against the source. Meanwhile Q can write the lasting fix in the repository, a not_null test on the discount column and an explicit mapping in the Glue script, as a pull request your team reviews as usual.
| What Amazon Q Developer does | What Data Workers does |
|---|---|
| Takes the question in the IDE chat panel or the terminal | Answers it from governed context: lineage, ownership, definitions, recent changes |
| Reads and edits the workspace, writes Glue, Spark, SQL and dbt code | Reads and changes Redshift, Glue, dbt and BI through each system's own API |
| Asks before tools set to Ask, runs Always allow tools, skips Deny | Applies per-domain guardrails and routes the change to the data owner |
| Writes the code fix for the pull request | Owns the production change, keeps a rollback point and verifies downstream |
| Shows the conversation for this session | Writes a receipt that outlives the session: who, why, what changed, how to undo |
Why doesn't Amazon Q Developer just do this itself?
Focus and risk. AWS built Q Developer to help people build and operate applications, and its design is right for that job. Every control it ships is about the assistant itself: per-tool permissions of Ask, Always allow or Deny; an MCP security model built on explicit permission, local execution and one process per server; and, for admins, an MCP toggle and a registry of approved servers in the Q Developer profile. Those are the right controls for a coding assistant: they decide which servers and tools this assistant may call.
Changing production data is a different product. A fix to analytics.orders touches an Aurora schema owned by an app team, a Glue job owned by the platform team, dbt models owned by analytics engineers, and a dashboard the CFO reads. Doing it safely takes context about every one of those systems, a blast radius, an approver per domain, a rollback plan, verification after the fact and a receipt an auditor can read next quarter. It also means carrying responsibility for changes in tools AWS doesn't run, such as dbt. A general assistant is right not to take that on. That is the product Data Workers is, and Q Developer is a natural place for your engineers to ask for it.
Every tool owns a slice. Data Workers covers the whole lifecycle
Each point tool adds another console, another contract and another handoff. Data Workers covers the whole data lifecycle with one context, one approval flow and one audit trail. Q Developer owns a valuable slice of it: writing and running AWS code in the IDE and terminal. It leads where that is the work, in pipeline code.
| Stage | Data Workers | Amazon Q Developer | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 4 | Q Developer reads your workspace and, in SageMaker Unified Studio, the governed data in a project. Data Workers keeps one governed context graph across Redshift, Glue, dbt, orchestration and BI. |
| Analytics & Insights | 8 | 5 | Q Developer writes SQL from your schema in Redshift query editor v2 and explains code. Data Workers answers business questions from governed definitions, lineage and ownership. |
| Data Quality | 8 | 4 | Q Developer writes tests and checks when you ask. Data Workers writes, runs and repairs checks across platforms and keeps them running. |
| Observability & Incidents | 8.5 | 4 | Q Developer diagnoses console errors and AWS operational issues. Data Workers detects, traces and closes data incidents across systems with a receipt. |
| Pipelines & Ingestion | 8.5 | 9 | Q Developer leads. It writes Glue jobs, Spark, SQL, dbt models and infrastructure code in the IDE and terminal. Data Workers owns the run in production behind approval. |
| Schema & Migration | 8 | 6 | Q Developer transforms code, including embedded Oracle SQL to PostgreSQL. Data Workers checks the blast radius across every downstream system before a schema change lands. |
| Governance & Access | 8.5 | 3 | Q Developer governs Q Developer: per-tool permissions, an MCP toggle and a registry set in the Kiro console. Data Workers proposes least-privilege grants on your data platforms behind approvals. |
| Security & Privacy | 8 | 5 | Q Developer scans code for vulnerabilities and opts Pro data out of collection. Data Workers flags sensitive column names in pull request review across the estate. |
| Cost / FinOps | 8 | 4 | Q Developer explains your AWS bill in the console. Data Workers traces Snowflake credits to the dbt model behind them and drafts the fix for its owner. |
| MLOps & Models | 7.5 | 6 | Q Developer helps write data prep, training and deployment code in SageMaker Studio. Data Workers keeps the data under the models healthy. |
How Amazon Q Developer and Data Workers work together
Q Developer stays on top, where engineers ask, build and approve tool calls. Data Workers sits underneath as MCP servers: the Context Wizard, the Swarm, the Conductor and the guardrails. Spellbook is where people look: data owners review and approve changes, roll them back and read the audit trail. For the wider AWS picture, see Data Workers on AWS.
Setup over MCP today. Every Data Workers agent is a standard MCP stdio server, so Q Developer starts it like any other local server. Clone the open-source repository and point Q at its start-agent.sh, one entry per agent. You can add each one through the IDE (Chat panel, tools icon, plus sign, transport stdio), which saves it to .amazonq/default.json for the workspace, or check an .amazonq/mcp.json file into the project. Q in the IDE reads that file by default, and the Kiro CLI keeps reading the project's .amazonq folder, so one file reaches both. Example (Q Developer .amazonq/mcp.json):
{
"mcpServers": {
"dw-context-catalog": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-context-catalog"]
},
"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"]
}
}
}Then open the MCP Servers panel and set permissions per tool. A sensible start: trace_cross_platform_lineage, search_across_platforms, diagnose_incident and get_incident_history on Always allow, because they only read; remediate on Ask, so Q stops before every change. Use /tools in the terminal to confirm what loaded.
For a shared deployment, run Data Workers as one remote server over Streamable HTTP. Q Developer supports remote servers with OAuth: in the IDE choose http and enter the URL, and Q opens a browser to authorize; in a CLI agent configuration it looks like this. Example (placeholder host):
{
"mcpServers": {
"data-workers": {
"type": "http",
"url": "https://<your-data-workers-host>/mcp"
}
}
}For admins. If your organization uses the MCP registry, add one streamable-http entry for the shared Data Workers server to the registry JSON your Q Developer profile points at, in the Kiro console under Settings, Q Developer tab. Q fetches the registry at startup and every 24 hours, shows users only approved servers, and still lets them set tool permissions. The registry decides which server is allowed; Data Workers decides who approves each data change. If your teams are moving to Kiro, the same entries work there; see You're on Kiro.
The same request on the autonomy ladder. Autonomy is set per domain, on the ladder L0 manual, L1 observe, L2 propose, L3 act reversibly, L4 autonomous.
- •L0 manual. The engineer queries Redshift by hand, reads the Glue script and greps the dbt project. Q helps with the SQL; nobody has the lineage from Aurora to the dashboard.
- •L1 observe. Q calls Data Workers and gets the cause, the blast radius and the owner. Nothing changes.
- •L2 propose. Data Workers drafts the mapping fix and the reload with blast radius and rollback plan. The finance owner approves in Spellbook; Q asks the engineer before the tool call.
- •L3 act reversibly. For a domain you trust, Data Workers fixes renamed-column mappings on its own with a rollback point and writes the receipt. The engineer reads it in Q.
- •L4 autonomous. The Conductor catches the schema change at 02:10, before Glue runs, updates the mapping and verifies the load. Q Developer is where an engineer reads the receipt in the morning.
Q permissions and Data Workers guardrails stack. Turning one up never turns the other down.
What changes for your team
Engineers keep the assistant they already use. What changes is the work behind it: the jobs that used to wait for a person with the right access and the right context now run through Data Workers, at the autonomy level each domain sets.
Data owners stop being pinged in Slack for "is this table right?" and start approving scoped changes in Spellbook. On-call stops starting from zero, because the first question typed into Q already returns the cause and the blast radius. The platform team stops handing out personal Redshift credentials for debugging: one MCP entry, one registry line, one audit trail.
Keep Amazon Q Developer, or consolidate?
Keep Amazon Q Developer if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too. With a coding assistant, keeping it is the usual answer: Q is where your engineers write AWS code, and Data Workers makes every data question and data change they send from it governed. Because Data Workers is a standard MCP server, a move to Kiro changes nothing on the data side. The same server also answers in Codex and Cursor, so teams that use more than one agent share one context and one audit trail. For the whole category, see Your company just rolled out AI assistants. Now what?.
The case for your CFO
You already pay for Q Developer seats, and engineers already use them on data work. The outcome to buy now is that the questions they ask get governed answers and the changes they ask for get made safely: fewer wrong numbers reaching finance, incidents closed in the same morning, and an audit trail for every change to production data.
The risk story is plain. At L1, Data Workers only reads and explains. At L2, it proposes and a named owner approves. At L3, it acts only where a change is reversible, and keeps the rollback point. L4 is reserved for domains you've trusted on evidence. Every action leaves a receipt: who asked, who approved, what changed, what it touched, and how to undo it. Q keeps its own tool permissions and your admin registry, so there are two locks on every write. Nothing migrates: Q Developer, Redshift, Glue, dbt and Amazon Quick all stay. The cost case is on the ROI page, the deployment and data-handling answers are on the security page, and the AWS data leader's guide covers the wider AWS plan.
Why now: coding assistants are already the front door for data work, and your teams are deciding their Kiro path this year. Wiring governed data context in once, over MCP, means it moves with them. The safety page walks through what agents can and can't do at each level, and the build-vs-buy page covers what it takes to wire this yourself.
The first win is small and visible: read-only Data Workers tools in Q for one domain, so "why is this number wrong?" gets a traced answer. Start with a pilot; pricing has the details, and the pilot is credited in full against the first year.
The sentence to repeat upstairs: "Our engineers keep Amazon Q Developer; Data Workers gives it our governed data context and routes every data change through one approval flow with a receipt."
Getting started
Start with a pilot. Pick one domain where engineers already ask Q Developer about data, often finance or product analytics, add the Data Workers servers to the project's .amazonq/mcp.json with read tools on Always allow and change tools on Ask, and run it at L1 for the first weeks. Move that domain to L2 when the answers hold up, and to L3 for the fixes your team approves every time. See pricing; the pilot is credited in full against the first year.
FAQ
Does Data Workers bypass Q Developer's tool permissions or our MCP registry? No. Q still asks before every tool set to Ask, and a registry set in your Q Developer profile still decides which servers can run. Data Workers adds its own per-domain guardrail on top, so a change needs both.
Which Q Developer surfaces does this work in? Q Developer in VS Code and JetBrains IDEs reads the MCP config in .amazonq/ or ~/.aws/amazonq/. The terminal experience is now the Kiro CLI, which keeps reading the project .amazonq folder and copies your global MCP config on install, on the same Pro subscription.
What happens when we move from Q Developer to Kiro? AWS will end support for the Q Developer IDE plugins on April 30, 2027, and recommends Kiro, which carries over inline suggestions, chat and code generation and supports MCP in both its IDE and CLI. Data Workers is a standard MCP server, so the same entries and the same receipts carry over. The Kiro page covers the Kiro-specific setup.
Whose credentials touch Redshift and Glue? Data Workers' own credentials, scoped per domain, so no personal warehouse keys sit in an engineer's IDE. The engineer's identity is recorded on the receipt as the person who asked and approved.
Won't more tools crowd Q's context? Start with the context and incident agents only, and set tools you don't need to Deny in the MCP Servers panel. Add the quality, schema and governance agents as domains move up the ladder.
Q Developer already writes Glue jobs and SQL. Why add Data Workers? Writing the code is Q's job, and it does it well. Knowing what that code touches downstream, who must approve the change, how to roll it back and proving the result is the data platform's job. The build-vs-buy page walks through what it takes to assemble that yourself.
Sources
- •AWS, "What is Amazon Q Developer?" (surfaces, end-of-support notice): https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is.html (checked Oct 2, 2026)
- •AWS, "Amazon Q Developer IDE plugins end of support" (April 30, 2027; Kiro): https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/q-developer-ide-end-of-support.html (checked Oct 2, 2026)
- •AWS, "Using MCP with Amazon Q Developer" (config paths, tool permission levels, /tools): https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/qdev-mcp.html (checked Oct 2, 2026)
- •AWS, "MCP configuration for Q Developer in the IDE" (default.json, legacy mcp.json, Ask / Always allow / Deny): https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/mcp-ide.html (checked Oct 2, 2026)
- •AWS, "MCP configuration in the CLI" (remote servers, OAuth): https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/command-line-mcp-config-CLI.html (checked Oct 2, 2026)
- •AWS, "MCP security": https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/command-line-mcp-security.html (checked Oct 2, 2026)
- •AWS, "MCP governance for Q Developer" (toggle, registry, Kiro console, client-side enforcement): https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/mcp-governance.html (checked Oct 2, 2026)
- •AWS, "Using Amazon Q Developer on the command line" (Q CLI has become the Kiro CLI): https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/command-line.html (checked Oct 2, 2026)
- •Kiro, "Upgrading from Amazon Q Developer CLI" (config migration, Pro subscription): https://kiro.dev/docs/upgrade-guides/migrating-from-q/ (checked Oct 2, 2026)
- •Kiro, "Migrating from Amazon Q Developer": https://kiro.dev/docs/upgrade-guides/migrating-from-q-developer/ (checked Oct 2, 2026)
- •AWS, "Amazon Q Developer pricing": https://aws.amazon.com/q/developer/pricing/ (checked Oct 2, 2026)
- •AWS, "Amazon Q Developer features" (Glue data integration, SageMaker Unified Studio, console operations): https://aws.amazon.com/q/developer/features/ (checked Oct 2, 2026)
- •AWS, "Interacting with Amazon Q generative SQL" (Redshift query editor v2): https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2-generative-ai.html (checked Oct 2, 2026)
- •Data Workers, "Client Setup": https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 2, 2026)