Bedrock AgentCore vs Data Workers: Build Your Own Data Agents or Run Finished Ones?

Amazon Bedrock AgentCore and Data Workers answer different questions. AgentCore answers "how do we build and run our own agents on AWS?" with a runtime, gateway, memory, identity, policy and evaluations. Data Workers answers "how do we get agents that run our data platform?" with 20+ finished data engineering agents, a context graph, an approval flow and receipts.

You can build data agents on AgentCore. Most data teams get there faster, and with less to maintain, by running Data Workers, and the two fit together because Data Workers agents are MCP servers that AgentCore Gateway can call.

Key Takeaways

• •AgentCore is a full kit for building agents: Runtime, Harness, Gateway, Memory, Identity, Policy (Cedar-compatible) and Evaluations, all generally available.
• •AWS's own Agentic Data Operations Platform (ADOP) is a reference architecture on Bedrock that you clone, deploy and maintain yourself.
• •A production data agent needs much more than a runtime: cross-system context, specialist skills, verification, per-domain autonomy, an approval inbox and an audit format.
• •Data Workers ships all of that ready to run, on Bedrock models if you choose.
• •Data Workers agents can sit behind AgentCore Gateway next to the agents you build yourself.

What AgentCore gives you

AgentCore has grown into a complete platform for agents on AWS.

For a platform team building agents across many use cases, this is an excellent foundation.

What you would build on top for data engineering

Here is the honest list of what a production-grade data operations agent needs beyond the runtime. AgentCore leaves each item to you, by design.

• •A context graph across AWS and non-AWS systems. Lineage from Aurora and DMS through Glue, S3 Tables and Redshift to dbt models, Airflow DAGs and dashboards, with owners and definitions. Kept current as the estate changes.
• •Specialist skills. Schema evolution, pipeline repair, incident debugging, data quality, access governance, cost cleanup, migration. Each has its own playbooks and edge cases.
• •A verification loop. After a fix, rerun the checks, diff the values, confirm the downstream numbers and only then close the incident.
• •Per-domain autonomy. Observe, propose, act reversibly or autonomous, set separately for failed loads, schema changes, access and cost.
• •Blast-radius scoping. Compute what a change touches before it runs, across every system in the graph.
• •An approval inbox. One place where proposed changes are approved, steered, sent back or rolled back by the right owner.
• •Receipts. A record of why each change was made, what it touched, who approved it and how to undo it, in a format your auditors accept.
• •Ongoing maintenance. Keeping all of the above working as AWS services, dbt versions and your estate change.

ADOP shows the pattern well: sub-agents that generate ETL code, quality checks and DAGs, with human-in-the-loop approval. It is a starting point you deploy and own. The list above is the distance from that starting point to a product.

What Data Workers ships

Data Workers is that product, ready to run on AWS.

• •Data Context Wizard builds and maintains the context graph across the Glue Data Catalog, Lake Formation, Redshift, DMS, S3 Tables, dbt, your orchestrator and BI.
• •The Data Agents Swarm brings 20+ specialist agents for schemas, pipelines, incidents, quality, access, security, cost and migrations.
• •The Autonomous Data Conductor owns each outcome through detect, diagnose, fix, review, verify and remember.
• •Per-domain autonomy levels, blast-radius scoping and an authority guard that stops any agent from approving its own work, enforced in code.
• •Tamper-evident receipts on every change.
• •An Apache 2.0 core, unlimited seats and no usage meter. See pricing.

Head to head

How they fit together

This is not either/or at the infrastructure level. Data Workers agents are MCP servers, so a team building on AgentCore can register them as Gateway targets and call them as tools from its own agents. Data Workers can run on the Bedrock models you already use. Your AgentCore Policy controls still apply to the tool calls your agents make, and Data Workers adds its own per-domain guardrail on the data change itself.

A common pattern: your platform team builds business-specific agents on AgentCore, and those agents call Data Workers whenever the work touches the data platform, such as checking impact, fixing a failed load or requesting access.

Frequently Asked Questions

Can you build data engineering agents on Bedrock AgentCore?

Yes. AgentCore provides the runtime, gateway, memory, identity, policy and evaluations. You would still need to build the context graph, the specialist data skills, verification, per-domain autonomy, an approval inbox and receipts. Data Workers ships those ready to run.

Does Data Workers run on Amazon Bedrock?

Data Workers supports Bedrock as a model provider, so you can run it on models you already use there, with no markup on model spend. Your data stays in your AWS accounts.

Can AgentCore agents call Data Workers?

Yes. Data Workers agents are MCP servers, so you can register them as AgentCore Gateway targets and call them as tools.

What is AWS ADOP?

The Agentic Data Operations Platform is an AWS reference architecture published in August 2026, with sample code on GitHub. It shows sub-agents on Bedrock generating ETL, quality checks and DAGs with human approval. It is a pattern you deploy and maintain yourself.

Sources

• •What is Amazon Bedrock AgentCore
• •AgentCore Policy general availability (Mar 3, 2026)
• •New AgentCore Runtime general availability (Sep 18, 2026)
• •AWS MCP Server general availability (May 6, 2026)
• •Agentic Data Operations Platform (ADOP) (Aug 21, 2026)