Databricks Agent Bricks: What It Is and How It Works

If you learned about Agent Bricks when Databricks introduced it in 2025, your mental model is already incomplete.

The original release focused on creating domain-specific agents from a task description, generating evaluations, and optimizing quality and cost. That still matters. But Agent Bricks has since expanded into something larger: a platform for building, deploying, and governing enterprise agents across managed and custom development paths.

This guide explains what Databricks Agent Bricks means in 2026, how its main components fit together, and how to decide whether it belongs in your architecture.

TL;DR

• Agent Bricks is now Databricks' broader enterprise agent platform, not one no-code agent builder.
• Its main building paths include Knowledge Assistant, Supervisor Agent, Custom Agents, and document-focused capabilities.
• The shared foundation brings together governed data, models, tools, evaluation, deployment, permissions, and monitoring.
• It fits best when your data or AI workloads already run on Databricks and production governance matters.

What Is Databricks Agent Bricks in 2026?

Databricks Agent Bricks is a platform for building, deploying, and governing AI agents that operate on enterprise data and tools. It includes managed experiences for common agent patterns and a custom path for developers who want to bring their own code, model, framework, or toolchain.

That definition is broader than the one developers first saw.

In its June 2025 launch announcement, Databricks presented Agent Bricks as a way to create domain-specific agents by declaring a task and connecting data. The platform could build task-specific evaluations, use synthetic data where appropriate, and optimize the agent across quality and cost choices.

By the Data + AI Summit in June 2026, Databricks described Agent Bricks as a comprehensive developer platform. The scope now covers model and framework choice, enterprise context, secure execution, deployment, monitoring, and centralized control.

This evolution also explains the naming confusion around Mosaic AI Agent Framework. Custom Agents is the current name for the capability formerly called Agent Framework. It is one development path inside the larger Agent Bricks platform, not a different name for the entire platform. For the earlier architecture and terminology, see this guide to the Mosaic AI Agent Framework.

Agent Bricks is therefore not a single model, SDK, chatbot, or visual builder. It is the umbrella around several ways to create and operate agents on Databricks.

If the wider platform is new to you, start with this beginner-friendly Databricks guide before going deeper into its agent stack.

How Agent Bricks Works: Choice, Context, and Control

The easiest way to understand the platform is through three responsibilities: choice, context, and control.

1. Choice

Agent requirements change quickly. One task may need a frontier reasoning model, while another needs a smaller model with lower latency and cost. Developers may also prefer LangGraph, the OpenAI Agents SDK, or another framework instead of a vendor-specific agent loop.

Agent Bricks provides a common environment for working with different models and supported agent frameworks. Custom agents can be deployed through Databricks Apps, while managed agents cover more defined patterns.

Choice here does not mean the entire system is infrastructure-neutral. The models and frameworks can vary, but the surrounding governance, deployment, data access, and observability still depend on Databricks services.

2. Context

An enterprise agent needs more than a prompt. It may need tables governed through Unity Catalog, documents indexed for retrieval, tools exposed through functions, or external systems connected through MCP.

Agent Bricks puts these context sources close to the agent runtime. Depending on the path, a developer can use Databricks data, AI Search indexes, Unity Catalog functions, MCP services, managed memory, and document-processing capabilities. The exact options vary by component.

For example, imagine an internal support assistant. It needs product documentation for grounded answers, ticket data for account-specific context, and permission checks so one employee cannot retrieve another team's restricted cases. The useful part is not merely generating a response. It is retrieving the right context and applying the user's permissions throughout the request.

3. Control

Agents can call tools, access sensitive information, generate code, and incur unpredictable model costs. That makes control a runtime requirement rather than an afterthought.

The Agent Bricks platform connects agent operations with Unity Catalog permissions, MLflow tracing and evaluation, managed deployment, and AI Gateway controls. These capabilities help teams inspect what an agent did, govern what it can access, and monitor behavior after deployment. They do not automatically make an agent accurate or secure; developers still need appropriate permissions, representative evaluations, and operational guardrails.

