Databricks agents · Harness SDK v6.1.0

Agent control for Databricks

Build agents on Databricks.Keep control when they act.

Compose Genie, SQL, AI Search, Jobs, and external tools in TypeScript. Add durable approvals, restart recovery, and Temporal without replacing Databricks governance.

$npm install @fabric-harness/sdk
Native host
Databricks Apps
Identity authority
Unity Catalog + OBO
Durable state
Lakebase + Temporal
Native tools
Genie · Jobs · AI Search

Fabric ecosystem

DatabricksTemporal

Native Databricks foundation

Harness coordinates the run. Databricks remains authoritative for data, identity, models, compute, and hosting.

Apps
Genie Agents
Unity Catalog
AI Search
Jobs
Lakeflow
Lakebase
MLflow

The 30 second answer

Databricks owns the platform. Fabric owns the run.

People often hear Fabric as a wrapper around Databricks products. That is the wrong layer. Unity Catalog, AI Gateway, Apps, Genie, Jobs, and MLflow stay native. Fabric is the durable agent control layer when request-scoped hosts are not enough.

Databricks decides

  • Who may read or write data under Unity Catalog
  • Which models and serving endpoints are available
  • Workspace identity, OBO, and App service principals
  • Jobs, Lakeflow, Genie, AI Search, Lakebase, MLflow

Fabric decides

  • How a finite or persistent agent recovers after failure
  • How exact-operation approvals survive multi-day waits
  • How policy covers tools, shell, filesystem, network, and sandboxes
  • How evidence, cost, and terminal state stay correlated to the run

If AppKit's request and thread lifecycle is enough for a Databricks-only interactive agent, use AppKit. If the work must outlive a request or cross systems, use Fabric on top of Databricks, not instead of it. Read the full boundary guide.

When the control layer earns its keep

Three production failures that outlive a model request.

Fabric earns its keep after the first crash, the long approval, or the cross-system effect—when the selected runtime and store are configured for durable recovery.

The App restarts mid run

A multi-step Job dies with the process. You cannot tell what finished, what ran twice, or how to resume safely.

With Fabric. Submissions, leases, checkpoints, and terminal states make recovery inspectable. Optional Temporal keeps the same agent contract across worker replacement.

A steward needs two days

Request-stream approval evaporates when the chat ends. The next attempt is a free-form grant, not the exact operation you reviewed.

With Fabric. Approvals bind the exact tool input and principal, persist beyond one HTTP stream, and stay correlated with lineage, cost, and terminal outcome.

Work leaves the workspace

Databricks owns data and models well. The agent still needs git, shell, Slack, sandboxes, or another cloud under one policy trail.

With Fabric. Portable policy, sandboxes, sources, and deployment targets keep one finite or persistent definition across Databricks and the rest of your stack.

How it works

Define once. Control every effect. Recover with proof.

A coherent contract from local mock runs to Databricks Apps, Temporal workers, and portable cloud targets.

  1. 01

    Define the agent

    Finite jobs or persistent agents with typed input, tools, skills, and a capability policy floor that invocation cannot silently widen.

  2. 02

    Run under control

    Sessions drive the model loop. Every tool, shell, or network effect passes policy. Approvals and budgets bind identity before side effects land.

  3. 03

    Recover with evidence

    Submissions, events, artifacts, cost, lineage, and replay views explain what resumed, failed, or changed after a crash, wait, or deploy.

Durability through Temporal

The App can restart. The run does not disappear.

Harness records the agent lifecycle and effects. Add the optional Temporal runtime when a Databricks workflow must cross worker replacement, multi-day approval, or a process crash without changing the agent definition.

  • Accepted work receives a stable submission identity before execution
  • Exact-operation approval can wait without keeping one request open
  • Databricks Jobs use bounded polling and stable idempotency tokens
  • Recovery preserves principal, policy, lineage, and terminal outcome
See the Temporal runtime contract

Durable execution trace

One submission across interruption

Temporal
  1. durable

    Accepted

    submission persisted

  2. durable

    Running

    Genie + SQL evidence

  3. durable

    Waiting

    steward approval

  4. process

    Restart

    App process replaced

  5. durable

    Resumed

    Temporal continues

  6. durable

    Settled

    outcome + lineage

Resume from recorded state; do not replay an external effect without its idempotency key.

The product boundary

Durability and portable governance are the product boundary.

Agent loops, scoped tools, threads, and request-time approvals now exist in several platforms. Fabric differentiates by keeping bounded lifecycles, policy, recovery, isolation, and evidence coherent across supported runtimes.

