Key takeaways
✓Agent Bricks is Databricks' framework for building, deploying and governing AI agents directly on the lakehouse, using your own data and infrastructure.
✓The knowledge assistant capability lets you build retrieval-augmented AI tools that answer questions against controlled, governed data sources rather than generic training data.
✓Governance is built in through Unity Catalog, meaning agent access to data, tools and models follows the same permissions your team already manages.
✓Building effectively with Agent Bricks requires a clear understanding of retrieval pipelines, tool-calling patterns and agent evaluation, not just familiarity with the Databricks interface.
✓Teams that invest in the right skills early avoid the most common failure modes: agents that hallucinate, exceed budget or drift outside policy boundaries.
What is Agent Bricks?
Agent Bricks is Databricks' native framework for building, deploying, and governing AI agents directly on the lakehouse. Rather than stitching together separate orchestration tools, vector databases, and monitoring layers from different vendors, Agent Bricks gives data and engineering teams a single, integrated surface inside Databricks where agents can be built and managed end to end.
The product sits within Mosaic AI, Databricks' suite of tools for developing and operationalising AI. Agent Bricks specifically addresses the problem that arises once teams move past simple prompt-and-response use cases: how do you build an AI system that reasons over your own data, takes multi-step actions, and can be audited when something goes wrong?
Databricks introduced Agent Bricks because the gap between a working prototype and a production-grade agent is substantial, and most of the difficulty is not in the model itself. It is in the surrounding infrastructure: retrieval pipelines, tool definitions, access controls, evaluation harnesses, and lineage tracking. Pulling those pieces together from scratch is slow and error-prone. Agent Bricks packages them in a way that is consistent with how data teams already work on the platform.
A few things are worth being clear about here. Agent Bricks is not a no-code visual builder aimed at business users. It is designed for data engineers and ML practitioners who are comfortable writing Python and working with Databricks notebooks and jobs. It also does not operate independently of Unity Catalog, Databricks' governance layer. Agents built with Agent Bricks inherit the same data access controls and lineage metadata that govern the rest of your lakehouse, which matters considerably for teams in regulated industries.
If you are already running workloads on the Databricks Lakehouse, Agent Bricks extends what your team can build without requiring a separate platform. If you are new to Databricks, it is one of the stronger arguments for consolidating on the platform rather than assembling a piecemeal agent stack.
How does the Agent Bricks knowledge assistant work?
The Agent Bricks knowledge assistant grounds your AI agents in your own enterprise data rather than relying solely on a model's training knowledge. It does this through retrieval-augmented generation, or RAG, a pattern where the agent searches a knowledge base at query time, retrieves relevant content, and passes that content to the language model as context before generating a response.
In plain terms: instead of the model guessing from what it learned during training, it looks up the answer in sources you control.
What the knowledge assistant retrieves from
The knowledge assistant connects to data stored in the Databricks Lakehouse, including documents, tables, and unstructured content indexed as vector embeddings. Vector embeddings convert text into numerical representations that make semantic search possible. When a user asks a question, the assistant finds content that is meaningfully similar to the query, not just content that shares the same keywords.
For an enterprise team, this means you can build an agent that answers questions drawing from internal documentation, policy libraries, technical runbooks, or structured data sitting in Delta tables. The sources stay in your environment. Nothing needs to move to an external service.
Where Unity Catalog comes in
Retrieval on its own does not solve the governance problem. A knowledge assistant that can fetch any document for any user is a liability, particularly in organisations with sensitive data classifications or access controls already in place.
Agent Bricks integrates with Unity Catalog, Databricks' unified governance layer, so the knowledge assistant respects the same permissions that govern the rest of your data. A user asking the agent a question only retrieves content they already have access to. If your Unity Catalog configuration restricts a dataset to a specific team, the agent will not surface that content to someone outside that team.
Retrieval without governance is a risk, not a feature
The value of a knowledge assistant scales with how much of your internal data it can access. That makes access controls essential from day one, not something to bolt on later.
How responses stay accurate
RAG helps, but it does not eliminate the risk of an agent producing incorrect or misleading output. Agent Bricks addresses this through MLflow tracing, which logs what each agent retrieved, what prompt it constructed, and what the model returned. You can inspect the full chain of reasoning for any response.
For data and engineering leads, this is the part that matters most in practice. When something goes wrong, you need to know whether the problem was in the retrieval step (wrong documents surfaced), the prompt (context assembled poorly), or the model response itself. Tracing makes that diagnosis possible rather than leaving you guessing.
How do you build an agent with Agent Bricks?
Building an agent in Agent Bricks follows a structured workflow: define what the agent should do, give it the tools it needs, choose a model, then deploy it into a governed runtime. The steps are deliberate rather than freeform, which is part of why production deployments hold up better than agents cobbled together outside a platform.
Authoring: describing goals and behaviour
You start by specifying the agent's purpose in plain language, what questions it should answer, what tasks it can take, and where it should stop and hand off to a human. This instruction layer sits in a configuration that Databricks versions and tracks. Change the system prompt or adjust a tool binding, and you have a new version, complete with a record of who changed what and when.
This matters more than it sounds. Many teams find that agent behaviour drifts as prompts get edited informally. Versioned configuration closes that gap.
Tools: connecting the agent to data and actions
Tools are the functions an agent can call: run a SQL query, retrieve a document from a vector index, call an external API, trigger a workflow. Agent Bricks lets you bind these tools to the agent at build time. Each tool is a discrete, testable unit, which means you can validate what the agent is actually allowed to do before it touches production data.
The Databricks Lakehouse is the natural home for those tools. A retrieval tool pulls from a vector index built on Delta Lake. A query tool runs against a Unity Catalog table. The agent never reaches outside the governance boundary you have already set up.
Models: choosing and switching the LLM
Agent Bricks is model-agnostic at the inference layer. You can back an agent with a model served through Databricks Model Serving, whether that is a foundation model accessed via the AI Gateway, a fine-tuned model your team has trained, or an external model endpoint. The agent configuration references a model endpoint by name rather than by hard-coded credentials, so swapping from one model to another is a configuration change rather than a code rewrite.
Model flexibility is an operational advantage
Locking an agent to a single model at the code level creates fragility. When that model is deprecated or a better option appears, a configuration-level switch takes minutes rather than weeks.
MLflow and Unity Catalog: traceability by default
Every agent built on Agent Bricks is logged as an MLflow experiment. Each run captures the configuration, the tool bindings, the model endpoint, and evaluation results. When something goes wrong in production, you have a complete record of exactly what was running.
Unity Catalog sits alongside this as the access control layer. Permissions on the tables, vector indexes, and functions an agent can call are managed in the same place you manage all your other data assets. There is no separate agent-specific permission system to maintain, and no shadow access paths to audit.
Together, these two components are what make Agent Bricks defensible in regulated environments. The agent's behaviour is not opaque. It is logged, versioned, and scoped to permissions that your governance team already controls.
Why does governance matter for AI agents?
An AI agent that can query databases, call external APIs, and write back to production systems is a different risk category from a chatbot that answers questions. The stakes rise sharply when the agent acts autonomously, because a misconfigured permission or a poorly scoped tool can cause real damage before any human notices.
Three failure modes come up repeatedly with enterprise agent deployments. First, data over-exposure: the agent retrieves more than the requesting user is entitled to see, because no one thought to enforce row- or column-level access at the agent layer. Second, unaudited actions: the agent modifies or deletes data and there is no clean record of what ran, when, and on whose behalf. Third, privilege creep: the service principal running the agent accumulates permissions over time because it is easier to add access than to review what already exists.
The governance gap in agent deployments
Most governance frameworks were designed for human users and scheduled jobs. Agents introduce a third category: autonomous processes that act on behalf of users but with their own credentials. That gap needs an explicit policy, not an assumption that existing controls cover it.
Agent Bricks addresses this through tight integration with Unity Catalog, Databricks' centralised governance layer. Every data asset the agent touches, whether a Delta table, a volume, or a vector search index, inherits the same access controls that apply to human users. If a data analyst cannot query a particular table directly, an agent acting on that analyst's behalf cannot query it either. The permission model follows the identity, not the tool.
Audit logging works the same way. Every tool call the agent makes is captured in the Unity Catalog audit trail: which asset was accessed, which action was taken, and which user or service principal triggered it. That record is queryable, exportable, and consistent with the logs your security team already reviews for the rest of the platform. You are not maintaining a separate audit system for agents.
Agent Bricks also supports lineage tracking at the model and data level. If the agent's behaviour changes because an upstream table changed, that dependency is visible. This matters for regulated industries where you need to demonstrate not just what the model decided, but why, and on what data it was trained or grounded.
For Australian organisations working within the Australian AI regulation framework, or for teams in financial services and healthcare that face sector-specific obligations, this is not a nice-to-have. Demonstrable control over what an agent can access and a retrievable record of what it actually did are the minimum bar for deploying agents in anything beyond a sandbox.
Who should be building with Agent Bricks?
Agent Bricks is not a no-code tool. The teams who get real value from it are those with working Python skills, familiarity with the Databricks platform, and at least some exposure to LLM concepts like prompt templates, retrieval-augmented generation (RAG), and tool calling. If those terms are new, the platform will feel steep.
That said, "data engineering team" is not the only valid answer here.
The right fit
Data and ML engineering teams who already run workloads on Databricks are the natural home. They understand Unity Catalog, they know how to manage Delta tables, and they can wire up the monitoring and lineage tooling without needing a separate onboarding journey. For these teams, Agent Bricks reduces the scaffolding work considerably, the governance layer is already there, and deployment to production follows patterns they have already learned.
Platform or enablement teams building internal tools, such as a knowledge assistant for a legal or compliance function, are also well placed. The agent needs to be reliable, auditable, and scoped tightly to approved data sources. That is exactly what the Databricks stack is designed to support.
When simpler tools are the better call
If your use case is a general-purpose chatbot that does not need to query proprietary data, something like Copilot Studio or a hosted GPT wrapper will get you there faster with less infrastructure overhead. Agent Bricks earns its complexity when the agent needs to reason over your own data, respect column-level permissions, or operate inside a governed lakehouse environment.
Similarly, if your team has not yet built foundational Databricks skills, starting with agents is probably the wrong sequence. Getting comfortable with the lakehouse architecture and Unity Catalog first will make the agent development work considerably less frustrating.
Governance readiness matters as much as technical skill
Agent Bricks gives you powerful governance tools, but only if your data is already organised, catalogued, and access-controlled. Teams with a messy data foundation will hit those problems before they build anything useful.
The honest version: Agent Bricks is a strong choice for teams that are already invested in Databricks and need to build agents that touch sensitive or regulated data. For everyone else, there are lower-friction starting points.
Frequently asked questions
What are the prerequisites for building with Agent Bricks?
You need an active Databricks workspace with Unity Catalog enabled. Unity Catalog is Databricks' governance layer, and Agent Bricks depends on it to register tools, trace agent activity, and enforce access policies. Beyond that, your team needs working Python skills and familiarity with Spark or MLflow. You don't need deep LLM research experience, but engineers should understand prompt construction and have a basic feel for how retrieval-augmented generation works before they start building production agents.
How does Agent Bricks relate to Mosaic AI?
Mosaic AI is the broader umbrella for Databricks' machine learning and AI capabilities, covering model training, serving, vector search, and the Agent Framework. Agent Bricks sits within that umbrella as the structured, production-oriented layer specifically for building and deploying agents. Think of Mosaic AI as the engine bay and Agent Bricks as the assembly line that puts the parts together in a governed, repeatable way. If you've been using Mosaic AI Model Serving or Vector Search already, Agent Bricks builds directly on top of those components.
Does Agent Bricks cost extra on top of a standard Databricks subscription?
Agent Bricks itself is not a separate product with its own licence fee. You consume DBUs (Databricks Units, the platform's standard compute billing unit) when running inference, vector search queries, and evaluation jobs. The cost depends on the model you serve, the compute tier you select, and how often your agents run. Teams that size their endpoints poorly or leave evaluation clusters running idle can accumulate significant spend. Understanding DBU consumption patterns before you scale is worth the effort. The Databricks pricing explained article in this series covers the mechanics in more detail.
How do you evaluate whether an agent is actually working?
Databricks provides MLflow-based evaluation tooling that scores agent responses against labelled ground-truth datasets. The key metrics are correctness, groundedness (whether the answer is supported by the retrieved context rather than hallucinated), and relevance of the retrieved chunks. You define the evaluation dataset, run the evaluation job, and review results in the MLflow UI. That score then feeds back into the review-and-iterate loop before you promote an agent to production. Skipping this step and deploying based on informal testing is one of the most common mistakes teams make with agent projects.
Can non-engineers contribute to an Agent Bricks project?
Domain experts and analysts can contribute meaningfully, even if they don't write the agent code. They are often best placed to define the evaluation dataset, identify where the knowledge assistant is returning wrong or unhelpful answers, and specify the tool-calling logic in plain language for engineers to implement. The human-in-the-loop review step in Agent Evaluation Studio is also accessible to non-engineers. Where teams run into trouble is when they assume the entire project belongs to engineering and skip the domain input entirely, which usually produces an agent that is technically functional but practically useless.
What your team needs to get started
Agent Bricks is not a point-and-click tool for generalist users. Getting value from it requires a team that can work confidently across a few disciplines: data engineering to build and maintain the pipelines feeding your agents, ML engineering to understand model behaviour and evaluation, and enough platform knowledge to configure Unity Catalog governance correctly from the start.
That last point matters more than most teams anticipate. Agents that are built before governance is in place tend to accumulate technical debt fast. Retrofitting access controls and lineage tracking onto a system that was wired together quickly is genuinely painful work.
Governance first, agents second
The teams that get Agent Bricks into production fastest are the ones that set up Unity Catalog correctly before they build anything. Treating governance as an afterthought adds weeks of rework.
On the model side, your team should understand how retrieval-augmented generation (RAG) works, what makes a prompt reliable at scale, and how to interpret the outputs of Mosaic AI Model Evaluation. These are learnable skills, but they take time to develop in the context of your own data and your own use cases.
The good news is that Databricks' own tooling is designed to reduce the surface area your engineers need to master. Mosaic AI Agent Framework handles a lot of the orchestration complexity that teams would otherwise build themselves. The skill gap is real, but it is narrower than it would be if you were assembling this stack from open-source components.
If your team is earlier in its Databricks journey, the Databricks training hub covers the progression from lakehouse fundamentals through to production ML and AI workflows. For teams that want structured training specific to your environment, Better People's Databricks training in Australia can be scoped to where your team actually is, rather than a generic syllabus.
The practical next step is an honest skills audit. Map what your engineers know today against what Agent Bricks actually requires, identify the gaps, and build a plan that closes them before you start your first production build. Starting with a well-governed prototype on Databricks Free Edition is a low-risk way to validate the approach before committing engineering time at scale.
