Agent development framework
Put an agent in production and keep it there
Harness is how your team runs AI agents on your Databricks data safely in production. Each agent can only read what Unity Catalog grants it, stops for a person's approval before the actions that need one, and keeps working through a restart instead of losing the run.
- Role in the family
- Agent development framework
- Databricks surfaces
- Unity GatewayUnity CatalogDatabricks AppsModel ServingTemporal
- Status
- Production-grade. The local runtime, Temporal worker path, model provider registry, approvals, tasks, artifacts, metrics, and Docker sandbox support agents running under real production workloads.
- Documentation
- harness.techfabric.com
The problem
Most agents that answer well in a notebook never reach production. The demo dies on the first timeout, it was given a broad service account because that was quickest, and there's no way for a person to approve what it does before it does it.
How it works
On Databricks each agent runs as a Databricks App under its own service principal, so its access is the kind of grant you'd give an analyst and nothing wider. Our engineers build your first agent on it with your team, and the code is yours to keep under Apache-2.0.
What it does
One agent, several targets
The same definition builds for local, Temporal, Cloudflare, or a Databricks App without rewriting the agent.
Approvals as a first-class step
An agent that needs a human decision parks and waits, and survives a worker restart while it does.
Governed tools
Tools resolve through Unity Catalog, so an agent cannot reach data its service principal has no grant for.
Sandboxed execution
Code the agent writes runs in a bounded sandbox, not in the worker process.
Your first agent reaches production in weeks, and the tenth costs a fraction of the first. Durability, approvals, sandboxing, model routing, and Unity Catalog-bounded data access are already solved, so your engineers write the agent instead of the plumbing under it.
The demo worked. Then it met a real day.
An agent that answers well in a notebook has solved the easy half. The hard half is everything that happens once it is running unattended.
It dies on the first timeout
A run that takes two hours, calls six systems and waits on a person cannot live in a request handler. A deploy in the middle loses the run.
It reaches data it should not
The agent got a broad service account because that was quickest, and now its access is wider than any person's and nobody reviewed it.
Nobody can approve anything
Some actions should stop and wait for a person. Without that as part of the runtime, the choice is between an agent that cannot act and one nobody is comfortable with.
None of these are model problems, and a better model does not fix any of them. They are all properties of the system around it.
The shift
Three ways to run an agent in production
The model is the same in all three. What differs is what happens when something goes wrong.
A script with a loop
Works on the good path
A queue and a retry
Durable, and it duplicates
A durable agent runtime
Survives a restart, and can be approved
What gets installed
A TypeScript framework, and the parts of it that matter are the ones nobody demos.
Durable sessions
An agent run is a workflow. A restart, a crash or a deploy mid-run resumes rather than starts again, and a retry does not repeat work already done.
Human approval as a gate
The run pauses on the actions that warrant it, the approval is recorded against the exact operation, and it resumes from there.
Governed tools
What an agent may call and which secrets it may see, scoped per session rather than per deployment.
Sandboxed execution
Untrusted code runs somewhere it cannot reach your host, with Docker, E2B, Cloudflare and several other sandboxes supported.
Model routing
Which provider serves which agent, session or call, decided at runtime instead of being compiled in.
Deployment targets
The same agent definition builds for a local runtime, a Temporal worker, a Cloudflare Worker or a Databricks App without rewriting it.
4
Deployment targets from one agent definition
Our own agents run on it
Harness is the runtime under Fabric and under the client applications we build on it, which means we are on the pager for it. It is free and open source under Apache-2.0, and it deploys into your own account.
FAQ
TechFabric Harness, answered
Is Harness production-ready?
Yes. The local runtime, Temporal worker path, model provider registry, approvals, tasks, artifacts, metrics and Docker sandbox support agents running under real production workloads.
Where do agents built with Harness run?
The same definition builds for a local Node runtime, a Temporal worker, a Cloudflare Worker, or a Databricks App running under its own service principal. You choose the target without rewriting the agent.
How is an agent stopped from reaching data it should not?
Tools resolve through Unity Catalog, so an agent's data access is bounded by the same grants as a human analyst's. It cannot reach what its service principal has no permission for.