What the Databricks agent features actually give you

The question we get on nearly every AI call now is some version of: Databricks has agent features built in — can we just use those?

Mostly yes. The platform has quietly absorbed the parts of agent engineering that used to eat the first six weeks of a project. What it has not absorbed is the part that actually decides whether the thing works, and teams keep discovering that in the wrong order.

So here is the honest split, from engagements where we have shipped on this stack.

What the platform genuinely gives you

Tools as governed functions. This is the feature that matters most and gets discussed least. When a tool is a function registered in Unity Catalog, the question "what is this agent allowed to touch?" has the same answer as "what is this service principal allowed to touch?" — and it is answered by your access model, not by your prompt. Every other approach eventually reduces to hoping the model does not call something it shouldn't.

Retrieval over governed sources. Vector Search indexes that sit on Delta tables and sync as the table changes. The win is not the ANN algorithm, which is a commodity. The win is that the index inherits the lineage and permissions of the table underneath it, so "which documents could this user's answer have come from" is an answerable question.

Serving that someone else operates. Authentication, autoscaling, request logging and rollback on an endpoint you did not have to build. Teams routinely underestimate this one because it is invisible when it works.

Tracing and evaluation. MLflow captures the full trace of a run — every tool call, every retrieved chunk, every intermediate response — and lets you attach judges and run them as a gate. This is the piece we would least want to rebuild by hand, and the piece most teams skip until the first production incident makes it urgent.

A trace you did not capture is an outage you cannot explain. Turn tracing on during the prototype, not after the first escalation.

What you still own

Three of those deserve more than a table row.

1. The tool boundary is a design decision, not a wrapper

A tool is an API you are exposing to a non-deterministic caller. The useful ones are narrow, idempotent where possible, and honest in their failure modes. We see teams expose run_sql(query) and call it a tool. That is not a tool, it is a shell — the model now owns your query surface, and your audit story is "it generated something".

Compare:

-- A tool: narrow, parameterised, and the grant is the boundary.
CREATE OR REPLACE FUNCTION finance.open_invoices_for_account(
  account_id STRING,
  as_of DATE
)
RETURNS TABLE (invoice_id STRING, amount DECIMAL(18,2), due_date DATE)
COMMENT 'Open invoices for one account as of a date. Read-only.'
RETURN
  SELECT invoice_id, amount, due_date
  FROM finance.gold.invoices
  WHERE account_id = open_invoices_for_account.account_id
    AND status = 'OPEN'
    AND invoice_date <= open_invoices_for_account.as_of;

The COMMENT is not documentation, it is part of the prompt — the model reads it to decide when to call this. Write it like an interface contract, because it is one.

2. Nobody can hand you the eval set

Every platform in this space will give you judges, metrics and dashboards. None of them can tell you what a correct answer looks like in your business. That comes from sitting with the three people who currently answer these questions by hand and writing down forty real cases, including the ones where the right answer is "I don't know, escalate".

Forty labelled cases is roughly a day of work and it is the highest-leverage day in the whole project. We have never regretted spending it. We have repeatedly been called in to rescue projects that skipped it and had no way to tell whether a change was an improvement.

3. Loops need a budget, enforced in code

An agent that can call tools can call them forever. Set a hard ceiling on iterations, a token budget per request, and a wall-clock timeout — then enforce them in the orchestration layer rather than asking the model to behave. And put a human checkpoint in front of anything that writes. Not a confirmation dialog in a demo; an actual interrupt in the graph that can wait hours for approval and resume.

The part that is genuinely easier now

Two years ago, a governed agent on enterprise data meant assembling six components and owning the integration between all of them. Today the integration is the platform's problem, and a competent team can get a traced, evaluated, permission-scoped agent serving real traffic in weeks rather than quarters.

That is a real change. It just moves the bottleneck to where it always should have been: knowing what the thing is supposed to do, and being able to prove that it does.

One practical note — feature names and GA status in this corner of Databricks move every few months. Treat specific product names here as a snapshot, check the current docs before you commit them to an architecture document, and design against the capability rather than the brand.

If you are starting next week

1. Pick one question with a known right answer and a user who is waiting for it.
2. Build retrieval only. No agent loop. Measure whether the answer is in the retrieved context at all — if it is not, no amount of agent architecture will save you.
3. Add one governed function as a tool. Still no loop.
4. Write the forty eval cases. Run them. Record the number.
5. Only now consider a loop, and only if the question genuinely needs multiple steps.

Every step there is useful on its own, which is the property you want when the budget conversation happens in month three.