Databricks

Databricks builds its AI stack on top of the same Lakehouse foundation it uses for data engineering: Unity Catalog for governance, Delta Lake for storage. Mosaic AI is the GenAI layer - Foundation Model APIs, Vector Search, an AI Gateway - and MLflow extends across both classic ML and agent evaluation. Nothing here is a separately governed product; features, models, and vector indexes inherit the same access control and lineage as every other table in the workspace.

That's the platform's core trade-off. It's the most complete option for teams that already own their ML lifecycle on Databricks and want agent tooling built the same way. It is not a managed, minimal-setup GenAI product - there's no low-code agent builder and no packaged knowledge-base service. Everything is code-first, run by engineering teams comfortable in notebooks and MLflow.

The Three-Layer Stack

Each layer builds on the one below it. Feature Store and MLflow Registry (Data Science & ML) feed Foundation Model fine-tuning and Vector Search (Mosaic AI), which in turn back the tools and evaluation harness agents use (Agentic AI). The practical effect: an agent's tools, retrieval index, and evaluation history all trace back through the same lineage graph as a traditional ML model.

---

Built-In AI Capabilities

Data Science & ML

This is Databricks' longest-standing strength - it predates the GenAI push by several years and is the most mature layer in the stack.

Generative AI (Mosaic AI)

Agentic AI

This is the newest layer, and it reads that way - less settled than the ML stack above, with an API surface still moving.

Databricks also ships AI/BI Genie, a natural-language query interface over governed Lakehouse data for business users. It sits outside the three layers above - no agent needs to be built to use it - and is the closest thing Databricks has to a low-code, ask-a-question-of-your-data experience.

---

Available Models

The external gateway matters more than the provisioned list suggests: it means the provisioned catalogue isn't a ceiling. Route to a frontier closed model (GPT, Claude) through the same governed endpoint when the open models aren't sufficient for the task, without adding a second vendor integration.

---

Custom AI Enablement: Agents as Unity Catalog Functions

The pattern that distinguishes Databricks from most other platforms: instead of hand-wiring tool definitions and a separate authorization layer, register a function in Unity Catalog and expose it to an agent directly. Tool access then inherits the table and function permissions already defined in Unity Catalog.

from databricks.agents import Agent, tool

@tool
def get_customer_data(customer_id: str) -> dict:
    """Retrieve customer information from the data warehouse."""
    row = spark.sql(
        f"SELECT * FROM gold.dim_customer WHERE id = '{customer_id}'"
    ).first()
    return row.asDict()

@tool
def create_support_ticket(customer_id: str, issue: str) -> str:
    """Create a support ticket for a customer and return the ticket ID."""
    ticket_id = ticketing_system.create(customer_id, issue)
    return ticket_id

agent = Agent(
    model="databricks-dbrx-instruct",
    tools=[get_customer_data, create_support_ticket],
    system_prompt=(
        "You are a customer service agent. Look up customer details "
        "before answering, and open a support ticket for unresolved issues."
    ),
)

Evaluate the agent through MLflow the same way you'd evaluate a model - as a versioned, tracked artifact, not a one-off script.

---

Cost Model

Databricks AI services bill on provisioned throughput or per-token, depending on the service:

• Foundation Model APIs - pay-as-you-go per token, or provisioned throughput for predictable, high-volume workloads
• Vector Search - priced separately from model serving, scaling with index size and query volume
• Model Serving (custom/fine-tuned models) - billed on underlying compute (GPU/CPU hours), not per-token

---

When Databricks is the Right Choice

• Your ML lifecycle already runs on Databricks - features, training, and registry stay in one governed platform instead of split across tools
• You need model flexibility - provisioned open models plus an external gateway to closed models, without vendor lock-in
• Tool governance should ride on data governance - Unity Catalog functions as agent tools means one permission model, not two
• Engineering teams are comfortable working code-first - notebooks, MLflow, and the Agent Framework are all pro-code

When Databricks is Not the Right Choice

• You need a managed, minimal-setup knowledge/RAG layer - a service that packages retrieval, chunking, and permission sync for you will get there faster
• Business users need to build or modify agents without writing code - there's no visual, low-code agent builder in this stack
• You want one dedicated safety/guardrails product to enable and move on - Databricks assembles guardrails from AI Gateway and Lakehouse Monitoring rather than shipping a single consolidated content-safety service

---

Key Takeaways

• Databricks' AI maturity comes from reusing Unity Catalog and Delta Lake for governance - features, models, and vector indexes inherit the same access control and lineage as the rest of the platform, rather than being bolted on separately.
• The Data Science & ML layer (notebooks, Feature Store, MLflow) is the most mature part of the stack. Agentic AI (Agent Framework, orchestration, guardrails) is newer and less settled - expect the API surface to keep changing.
• Tool calling through Unity Catalog functions is the standout differentiator: agent tool access inherits existing table and function permissions instead of needing a parallel authorization system.
• Guardrails are assembled, not packaged - AI Gateway and Lakehouse Monitoring cover routing, rate limiting, and drift detection, but there's no single dedicated content-safety product to switch on.
• The external model gateway (OpenAI, Anthropic, Google, Cohere, Bedrock) means the provisioned model list isn't a ceiling - route to frontier closed models through the same governed endpoint when open models fall short.
• Foundation Model serving costs scale with token usage, not a flat subscription. Track consumption in staging before production rollout.