Agent Bricks vs the Data-Agents Swarm: Build or Buy Your Data Agents

Your platform team runs Databricks well. Unity Catalog governs the lakehouse, MLflow tracks your models, and Genie Agents answer questions for finance and sales. This year Agent Bricks made it easy to build more: a Supervisor Agent that routes work to subagents, a Knowledge Assistant that answers from your documents with citations, and custom agents in Python. So when someone asks for agents that fix broken pipelines, clear access requests and catch schema changes, the natural answer is "we'll build them on Agent Bricks."

That instinct is a good one, and this page respects it. Agent Bricks is the workshop where you build your own agents. The [Data-Agents Swarm](/product/data-agents-swarm/) is the crew already trained for data operations. Agent Bricks gives you the parts. Data Workers, the agentic data platform, ships 20+ specialist agents that run the data lifecycle across Databricks, Snowflake, dbt, Airflow and BI, with approvals, rollback and a receipt on every change. You don't have to choose. A Supervisor Agent can call Data Workers agents as tools over MCP, so you build the agents that are unique to your business and buy the ones every data team needs.

Key takeaways

• •Agent Bricks is a framework for building agents. Supervisor Agent, Knowledge Assistant and custom agents are GA. It ships no finished agents for pipelines, incidents, schema changes, access or cost.
• •The Data-Agents Swarm is the finished product for those jobs. 20+ specialist agents, one context graph, autonomy set per domain, and a tamper-evident receipt on every change.
• •Building it yourself is a real program. Connectors to dbt, Airflow and Snowflake, a context graph, blast-radius checks, approvals, rollback, receipts, verification and someone on call for the agents. We list it below.
• •Agent Bricks leads on its home ground: custom agents, cited answers over documents, and MLflow evaluation and tracing.
• •Use both. Register Data Workers agents with your Supervisor Agent over MCP. Your Supervisor routes the question; Data Workers does the data work and answers with a receipt.
• •Zero migration. Agent Bricks, Unity Catalog, MLflow and Unity Gateway all stay.

Going further. For everything Data Workers adds on a Databricks stack, read Data Workers on Databricks. For Databricks' own ops agent, read Genie ZeroOps vs the Autonomous Data-Conductor.

Six things Data Workers adds on top of Agent Bricks

1. Agents that do data work on day one. The Swarm ships the Incident Debugging, Pipeline Building, Schema Evolution, Data Change Review, Quality Monitoring, Access & Governance, Security, Cost and Migration agents, among others. Each is an MCP server. There's no build sprint before the first incident gets traced.

2. Fixes where the cause lives. Most incidents that show up in Databricks start somewhere else: a source rename, a Fivetran sync, a dbt model in Snowflake, a late Airflow task. Data Workers proposes the dbt change as an approval-gated diff for the owner to merge, triggers the Airflow rerun, or applies a Unity Catalog grant through the permissions API.

3. One governed context graph. Data Context Wizard joins Unity Catalog grants and metric views with your dbt manifest, Airflow state, Snowflake query history and BI metadata through 50+ connectors. Every fact carries its source, author, confidence and the time it was observed.

4. Autonomy set per domain. Start every domain observe-only. Let freshness reruns move up to reversible actions while schema changes stay at propose-and-approve. The level is a setting in Data Workers. Your team doesn't write or maintain that logic.

5. Receipts and rollback on every change. Every action records who or what made it, why, what it touched, the blast radius and how to undo it. No agent can approve or promote its own work; that rule is enforced in code.

6. One place to review it all. Spellbook Data Catalog (in preview) is where people approve, steer, send back or roll back agent work, and where audit evidence builds up as a side effect.

The Autonomous Data-Conductor ties the six together: detect, diagnose, fix, review, verify and remember, across the estate.

One incident, five systems

Here is a scenario many Databricks teams will recognize. It's an illustration, not a customer case.

