Agents that hold up
Agents that run under their own identity, and can be checked
We build production AI agents: durable across restarts, bounded by the same catalogue permissions as the people they act for, stopping for human approval where a decision needs one, and measured by an evaluation harness so you can tell whether a change helped. Our agent framework is open source and deploys into your own workspace.
An agent that works in a notebook has solved the easy half. The hard half is what happens when the model times out mid-run, when it needs to read a table its caller has no grant for, when somebody has to approve a refund before it goes out, and when you want to know whether this month's version is better than last month's.
- Who it is for
- Engineering leaders whose agent pilot cannot get past review
- Bench
- 115+ engineers, 80 Databricks-certified
What we build
- Agents deployed as a Databricks App under their own service principal, or as a Temporal worker, or both
- Tools that resolve through Unity Catalog, so an agent cannot reach data it has no grant for
- Approvals as a first-class step: the run parks, waits for a person, and survives a worker restart while it waits
- Model routing through a provider registry rather than a hard-coded vendor
- Sandboxed execution for code the agent writes, bounded away from the worker process
- An evaluation harness, so a change can be shown to have helped rather than argued about
What makes it faster
The framework underneath. One agent definition builds for a local runtime, a Temporal worker, a Cloudflare Worker or a Databricks App, so the deployment target is a decision you can change later. It is Apache-2.0 and it runs in your workspace, not ours.
About Fabric HarnessWhere this goes next
FAQ
Agentic AI development: common questions
What makes an agent production-ready?
Four things, and none of them is the prompt. It survives a restart without losing its place. It cannot read data its caller could not. A person can approve or stop it, and the run waits without falling over. And somebody can measure whether a change made it better. A pilot that has none of these is a demo, and the gap between the two is most of the work.
How do you stop an agent reaching data it should not?
Its tools resolve through Unity Catalog and it runs under its own service principal, so the grants that bound a human analyst bound the agent too. That is a platform property rather than a prompt instruction, which matters because a prompt instruction is a request and a grant is not.
What happens when the model provider has an outage?
Model access goes through a provider registry, so a fallback is configuration rather than a rewrite. On Databricks that registry is Unity AI Gateway. Runs that are mid-flight are durable, so they resume rather than restart.
Do we have to use your framework?
No. Harness is Apache-2.0 and it exists because we needed it, so we are happy when a team takes it and never talks to us again. We also work in whatever you already have. The framework is how we go faster, not a condition of the engagement.
How do you evaluate whether an agent is any good?
A fixed set of cases with known answers, run on every change, scored the same way each time. Without that, quality is whoever spoke last in the review meeting. Fabric Experiments is the accelerator we use for it and the approach works the same way without it.
The rest of our AI work
AI Readiness Assessment
Leaders with AI on the roadmap and no clear view of what is in the way
AI Tools Assessment
Finance and platform leaders holding a renewal they cannot justify
AI workflow automation
Operations and engineering leaders with a process that half-completes
AI enablement
Engineering leaders whose team needs to own this, not outsource it
AI transformation
Executives with a mandate, a budget, and fifteen pilots