The demo was never the hard part. Shipping it was.
Almost every organisation we meet has an AI pilot that worked. It answered the questions in the meeting, everyone was impressed, and it is still a notebook eleven months later. What stands between that notebook and production is dull: durable execution, memory that survives a restart, governed access to tools, traces you can debug from, and an agreed definition of good enough. Agent Bricks is Databricks’ attempt to supply all five.
Six things a notebook does not have.
This is the list we work through with every client who has a stalled pilot. It is rarely the model, and it is never the prompt.
Works until something moves
- A crash or a restart loses the run and everything it had worked out.
- No memory, so every conversation starts from nothing.
- Credentials pasted into a cell, held by whoever wrote it.
- No record of what the agent did, so a bad answer cannot be diagnosed.
- “It seems good” as the quality standard.
- Spend discovered at the end of the month.
Boring, and non-negotiable
- Durable execution, so a run survives a restart or a crash.
- Sessions and long-term memory, stored and governed.
- Registered, permissioned tools instead of ambient credentials.
- A trace of every step, tied to the output it produced.
- A written numeric bar, measured on a fixed set of real cases.
- Rate limits, budgets and hard caps before the first week of traffic.
What Databricks supplies, piece by piece.
Agent Bricks is described as an agent developer platform rather than a framework, and the distinction is real: it hosts agents built with whatever framework or harness you prefer, and supplies the surrounding machinery.
| Piece | What it does | Why it matters |
|---|---|---|
| Agent Runtime | Hosts agents built with any framework or harness, stateful or stateless. | You are not betting the project on one framework being the right one in a year. |
| AgentKit | Adds durable execution, so runs survive restarts and crashes. | A long-running task that loses its place on a deploy is not a production system. |
| Agent Server | Built on DurableAgentServer: synchronous, streaming and background runs, with crash recovery. | Background runs are what let an agent do ten minutes of work without a browser waiting on it. |
| Memory and sessions | Conversation state and long-term memory, stored in Lakebase-backed stores. | An agent with no memory re-asks what it was told, which is how users stop using it. |
| Databricks Sandbox | An isolated environment where an agent runs the code it writes. | Letting a model execute code is useful and must be contained. This is the containment. |
| MCP servers and tools | Databricks-managed, custom and external MCP servers; Unity Catalog functions published as tools; HTTP connections. Includes a Genie One MCP server for natural-language questions over governed data. | Every capability an agent has is a registered, permissioned object rather than a secret in a file. |
| AI Search | A managed vector index with real-time syncing from the source data, for retrieval over text and unstructured content. | Grounding in your own documents is what separates a useful answer from a fluent one. |
| MLflow Tracing | Records every step an agent takes, in development and in production. | A bad output leads to the step that caused it instead of to a shrug. |
| Unity Gateway | Governs which models, MCP servers and skills may be used, with guardrails, rate limits, budgets and usage tracking. | It is the only part of this list that your auditor will ask about by name. |
| Agent Bricks CLI | Scaffolds, runs and deploys agents from the command line. | An agent becomes a repository with a pipeline, which is how it gets reviewed and rolled back. |
Agents are queried through an invocation API, a Responses API, or from SQL — which means an agent can be called from a query, and its output treated as a column. That is a strange and useful idea worth sitting with for a minute.
Keep the model out of the application code.
The best model for a job has changed roughly every quarter for three years and will keep changing. Any architecture that bakes a model name into application code is buying itself a rewrite on somebody else’s release schedule.
Here, frontier and open models are reached through one API behind Unity Gateway — foundation models served natively, plus external providers connected with your own key, with OpenAI and Anthropic named among them and GPT, Claude and Gemini named as examples. Traffic can be split across destinations, with failover for availability, and Smart Routing picks a model and harness per coding task to control spend.
So the model is configuration behind a governed interface. Changing it is a change to a policy, not a deployment — and when a cheaper model turns out to be good enough for eight of your ten cases, you can act on that finding the same week.
Fine-tuning and pretraining
Fine-tune open models on your data, build classical ML models, or pretrain a custom model. Retrieval-augmented generation, parameter-efficient fine-tuning and standard fine-tuning are all supported, with Hugging Face and DeepSpeed tooling.
One deployment path
Model Serving covers agents, generative models and classical ML behind a unified deployment, with latency and drift monitoring and retraining pipelines after go-live.
Managed MLflow
Hosted MLflow for experiments, models and generative AI, with the registry inside Unity Catalog so models inherit its access control and lineage.
Document Intelligence
Parsing, extraction and classification of enterprise documents at scale, with governance built in rather than bolted on to a separate vendor.
Define good enough before you build anything.
This is the discipline we insist on, and the one clients resist most, because it feels like bureaucracy. It is the opposite: it is the only thing that lets you ship. Without a number, every review is an argument about anecdotes, and the person with the most memorable bad example wins.
Evaluation is part of the platform rather than a separate exercise: LLM judges, custom scorers you write for your own criteria, and structured feedback from the people who actually know the right answer, all tied back to traces so a failure leads to its cause.
What we add is the governance around it: a fixed set of real cases agreed up front, a written bar, and a rule that the bar does not move to meet the result. If the agent reaches 78% and the bar was 90%, that is useful information, not a negotiation.
And a rule for what happens below the bar
The most valuable design decision in most agent projects is not how to be right more often — it is what to do when the agent is unsure. Escalate to a person, say so plainly, decline. An agent that escalates 30% of cases and is right about the rest is deployable. One that is right 95% of the time and confident about the other 5% is not.
Customer figures published by Databricks, without methods. We quote them to show the shape of the results companies report, not as a forecast. The only number that should influence your decision is the one your own evaluation produces on your own cases.
Half of these projects are a SQL function.
We would rather lose the bigger piece of work than sell you one. A great many requests that arrive described as “an AI agent” are, on inspection, a batch job: read these five thousand documents, pull out these eight fields, flag the ones that disagree with the purchase order.
When you genuinely need one
- The task takes several steps whose order depends on what was found.
- It must decide which tool to use, not just run one.
- It holds a conversation, or state across time.
- It needs to escalate, with judgement about when.
When a SQL call will do
- Extracting fields from documents into a table.
- Classifying text against a known set of labels.
- Summarising, translating or masking at volume.
- Forecasting a series or ranking what drove a change.
The second column is cheaper to build, cheaper to run, easier to test, and already governed by the catalogue. It also tends to deliver the value people actually asked for. Start there, and reach for an agent when the work genuinely branches.
An agent is only as good as what it can retrieve. The most common reason a pilot disappoints is not the model — it is that nobody described the data.
Which is why we start with the catalogue, not the promptWhat an agent stands on.
Grounding, memory and a place for people to use it.
Unity Catalog
Tables, files, models, agents and dashboards in one permission model, with column-level lineage, attribute-based policies and a gateway that governs what AI is allowed to touch.
Read it →DatabaseLakebase
Open-source Postgres with storage and compute pulled apart: branch it like code, scale it to zero, and read the same governed data your analytics read.
Read it →Application developmentDatabricks Apps
Streamlit, Dash and Gradio apps on serverless compute, with sign-in, permissions and Unity Catalog around them instead of a server you have to ask IT for.
Read it →Where this leads next.
© 2026 Mawkish Technologies. This guide, its diagrams and illustrations are protected by copyright. You’re welcome to learn from it and to quote it with credit and a link. Reproducing it, by hand or through AI, and publishing it as your own is not allowed. Read our copyright notice
What people ask about agents.
What is actually provided here that we could not build ourselves?
Durability, governance and observability — the parts that are boring until they are the reason a pilot never reached production. Agent Runtime hosts agents from any framework; AgentKit adds durable execution so a run survives a crash or restart; the Agent Server handles synchronous, streaming and background runs with crash recovery; memory and sessions persist state in Lakebase-backed stores; a sandbox runs code the agent writes; MLflow traces every step; and Unity Gateway governs which models, tools and MCP servers the agent may use, with rate limits and budgets.
You could assemble that. Most teams who try are still assembling it a year later.
Which models can we use?
Both frontier and open models through one API, governed by the gateway: foundation models served natively, plus external providers connected with your own key, with OpenAI, Anthropic, GPT, Claude and Gemini named as examples. Traffic can be split across destinations, with failover, and Smart Routing picks a model per coding task to control spend.
So the model is a configuration choice behind a governed interface rather than a dependency baked into application code, which is the right way round given how often the best model changes.
How do we know an agent is good enough to ship?
Evaluation is part of the platform rather than a separate project: LLM judges, custom scorers you write, and structured feedback from the people who actually know the right answer, all tied back to traces so a bad output leads to the step that caused it.
The discipline we insist on is a written definition of "good enough" before anything is built — a measurable bar for accuracy on a fixed set of real cases. Without it, every review becomes an argument about anecdotes.
Can an agent reach our other systems?
Through MCP servers and tools, yes: Databricks-managed, custom and external servers, Unity Catalog functions published as tools, HTTP connections, AI Search over your indexed documents, and a Genie One MCP server for natural-language questions over governed data.
Everything an agent can reach is registered and permissioned, which is the point. An agent with an unaudited credential is an incident waiting for a date.
Do we need AI at all, or do we need better data first?
Usually the second, and we would rather say so early. An agent is only as good as what it can retrieve, and the most common reason a pilot disappoints is that the underlying tables have no agreed definitions and no owner.
The honest sequence is: get the data governed and described, then put an agent on it. That order also makes the agent cheaper, because grounded retrieval beats a larger model on the same ungrounded mess.
Bring us your stalled pilot.
Tell us what it does, what it demoed on, and why it has not shipped. We will tell you which of the six missing pieces it needs, whether it should be an agent at all, and what a written bar for good enough would look like on your cases. Often the answer is smaller and cheaper than the one you came in with.
- An honest read on whether you need an agent
- A written accuracy bar before any build
- Grounding in governed, described data
- Tools registered, not credentials shared
- A rule for what happens when it is unsure
Databricks, Lakehouse, Lakeflow, Lakebase, Unity Catalog, Genie, Agent Bricks, OpenSharing, Delta Sharing and Lakewatch are trademarks of Databricks, Inc. Apache, Apache Spark, Apache Iceberg and Spark are trademarks of the Apache Software Foundation. Delta Lake and MLflow are projects of the Linux Foundation. SAP, SAP Business Data Cloud and SAP Datasphere are trademarks of SAP SE. PostgreSQL is a trademark of the PostgreSQL Community Association. All other names belong to their owners. Mawkish Technologies is not affiliated with, endorsed by or a reseller for Databricks, Inc. Everything described here is taken from material Databricks publishes; product names, availability and prices change, so check the current documentation before you commit to anything. Screens shown are our own illustrations with sample data, not screenshots.
We call our approach to Databricks Agent Bricks the Prubrook Pledge: advice that stays on your side of the table.