Agent development framework
Put an agent in production and keep it there
A TypeScript framework for durable agents that deploy to Databricks Apps, Temporal or Cloudflare, and keep running through a restart.
- Role in the family
- Agent development framework
- Databricks surfaces
- Unity AI 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
Agent demos run in a notebook and die on the first timeout. Getting one into production means solving durability, approvals, sandboxing, model routing, and cost accounting. No framework tutorial covers those.
How it works
Agents are defined once and deployed to a target: a local Node runtime, a Temporal worker, a Cloudflare Worker, or a Databricks App running under its own service principal. The Databricks path wires Unity AI Gateway for model serving and Unity Catalog-governed tools, so an agent's data access is bounded by the same catalogue permissions as a human analyst's.
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.