We build agents inside the Databricks Data Intelligence Platform: Agent Bricks or your own framework, tools registered in Unity Catalog, retrieval over governed Delta tables, and every request traced in MLflow. Guardrails, eval gates and a human checkpoint come as standard - so what you get is production, not another pilot.
Building an agent that works in a notebook is easy now. Building one you would let touch a customer, a system or a dollar is a different problem - and it is where most agent projects stall, even on a platform as capable as Databricks. These are the four walls they hit, and the Databricks answer to each.
The demo works because someone exported tables to a vector database outside Unity Catalog. Now the data is stale, ungoverned and outside every access control you built. That copy is the whole risk.
Databricks AI Search over governed DeltaAgents usually run as one service principal that can see everything. So the agent answers questions the user was never entitled to ask - and does it at machine speed, across every user at once.
On-behalf-of-user authorization“It seemed to work in the demo” is not a release criterion. Without an evaluation dataset, judges and a defined bar, you are shipping on vibes - and you find out in production.
MLflow evaluation, as a gateWhen an agent gives a wrong answer or takes a strange action, the trace is the only record. No tracing, no monitoring - no way to debug it, and no way to defend it to a regulator or a board.
MLflow tracing, stored in Unity CatalogWe design, build and ship production AI agents natively on Databricks. Not adjacent to it, not reading an export of it - inside it, where the permissions, the lineage and the audit trail already live. Accelerated by our own agentic framework: Forge, Blocks and Sentinel.
Where a managed agent fits, we use it: Knowledge Assistant for grounded document Q&A with citations, Supervisor Agent to orchestrate several agents and tools. Where the problem needs real code, we author a custom agent on the MLflow ResponsesAgent interface - LangGraph, LangChain, LlamaIndex or the OpenAI Agents SDK - and deploy it to Model Serving or Databricks Apps.
Retrieval runs on Databricks AI Search indexes that sync from your Delta tables, with hybrid keyword-plus-vector ranking. Structured questions go through Genie and your metric definitions. Documents become rows with ai_parse_document and ai_extract. Nothing leaves the platform to make the agent work.
Tools are Unity Catalog functions and MCP services with EXECUTE grants, not free-form code. Agents run on behalf of the user who asked, so row filters and column masks apply exactly as they would to that person in a SQL editor. Anything irreversible stops for a human.
An evaluation dataset in Unity Catalog, MLflow judges for correctness, groundedness, safety and your own written guidelines, plus adversarial red-teaming - all of it a gate, not a report. Once live, registered scorers keep sampling real traces, so drift is caught by us, not by a customer.
Most agent architectures are assembled from six or seven vendors and glued together with credentials. On Databricks the whole stack sits inside one governance boundary: every model, tool, index, function and MCP server is a Unity Catalog object with an owner, a grant and an audit trail. Choose a layer to see what actually runs there - and what we build on it.
An agent nobody opens is a research project. We ship the interface with the agent: a Databricks App for an internal audience, a served endpoint your product calls, Genie One for business users who want to ask questions of governed data directly, or the agent surfaced inside Slack, Teams or a support console. Databricks Apps run serverless Python - Streamlit, Dash, Gradio, Shiny, Flask or FastAPI - with the signed-in user’s identity carried through, so the app sees exactly what that person is entitled to see.
What we do here. Design the interaction, not just the API - where the agent asks before it acts, how it shows its sources, and what a user does when it is wrong. The fastest route to a real answer is usually a Databricks App in front of a governed agent.
Databricks now gives you both, and choosing correctly is most of the value. Knowledge Assistant builds a cited, document-grounded assistant with an instructed retriever and improves from expert feedback rather than prompt archaeology. Supervisor Agent - generally available since February 2026 - routes a question across Genie Agents, Knowledge Assistants, Unity Catalog functions, MCP servers and your own agent endpoints, and learns its routing from natural-language guidance. When the problem needs bespoke control flow, we author a custom agent on the MLflow ResponsesAgent interface - the one Databricks recommends - which gives streaming, multi-agent support, tool-call confirmation and automatic tracing for free, in LangGraph, LangChain, LlamaIndex or the OpenAI Agents SDK.
What we do here. Pick the cheapest thing that will hold. Most teams over-build: a Knowledge Assistant answers the question a six-week custom RAG project was scoped to answer. We reserve custom agents for the cases where control flow, side effects or latency genuinely demand them - and then Forge supplies the scaffolding so week one is the hard part, not the setup.
This is the layer that separates a governed agent from a risky one. On Databricks a tool is not a Python function someone wired up - it is a Unity Catalog function or an MCP Service addressed by its three-level name, with EXECUTE grants, tool-level selection and policies attached. Databricks hosts managed MCP servers for AI Search indexes, Genie Agents, Unity Catalog functions and Databricks SQL, and managed OAuth connectors reach outward to systems like GitHub, Jira, Confluence, SharePoint, Google Drive and Slack - with credentials held centrally instead of pasted into an agent’s config.
What we do here. Write the tool surface deliberately - narrow, typed, individually granted, and reviewed like an API rather than accumulated like a prompt. Our Blocks library supplies the patterns we have already proven: retrieval tools, write-back tools with confirmation, and the routing logic between them.
Databricks AI Search (formerly Databricks Vector Search) keeps an index in sync with a Delta table, so the agent’s knowledge moves when your data moves - no nightly export, no drift between the answer and the warehouse. It does hybrid keyword and vector retrieval, merging both rankings, and offers a real cost-versus-latency choice: standard endpoints answer in tens of milliseconds, storage-optimized endpoints scale past a billion vectors and index far faster for a fraction of the cost. For structured questions, Genie Agents hold the trusted tables, metrics and business rules so “revenue” means the same thing to the agent as to finance. And unstructured input becomes governed rows through ai_parse_document, ai_extract and ai_classify.
What we do here. Almost every “the agent is not accurate enough” problem is a retrieval problem, so we treat it as one: chunking, hybrid weighting, filters and a retrieval eval set measured on its own before anyone blames the model. This is also where this page meets Modern Data Engineering - same team, one layer down.
Databricks serves frontier models from Anthropic, OpenAI and Google alongside strong open models, all through one governed interface, plus external providers and your own fine-tuned models on the same endpoints. Consumption is a real design decision rather than a detail: pay-per-token for variable traffic, a priority tier for latency-sensitive interactive use, provisioned throughput when load is steady, and AI Functions such as ai_query when the job is reasoning over a whole table rather than one request at a time.
What we do here. Keep the model behind an interface so it can be swapped when a better or cheaper one lands - then prove the swap with the same evaluation set rather than a vibe check. Nine times out of ten the smaller model passes, and the bill falls.
Databricks frames this in three parts and so do we. Assets: every model, function, index, MCP server and connection is a Unity Catalog securable with an owner, grants, lineage and audit - and attribute-based access control now applies row filters and column masks from governed tags rather than per-table grants. Traffic: Unity AI Gateway (Beta) sits in front of every model and MCP call to enforce rate limits, budgets, usage tracking and service policies - content-and-identity rules that return allow, deny, or ask a human, and that fail closed. Quality: MLflow 3 traces every request, evaluates against judges and your own guidelines, and keeps scoring a sample of live traffic after launch.
What we do here. This is where Sentinel lives - our production-readiness layer on top of these primitives: the eval gate an agent has to clear, the guardrail set, the trace and monitoring wiring, and the evidence pack that lets a risk committee sign off. See AI Governance.
A tool call, a vector lookup, a SQL query and a model invocation are all governed by the same catalog, the same grants and the same audit log as the analyst sitting next to you. That is what makes “governed agent” a fact you can evidence rather than a phrase in a deck - and it is why we build here rather than bolting an agent onto the side of your warehouse.
A request arrives. Before the agent sees it, a gateway policy checks it. The agent plans, calls a tool it has been granted, and reads governed data in place - under the permissions of the person who asked, not a service account that can see everything. Anything irreversible stops for a human. The response is checked again on the way out, and the whole thing is one trace. Run it below, then try to break it.
Nearly every agent worth funding is a variation on one of these. Knowing which one you are actually building - before the first sprint - is the difference between six weeks and six months. Each maps onto specific Databricks primitives, which is why they can be estimated honestly.
Ask a question in plain language, get an answer grounded in your own documents with citations you can click through to the source. The workhorse pattern - policies, manuals, contracts, tickets, an internal wiki nobody can search.
Databricks AI Search when you need control of chunking and filters.Business questions answered in SQL over governed tables - with your definitions of revenue, churn and margin, not the model’s guess at them. It answers the questions that currently queue behind a data analyst.
Contracts, claims, invoices, statements and scanned forms turned into structured, governed rows - at volume, with a confidence score and a review queue for the ones that need a human.
ai_parse_document, ai_extract and ai_classify running over Unity Catalog volumes and landing straight into Delta.One front door over several specialists: a question about numbers goes to the analytics agent, a question about policy to the knowledge agent, a request to do something to the action agent. The user never has to know which is which.
An agent that does things, not just says things - raises the ticket, adjusts the record, triggers the workflow. Which is exactly why it needs scoped tools, a policy on every call and a person standing at anything irreversible.
ask and route to a human approver.Some jobs are not a conversation. Classify two million support tickets, summarise every contract, score a whole customer base for risk - reasoning applied as a data pipeline, at a fraction of the per-request cost.
ai_query and the AI Functions family running as a Lakeflow job, output landing in a governed Delta table.Most firms bring principles to agentic AI. We bring tooling - three proprietary components that turn agent-building from a bespoke research project into a repeatable production discipline. On Databricks they do not replace the platform; they sit on top of it and take the parts every project would otherwise rebuild.
Accelerates multi-agent development - the scaffolding, orchestration and plumbing that otherwise gets rebuilt from scratch every time, so we start at the hard part instead of the setup.
Reusable agentic patterns - the proven building blocks for retrieval, tool use, routing and multi-agent coordination, so each new agent stands on patterns that already work in production.
Production readiness - guardrails, evaluation gates, observability and governance in one layer. The thing that decides whether an agent is fit to go live, and keeps watching after it does.
Sentinel expresses our AI Governance method
You are not paying us to discover how to build agents on your project - that discovery is already in the framework. You are paying for agents that reach production faster because the patterns are proven, and stay in production because Sentinel governs them against the platform’s own primitives rather than a parallel set of ours. Sentinel is also where this page meets our AI Governance method - the same production-readiness discipline, expressed as tooling.
Forge, Blocks and Sentinel are Focaloid’s own agentic framework. On Databricks they compose with the platform rather than competing with it.
Sentinel is the gate between “it works on my machine” and “it is serving customers”. The agent moves left to right and does not advance until each stage clears. If it fails, it goes back, not forward. After launch the same scorers keep running against a sample of live traces - so an agent that passed and then drifts gets caught by a scorer rather than by a customer.
Not a discovery phase that produces a slide deck. We pick one use case that matters, build it properly in your workspace against your governance, and hand it over running. The evaluation set and the guardrails exist from week one - that is the whole reason the timeline holds.
What you have, what is actually governed, and which use case is worth the quarter. We look at your Unity Catalog, your data, and any agent work already underway.
The agent gets built - and so does the eval set, the tool grants and the guardrail policy, in the same sprint. Not bolted on afterwards, which is where quarters go to die.
Judges and written guidelines, adversarial red-teaming, the human checkpoints agreed with your risk people, and tracing wired end to end. The agent either clears the bar or goes back.
Deployed, monitored, documented - and your team can run and extend it without us. We would rather be asked back for the second agent than be needed for the first one.
Shorter and longer both exist. A well-scoped Knowledge Assistant over documents you already hold can be live in weeks. A multi-agent system that takes actions in regulated workflows takes longer, and should. What does not change is the order: governance and evaluation are designed in at the start, because retrofitting them is what turns a six-week build into a six-month one.
We build agents in two places, and it is a real choice rather than a duplicate offering. AI Studio’s Agentic AI Development builds on an open or bespoke stack - best tools for the problem, any cloud. This builds natively inside Databricks, so the agent inherits governance you have already paid for instead of needing its own.
The expertise is identical - only the home differs. If your stack is open, or your data does not live in Databricks, that is Agentic AI Development in AI Studio.
The Databricks-native runtime, the frameworks we author in, our own Forge, Blocks and Sentinel across the top, and the evaluation and guardrail tooling Sentinel orchestrates. Representative rather than exhaustive - filter by layer.
Databricks moves quickly and renames as it goes - AI Search was Vector Search until mid-2026, and the Mosaic AI prefix has largely been retired. We keep this page current because using last year’s product names is the fastest way to tell a client you have not shipped recently.
A copilot over equipment manuals, asset data and floor plans, answering technicians in the field - grounded in governed data, not a scraped document dump.
An autonomous agent that researches CVEs and applies verified, auditable remediations - the kind of authority that only works with scoped tools and a human checkpoint.
A multi-agent system tracking sentiment and narrative across thousands of sources in real time - orchestration at production scale.
Turns retirement simulations into explainable, advisor-ready insight - regulated-industry AI where the explanation matters as much as the answer.
Anonymized production engagements across facilities, security, media and wealth. Named references and metrics available under NDA.
Agents live in the field today - a technician copilot, an autonomous security agent, a real-time media system. We have solved the hard part, which is not the demo.
Forge, Blocks and Sentinel mean agents reach production faster and stay there. They compose with Databricks rather than duplicating it - you buy a discipline, not a research project on your budget.
Because we also build governed lakehouses and the Unity Catalog model on top of them, the agent inherits real governance instead of a parallel one. Most agent shops govern a copy; ours reads governed data in place.
Databricks ships and renames constantly. We track it - AI Search, service policies, on-behalf-of-user authorization, MLflow 3 - so you get the architecture that is right now, not the one a blog post described eighteen months ago.
This is the lead page of the cluster. An agent is only as governed as the platform beneath it, and only as good as the data it reads. Where it points next:
The Unity Catalog model that governs these agents - grants, lineage, masking and audit. Without it, “governed agent” is just a phrase in a deck.
The control plane →← Beneath thatThe governed Delta tables the agent reads from, and the pipelines that keep them fresh - built by the same team that builds the agent.
The foundation →Across →The same capability on an open stack, when your data does not live in Databricks - AI Studio’s agent build. Same team, same framework, different home.
AI Studio →Sideways: AI Governance is the method Sentinel expresses - the phased lifecycle, the EU AI Act readiness, the evidence packs.
Usually both, in that order. If the job is document-grounded question answering, Knowledge Assistant gets you a cited, evaluated assistant far faster than a hand-rolled RAG pipeline, and it improves from expert feedback rather than prompt tinkering. If you need several specialists behind one front door, Supervisor Agent handles the routing. We build a custom agent on the MLflow ResponsesAgent interface when control flow, side effects, latency or a non-standard interaction genuinely require it - not by default. The honest version of this answer is that most teams start custom and later discover the declarative option would have done.
Concretely: tools are Unity Catalog functions and MCP services with EXECUTE grants, so you can list exactly what an agent may do. The agent can be deployed with on-behalf-of-user authorization, so when Sam asks a question the query runs as Sam - row filters and column masks apply exactly as they would in a SQL editor. Its access token is downscoped to only the APIs the agent declares. Every read and action lands in the same audit surface you already query for humans. When someone asks “what could this agent see?”, you answer from the catalog rather than from memory. That is the Governed Data Platform.
Yes, and you should know it before you design. Row and column level permissions are not enforced on AI Search indexes the way they are on tables - if a chunk is in the index, the index will return it, so filtering has to be done deliberately through the query filter API and how you partition indexes. Gateway service policies also evaluate one message at a time, so a multi-turn attack that builds across a conversation is not caught by policy alone; that is what conversation-level judges in monitoring are for. We design around both from day one. Any consultancy telling you Unity Catalog handles all of it automatically has not shipped one.
No. Databricks explicitly supports agents authored in LangGraph, LangChain, LlamaIndex and the OpenAI Agents SDK, and the ResponsesAgent interface is framework-agnostic - it is the contract between your code and the platform, not a library you have to write in. Model choice is equally portable: frontier models, open models and your own fine-tunes all sit behind the same serving interface. The commitment is to the governed platform underneath, not to a particular agent library on top.
It passes an evaluation gate before it goes live and keeps passing after. That means an evaluation dataset stored as a governed Unity Catalog table, MLflow judges for correctness, groundedness, relevance, safety and tool-call correctness, plus a Guidelines judge that turns your own written rules into automated pass/fail - and adversarial red-teaming on top. Judges can be aligned against your reviewers' real ratings, so the bar reflects what your experts actually think rather than a generic notion of quality. If it fails, it goes back to be fixed, not forward.
Every request is traced in MLflow, and registered scorers keep running against a sample of live traffic - typically everything for safety checks and a smaller sample for the expensive judges. Assessments are written back onto the traces, so a quality drop shows up as a measurable trend rather than a support ticket. Conversation-level judges catch the failures that only appear across a whole session: frustration, lost context, a role slipping. That monitoring loop is Sentinel's job, and it is the part most agent projects skip.
Same capability, different home. AI Studio builds agents on an open or bespoke stack - any cloud, best tools for the job. This builds them inside Databricks, so the agent inherits the governance you already run. Same team, same Forge / Blocks / Sentinel framework. See Agentic AI Development.
It depends on the pattern, and the pattern is the lever. Interactive agents bill per token, with a priority tier when latency matters and provisioned throughput once load is steady. Batch reasoning through ai_query is dramatically cheaper per record than the same work done one request at a time. Retrieval has a real cost-versus-latency choice too: standard AI Search endpoints answer in tens of milliseconds, storage-optimized endpoints trade some latency for far larger scale and substantially lower cost. We size this in the readiness review rather than after the first invoice, and we re-test smaller models against the same eval set - they usually pass.
Then this is not the right page. AI Studio's Agentic AI Development builds the same agents on an open stack, with the same team and the same framework. This page is specifically for teams who have standardized on Databricks and want the agent native to it rather than beside it. If you are mid-migration, we do both - that conversation usually starts at Modern Data Engineering.
Start with an agent readiness review. We look at what you have built or want to build, where it sits against production on your Databricks workspace - governance, tool grants, evaluation, tracing - and what it takes to ship it with Sentinel behind it. The fastest route from a promising demo to an agent you would defend in a board meeting.