For more background, this overview explains how the wider Databricks platform fits together.

Which Agent Bricks Path Should You Choose?

Do not start with the product menu. Start with the task. The table below maps common workloads to the most relevant path.

Path	Best starting use case	Developer control	Main inputs	Key boundary
Knowledge Assistant	Cited question answering over company documents	Managed	Documents, a volume or table, or an AI Search index	Designed for knowledge retrieval, not arbitrary business workflows
Supervisor Agent	Coordinating several agents and tools behind one endpoint	Managed orchestration	Existing agents, functions, tables, indexes, dashboards, or MCP tools	Orchestration still requires permissions, testing, and clear tool descriptions
Custom Agents	Bespoke agent logic, tools, models, and frameworks	High	Application code, evaluation data, tools, deployment configuration	More flexibility means more engineering responsibility
Document capabilities	Parsing, extraction, and classification workflows	Task-specific	Files, schemas, SQL functions, and target tables	Availability and limits vary by capability

Knowledge Assistant

Knowledge Assistant is the most direct path when the job is answering questions over documents with citations. It manages much of the ingestion, retrieval, endpoint, and improvement workflow. Subject-matter experts can add example questions and guidance when an answer needs correction.

Use it for product documentation, internal policies, research libraries, or support knowledge bases. Do not choose it merely because the interface is convenient if the real requirement is a multi-step workflow that changes external systems.

Supervisor Agent

Supervisor Agent coordinates existing agents and tools. A supervisor can route a request to a Genie Agent, Knowledge Assistant, model-serving endpoint, Unity Catalog function, MCP service, or supported custom agent, then synthesize the result.

This is useful when one request crosses domains. A customer operations assistant might need a policy agent, an order-data tool, and a ticketing integration. The supervisor provides coordination, but it does not repair a weak subagent or grant access the user does not already have.

Custom Agents

Custom Agents is the developer-first path. Teams can keep their preferred frameworks and development workflows, evaluate the agent, and deploy it as a governed Databricks App.

Choose this when the behavior cannot be expressed through a managed agent pattern, when you need custom tools or control flow, or when agent code must fit an existing CI/CD process.

Document capabilities

Not every intelligent workflow needs a conversational agent. Agent Bricks also includes document-focused capabilities for turning unstructured files into data that applications, pipelines, or other agents can use.

For example, ai_parse_document converts document content into structured output for downstream processing. Information Extraction can map content such as contracts, invoices, or forms into a defined schema, while Classification can assign predefined categories to documents or text.

These capabilities can run as part of a larger agent architecture, but they are also useful on their own. If the real job is “extract these six fields from every invoice,” a focused extraction pipeline is easier to evaluate than a general-purpose chat agent. Check each capability's current release state, supported inputs, schema rules, and token limits before choosing it.

From Use Case to Production: The Agent Bricks Workflow

The screens and APIs differ across components, but the engineering sequence remains broadly consistent.

1. Define one task and its success criteria

“Build a support agent” is too broad. “Answer product-configuration questions using the current documentation and cite the source” is testable. Define unacceptable behavior as well: unsupported answers, exposure of restricted data, or tool calls without confirmation.

2. Connect governed data and tools

Identify the tables, documents, indexes, functions, and external services the agent requires. Then verify data quality, ownership, freshness, and permissions. An agent cannot reason its way around missing context or contradictory source material.

3. Choose the narrowest suitable path

Use a managed experience when the workload matches it. Choose Custom Agents when the job needs bespoke logic or framework control. Add a supervisor only when a request genuinely requires coordination across specialized agents or tools.

4. Evaluate with representative inputs

Test real question patterns, edge cases, permission boundaries, tool failures, and ambiguous requests. Use traces to identify whether a failure came from retrieval, reasoning, a tool, or the source data. Domain experts should review examples that general-purpose evaluators cannot judge reliably.

5. Deploy with least privilege, then monitor