Choose the operating plane

Native where it matters. Portable everywhere else.

Fabric does not flatten every platform into the lowest common denominator. It gives Databricks a first-class governed surface while keeping agent, policy, runtime, and sandbox contracts portable.

Databricks · first-class

Keep the data plane native. Add durability when the work demands it.

Use Databricks AppKit directly for workspace-only interactive agents. Add Fabric when work must survive process failure, cross services, use isolated execution, or retain portable governance evidence.

  • Native Unity Catalog and OBO authority
  • Agent Bricks and AppKit interoperability
  • Durable workflows around Databricks services
Explore Fabric on Databricks

Cloud + edge · portable

Bring your runtime, network, and isolation model

Deploy Node or container artifacts to AWS, Azure, Google Cloud, Cloudflare, or Kubernetes. Swap sandboxes and persistence without rewriting the agent definition.

  • Docker and Kubernetes isolation
  • Temporal or inline durability
  • Provider-neutral policy and sessions
Compare runtimes and targets

Databricks agent stack

Native services, composed as one durable agent.

Build on the Databricks capabilities customers already govern. Harness binds them to an explicit agent lifecycle, durable approval, recovery, and evidence contract.

A Databricks agent you can explain

One agent. Native Databricks tools. Durable control.

This revenue agent asks Genie for business context, verifies claims with read-only SQL, and can refresh a forecast only after an exact-operation approval. Databricks remains the authority; Harness owns how the run proceeds and recovers.

  • Genie and SQL remain governed by Unity Catalog
  • The forecast Job is allowlisted and approval-bound
  • The submission can resume after a Databricks App restart
  • Temporal can carry the same definition across multi-day waits
Build a Databricks agent
.fabricharness/agents/revenue-ops.ts
1import {
2 createAgent,
3 useModel,
4 useSkill,
5 useTool,
6} from '@fabric-harness/sdk';
7import { financeControls } from '../skills/finance';
8import {
9 askGenie,
10 readRevenue,
11 runForecastJob,
12} from '../tools/databricks';
13
14function RevenueOpsAgent() {
15 useModel('databricks/system.ai.gpt-oss-20b');
16 useSkill(financeControls);
17 useTool(askGenie);
18 useTool(readRevenue);
19 useTool(runForecastJob);
20
21 return `Investigate revenue changes with Genie first.
22Verify every claim with read-only SQL. If a forecast
23must be refreshed, request approval before running the
24Job. Return the SQL, Job run ID, and source lineage.`;
25}
26
27export default createAgent(RevenueOpsAgent, {
28 durability: { maxAttempts: 5, timeoutMs: 7_200_000 },
29 policy: {
30 toolPolicy: {
31 allow: ['databricks_genie_ask', 'sql_read'],
32 requireApproval: ['run_forecast_job'],
33 },
34 },
35});

FAQ

Straight answers to the comparison questions

Use these when someone asks what Fabric provides that Databricks does not provide natively.

What does Fabric provide that Databricks does not provide natively?
Databricks decides who can touch data, models, and compute. Fabric decides how an autonomous agent runs: recover after a crash, wait days for an exact operation approval, constrain shell and tools the same way everywhere, and leave operator evidence. Full comparison: Why Fabric on Databricks.
Should I use AppKit instead?
Use AppKit when a Databricks-only interactive agent and its request or thread lifecycle are enough. Use Fabric when work must outlive a request, cross systems, use isolated execution, or keep a portable recovery record. They can also compose through MCP and governed tools.
Does Fabric replace Unity Catalog, Jobs, or MLflow?
No. Unity Catalog remains the authorization authority. Jobs, Lakeflow, AI Search, Genie, Lakebase, and MLflow stay native Databricks services. Fabric adds the durable control layer around them.
Do I need Temporal to start?
No. Local and Databricks App paths work without Temporal. Add Temporal when you need deterministic recovery across worker restarts and multi-day waits. The agent definition stays the same.
Is this only for coding agents?
No. Coding and review agents are one workload family. The same runtime serves data copilots, knowledge assistants, customer operations, incident response, and long-running business processes.
How do I try it without a live workspace?
Run fh init --template databricks and use --mock for the model loop. Mock mode does not validate Databricks APIs or permissions; certify the target workspace before production.
Databricks-native · Temporal-ready

Put a governed agent next to your data.

Start locally with mock tools, deploy the same definition to Databricks Apps, and add Temporal when recovery and multi-day work become requirements.

Fabric Harness is built and supported by TechFabric.

Contact TechFabric