• •01:20. A Salesforce admin renames Segment__c to Customer_Segment__c.
• •01:45. Fivetran syncs the new column into Snowflake. The old column stops filling.
• •03:00. Airflow runs dbt. dim_accounts succeeds and writes null segments for every new account.
• •08:05. A Genie Agent reads that table through Lakehouse Federation. A sales VP asks your Supervisor Agent why Enterprise pipeline fell 40% overnight.

Agent Bricks routed the question well. Data Workers did the data work behind it. That split is the whole page.

What Agent Bricks covers, as of October 2026

Databricks calls Agent Bricks its developer agent platform. Here is what its documentation and release notes say ships today.

This is a strong framework. Supervisor Agent runs on behalf of the user, so people only reach the subagents and data they're allowed to see. Knowledge Assistant is a good managed agent for document questions. Every row is a part you assemble. None of them is an agent that already knows how to fix a dbt model or clear an access request.

Why doesn't Agent Bricks just do this itself?

Focus, and risk. Databricks built Agent Bricks to be the place you build agents on your data, and a framework is the right product for that job. It lets every customer build what is unique to them, and it keeps Databricks out of decisions it can't own.

Finished agents that write to production data across systems are a different product category. They need blast-radius scoping across platforms, approvals per domain, rollback, receipts, context about every other system, and accountability for changes in tools Databricks doesn't own, like your dbt repo, your Airflow deployment and your Snowflake account. Databricks' own operations agent, Genie ZeroOps, is scoped to Databricks assets for the same reason. Data Workers is that other product.

One platform, not one more tool

Building agents is one slice of a data team's year. The same team keeps the catalog current, writes quality checks, closes incidents, changes pipelines, handles access, cuts spend and produces audit evidence. Every point tool adds another console, another contract and another handoff, and every agent you build yourself adds another thing to maintain.

Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail. We score the same ten stages on every comparison page. Agent Bricks leads on two, both home ground: MLOps and models, and analytics and insights through Genie Agents.

Agent Bricks vs the Data-Agents Swarm on the outcomes you buy

The ten-stage view shows breadth. This view scores eight outcomes a data leader pays for when deciding whether to build or buy data agents. Agent Bricks leads on three, all on its home ground. Data Workers leads on the five that decide whether data work actually gets done.

These are directional scores of scope, not benchmarks. We've shown the reasoning so you can check every line.

The build list: what "we'll build it on Agent Bricks" means

If your team builds data-operations agents on Agent Bricks, this is the work. Agent Bricks gives you a good start on several rows. The rest is a product your team would own for as long as the agents run.

Some teams will build all of this, and the result can be excellent. The question for a leader is whether those twelve rows are the best use of a platform team that also has a lakehouse to run.

Where Agent Bricks stops

Each limit comes from Databricks' own documentation, and each follows from building a framework rather than a finished product.

It ships parts. The data-ops agents are yours to build. The managed agent types are Knowledge Assistant and Supervisor Agent. Nothing in the documentation ships an agent for incidents, pipelines, schema, access or cost.

Reach outside Databricks is what you register. A Supervisor Agent can call external and custom MCP servers. What those servers can read or change in dbt, Airflow or Snowflake is up to the server, and if you build it, your team owns it.

Approvals are per tool call. Unity Gateway service policies can allow, deny or require approval for a call, and contextual policies are Beta. Deciding that freshness reruns may run alone while schema changes wait for a named approver, per domain, is design work your team does.

Logs are not receipts. System tables record tool invocations. A record that ties a change to its reason, diff, blast radius, approver and undo path is something you build.

Supervisor routing needs upkeep. Practitioners note that routing follows the instructions you write, so adding Genie Agents and tools means maintaining those instructions, and each hop is another model call.

Where the two overlap

What it costs

Agent Bricks has no separate list price. It bills through Databricks compute. The Supervisor Agent requires serverless compute and a serverless usage policy with a nonzero budget, and custom MCP servers run on Databricks Apps pricing. The bigger cost of building is people: the engineers who write and maintain the twelve rows above.