Grant only the permissions required by the agent and its users. After deployment, monitor quality, latency, tool behavior, and cost. Production feedback should become new evaluation cases rather than a collection of one-off prompt patches.

Agent Bricks can reduce the amount of infrastructure a team assembles manually. It does not remove the work of defining the task, preparing context, testing behavior, or controlling access.

When Agent Bricks Makes Sense—and When It Does Not

Agent Bricks is a strong fit when:

• your enterprise data or analytics workloads already run on Databricks;
• agents need governed access to tables, documents, models, and tools;
• evaluation, tracing, managed deployment, and monitoring are production requirements;
• several models or agent frameworks need a shared control plane;
• domain experts will provide examples and feedback.

It may not be the first choice when:

• you are building a small prototype outside the Databricks ecosystem;
• the required component is unavailable in your cloud region or workspace configuration;
• infrastructure portability matters more than deep Databricks integration;
• your data, permissions, ownership, or evaluation criteria are not ready;
• a deterministic workflow would solve the task more safely than an agent.

The last point is easy to miss. Not every automation problem requires an LLM to plan and choose tools. If the process has fixed rules and predictable inputs, a conventional application or workflow engine may be cheaper, easier to test, and easier to audit.

Prerequisites and Current Limitations

Agent Bricks is a platform umbrella, so there is no single prerequisite list for every component. Common requirements include a supported region, Unity Catalog, serverless compute, Model Serving access, appropriate object permissions, and a serverless usage policy with a nonzero budget. Confirm the documentation for the specific path you select.

The limits are also component-specific. As of August 13, 2026:

• Knowledge Assistant supports selected document formats and skips files larger than 100 MB. PDF, Word, and PowerPoint files over 500 pages are also skipped. Its current documentation lists the supported inputs and embedding models.
• A Supervisor Agent can use up to 50 agents and tools. Its web-search capability also has model, region, and workspace-security restrictions documented in the Supervisor Agent limitations.
• Some older Custom LLM and Information Extraction pages are marked legacy or beta, while newer document and custom-agent capabilities have different release states.
• Pricing depends on the selected capabilities, cloud, region, models, compute, and usage. Check the current Agent Bricks pricing page instead of relying on a universal per-agent estimate.

These details will change faster than the platform's basic architecture. Treat region lists, quotas, supported models, and preview status as publication-date facts—not permanent design guarantees.

Frequently Asked Questions

Is Databricks Agent Bricks the same as Mosaic AI Agent Framework?

No. Custom Agents was formerly called Agent Framework, but Custom Agents is now one path within the broader Agent Bricks platform. Agent Bricks also includes managed agents, document capabilities, model and tool access, evaluation, deployment, and governance services.

Does Agent Bricks require coding?

Not always. Knowledge Assistant and Supervisor Agent provide managed creation experiences for defined workloads. Custom Agents is intended for developers who need their own code, framework, tools, or application behavior. Data preparation, permissions, evaluation, and integration work are still required even when the agent itself is configured through a UI.

Can Agent Bricks use LangGraph or the OpenAI Agents SDK?

Yes. Databricks' 2026 platform announcement and Custom Agents documentation describe support for popular agent frameworks, including LangGraph and the OpenAI Agents SDK. Verify the currently supported versions and deployment guidance before implementation.

Is Agent Bricks generally available everywhere?

There is no safe platform-wide yes or no. Several major components have reached general availability, while individual features can remain in preview or have cloud, region, security, and model restrictions. Check the documentation for the exact component and workspace before designing around it.

The Practical Takeaway

The most useful way to think about Agent Bricks is not “a tool that builds an agent for me.” It is a set of managed and custom paths for running agents with Databricks data, evaluation, deployment, and governance around them.

Start with one governed workload. Define what a correct result looks like. Then choose the narrowest Agent Bricks path that meets the requirement.

If you are still building the foundation, continue with the 2026 data engineering learning path. If your team already uses Databricks and needs to move an agent from prototype to a governed production workflow, Lucent Innovation can help assess the architecture and implementation path.