Concept card

Databricks Agent Bricks — Building and Governing Agents on Databricks

As of 2026-10-06

Edited by Cédric Mary, sole editor and publication director — 27 years in the SAP ecosystem. How these pages are produced, and where automation is used.

What is Databricks Agent Bricks?

Databricks' agent tooling (Agent Bricks and custom agents on Databricks Apps) is the natural home for an agent only if it needs to read Delta tables, call ML models, or query AI Search in the same reasoning loop — otherwise a direct LangChain chain is cheaper.

Databricks Agent Bricks, together with custom code agents hosted on Databricks Apps, is the agent-building runtime native to the Databricks Intelligence Platform (the current documentation presents it under those names, while older material calls it the Mosaic AI Agent Framework): scaffolding for constructing, evaluating, deploying, and governing multi-step AI agents that chain together tool calls, retrieval, language-model reasoning, and direct data queries, all inside a workspace where the platform's own catalog governs lineage, access control, and audit trails on every table, model, and function the agent touches. The framework's value proposition is narrow and specific: it is the right home for an agent whose reasoning loop needs to read Delta Lake tables, call machine learning models already registered in the workspace, or query a vector index, without copying that data or those models anywhere else first.

The three pillars that make it a platform rather than a library

The first pillar is deep integration with the workspace's experiment-tracking layer: every agent is registered with a typed input and output signature, the same way any other model artefact is, which makes it possible to run reproducible evaluation passes, compare versions side by side, and trace a production decision all the way back to the training or configuration data that shaped it. This is not a cosmetic detail — it is what turns "the agent behaved oddly on this request" from an unanswerable question into a traceable one.

Why it matters

Unity Catalog functions govern tool access the same way they govern notebooks and Delta tables, so agent permissions inherit existing data governance automatically.
Unity Gateway governs the tools and MCP servers an agent calls, while agents hosted on Databricks Apps expose a conversational REST API, letting BDC Connect or SAP AI Core call them without knowing the internal topology.
For SAP process-aware reasoning, the correct architecture is Joule Agent as orchestrator calling a Databricks agent as a specialist tool — not replacing Joule.

Key points

Databricks' agent tooling — Agent Bricks and custom code agents on Databricks Apps — is the agent runtime native to the Databricks platform: build, evaluate, deploy and govern multi-step agents inside a workspace where Unity Catalog governs every table, model and function touched.
It is the natural home for an agent only when the reasoning loop needs Delta tables, registered ML models or Vector Search in the same loop.
Otherwise a direct LangChain chain is cheaper and simpler — the framework's value is governance and lineage, not a smarter model.
In a BDC estate, decide first which agents belong on the Databricks side and which on Joule; the catalog boundary is the governance boundary.
The 2026 evolution toward Agent Bricks (a control-plane layer for custom agents) and managed MCP servers for Unity Catalog Functions, Genie, Vector Search and DBSQL is reducing the amount of hand-written orchestration code a team needs to maintain.
Both Databricks agent tools and SAP's own Joule Studio / Joule Work extensibility increasingly speak MCP natively, which is making 'Joule calls a Databricks agent as a tool' architectures easier to wire than a year ago.
Databricks' CLEARS evaluation framework standardises agent-quality measurement (correctness, groundedness, safety) via LLM-as-judge — insist on an equivalent evaluation gate before production regardless of which platform hosts the agent.
Agent reliability across repeated runs — consistency, cost, safety and policy compliance — is the metric that separates a demo from a production deployment, and it degrades silently if evaluation is skipped.

Terms used on this page

Unity Catalog tool: A Python function, NL-to-SQL interface, or vector search index registered in Unity Catalog and declared as an agent tool — the same access-control layer that governs tables also governs who can invoke it.
Unity Gateway: The Databricks control plane that governs access to model services, model providers and MCP services and monitors activity, with Unity Catalog enforcing permissions; its API reached general availability on 16 September 2026.
mlflow.evaluate(): MLflow's evaluation API for scoring agent or model outputs against a labelled dataset, including an LLM-as-judge mode for correctness, groundedness and safety.
Agent Bricks: Databricks' agent offering, documented as managed agent types (Knowledge Assistant, Supervisor Agent) plus an Agent Bricks CLI (Beta since 29 September 2026) for custom code agents hosted on Databricks Apps.
Managed MCP server (Databricks): A Databricks-hosted MCP server exposing Unity Catalog Functions, Genie, Vector Search or DBSQL as MCP-compatible tools, with enterprise governance built in — reduces the custom integration code needed to connect an agent's tools.
CLEARS framework: Databricks' standardised evaluation framework for agent quality, covering correctness, groundedness and safety dimensions via automated LLM-as-judge scoring against held-out data.
Agent reliability: The consistency, cost, safety, and policy compliance of an agent across repeated runs — the property that separates a demo from a production deployment.

Sources

Full card available to members. What the full card adds: the full decision framework · the SAP vs Snowflake / Databricks / Fabric comparison · the common pitfalls and their fix · the cheat sheet · the architecture schemas · the code blocks · the facts worth quoting.

Open in the app →