Data Workers is a flat platform fee. The Apache 2.0 core is free. A pilot is $7,500 one-time. Scale starts at $1,000 a month and Enterprise at $3,000 a month (billed annually). Seats are unlimited, there's no usage meter, and there's no markup on model spend because you bring your own model. See pricing.

The fastest first win: give your Supervisor Agent a data-ops tool

Pick one Supervisor Agent your business users already ask. Run the Incident Debugging and Pipeline Building agents over HTTP, register them as MCP servers through a Unity Catalog connection, and add them as subagent tools. Set the incidents domain to propose. The next time someone asks why a number moved, the Supervisor calls Data Workers, and the answer comes back with the cause, a proposed fix and its blast radius, waiting in Spellbook for approval. After a few weeks of approving those proposals as written, move freshness reruns up to reversible actions.

What each Data Workers product does

Data-Agents Swarm. 20+ specialist agents for pipelines, incidents, quality, schema, change review, access and governance, security, identity, cost, migration, observability, streaming, ingestion and MLOps. Each is an MCP server your Supervisor Agent or coding agent can call.

Autonomous Data-Conductor. Owns an outcome rather than a step. It runs detect, diagnose, fix, review, verify and remember, scopes the blast radius before acting, and records a receipt.

Data Context Wizard. One governed context graph across every platform. It reads Unity Catalog grants, imports metric views and joins them with dbt, Airflow, warehouse and BI metadata.

Spellbook Data Catalog. The business-user app and control plane for agent work: one inbox to approve, steer, send back or roll back, and asset pages for the whole estate. Approval requests also reach the team in Slack or email.

Autonomy guardrails and security

Agent Bricks governs agents at the tool call. Data Workers governs data work at the domain, so trust can grow one domain at a time.

• •Every deployment starts observe-only. You raise autonomy per domain as the receipts earn trust.
• •Levels run from L1 observe to L4 autonomous. Freshness reruns can act reversibly while schema changes stay at propose.
• •Every write is scoped before it runs, with blast radius computed across platforms.
• •Every action is approved or reversible and leaves a tamper-evident receipt.
• •No agent can approve or promote its own work, enforced in code.
• •Least privilege. Data Workers acts with the grants you give it, through each platform's own permission system, including Unity Catalog. Your Unity Gateway policies still apply to every call your Supervisor makes.

"Our Supervisor Agent can call any MCP server. Doesn't that close the gap?"

It closes the connection gap, and that's why using both works. MCP lets your Supervisor reach a tool. It doesn't supply the tool's judgment: what to change in dbt, how far the change reaches, who must approve it, how to undo it, and whether the data is right afterwards. If you write those MCP servers yourself, you've signed up for the build list. If you register Data Workers agents, those answers come with the tool, and every Data Workers agent is already an MCP server.

How it fits together

Here's the pattern, over MCP today. Data Workers agents run over streamable HTTP in your environment. You register them as MCP servers in Unity Catalog, and Unity Gateway governs who can call them. Your Supervisor Agent adds them as tools next to your Genie Agents and Knowledge Assistant. When a request is data work, the Supervisor hands it to Data Workers, which reads its context graph, proposes or makes the change at the level you set, verifies it, and returns the result with a receipt. People review in Spellbook. Nothing moves; Data Workers stores metadata and scrubbed facts, not copies of your tables.

The case for your CFO

The outcome. Data incidents, pipeline breaks, schema changes, access requests and cost cleanup get handled by agents that already exist, so your platform team spends its year on the agents and data products only your business can build. Wrong numbers get fixed before the forecast call instead of after it.

The risk story. Every domain starts observe-only. At L2 agents propose and a person approves; at L3 and above they act only on reversible changes you've opened for that domain. Every write is scoped before it runs, every action is approved or reversible, and each one leaves a receipt with who or what acted, why, what changed, the blast radius and how to undo it. No agent approves its own work. Zero migration: nothing is copied or moved.

Why now. Agent Bricks made building agents easy this year, so the pressure to build data-ops agents in-house is real. The twelve-row build list is the cost of saying yes. Buying that list lets the build budget go to agents that differentiate the business.

The first win. One Supervisor Agent your business users already ask, with the Incident Debugging and Pipeline Building agents registered as tools, in propose mode.

What stays the same. Agent Bricks, Unity Catalog, MLflow, Unity Gateway, dbt, Airflow and Snowflake. Your policies keep applying.

The pilot path. Start with a pilot; the pilot is credited in full against the first year. See pricing.

The sentence to repeat upstairs: we build the agents that are unique to our business on Agent Bricks, and we buy the data-operations agents every team needs, with approvals, rollback and receipts already in them.

When Agent Bricks alone is enough

Agent Bricks alone can be enough if your agent roadmap is about business questions and documents, your estate is Databricks end to end, and you have a platform team that wants to own data-ops agents as a product. Everyone else gets more from using both: build what is yours, and let the Data-Agents Swarm run the data lifecycle under it.

FAQ

Is Data Workers an Agent Bricks alternative? For data operations, yes. Agent Bricks is a framework for building agents. The Data-Agents Swarm is a finished set of data-operations agents. Most Databricks teams use both: Agent Bricks for custom agents and document answers, Data Workers for incidents, pipelines, schema, access, cost and audit.

Can an Agent Bricks Supervisor Agent call Data Workers agents? Yes, over MCP today. Supervisor Agent supports external and custom MCP servers as tools, and every Data Workers agent is an MCP server that runs over streamable HTTP. Register it through a Unity Catalog connection and add it as a tool.

Should we build data-ops agents on Agent Bricks or buy them? Build the agents that encode what is unique to your business. Buy the ones every data team needs, because the expensive part is the build list: connectors, cross-platform context, blast radius, approvals, rollback, receipts, verification and ownership.

Does Data Workers replace Unity Gateway or Unity Catalog? No. Unity Catalog stays your governance layer on Databricks and Unity Gateway keeps governing model and tool calls. Data Workers acts through Unity Catalog's own permissions and adds approvals and receipts for data work across platforms.

What happens if a Data Workers agent gets a fix wrong? Every write is scoped and sent to review at the autonomy level you set for that domain. Every action is approved or reversible, leaves a tamper-evident receipt, and has a rollback path. No agent can approve its own work.

Does Data Workers work outside Databricks? Yes. That's the point of the Swarm. It runs across Databricks, Snowflake, BigQuery, dbt, Airflow, Fivetran and BI tools with one context graph and one approval flow.

How much does Data Workers cost? A free Apache 2.0 core, a $7,500 one-time pilot, Scale from $1,000 a month and Enterprise from $3,000 a month (billed annually), with unlimited seats and no usage meter. See pricing.

Sources

Agent Bricks capabilities and statuses come from Databricks documentation, release notes and blog posts, checked October 2, 2026:

• •Agent Bricks overview (updated Sep 30, 2026)
• •Supervisor Agent (updated Sep 11, 2026)
• •MCP Services for external MCP servers (updated Sep 11, 2026)
• •Custom MCP servers on Databricks Apps (updated Sep 30, 2026)
• •Unity Gateway (updated Sep 29, 2026)
• •Release notes, February 2026: Supervisor Agent GA and rename, AI Gateway Beta
• •Release notes, June 2026 and September 2026: Supervisor tools, managed memory, Agent Bricks CLI Beta, Unity Gateway GA
• •Knowledge Assistant is generally available (Jan 27, 2026)
• •Agent Bricks at Data + AI Summit 2026 (Jun 16, 2026)
• •AI governance at Data + AI Summit 2026: Unity Gateway (Jun 16, 2026)

Product names and statuses change quickly; if we've got something wrong, tell us and we'll fix it.