Why Fabric Harness on Databricks

The 30 second answer

Databricks decides who can touch data, models, and compute. Fabric decides how an autonomous agent runs.

Fabric does not replace Databricks. It is optional when AppKit’s request/thread lifecycle is enough, and valuable when work must outlive a request, wait for a steward, run isolated shell or filesystem tasks, or leave portable recovery evidence—on Databricks and beyond.

Use AppKit (or native) when

• the app and users live entirely in Databricks;
• the agent is primarily interactive chat, Genie, analytics, files, or Model Serving;
• request-scoped approval and thread persistence meet the recovery bar.

Use Fabric on Databricks when

• a run must survive process failure, a multi-day approval, or worker replacement;
• policy must cover tools and commands, filesystems, networks, connectors, or sandboxes;
• the same agent must run locally, on a Databricks App, and optionally on Temporal or another cloud;
• operators need retry classification, principal lineage, replay, cost attribution, and cleanup evidence.

Use both when

Fabric owns a broader durable workflow and calls Agent Bricks, Genie, Model Serving, Jobs, or AI Search as governed native capabilities. Application code can use bundle.sdk; only selected operations are exposed to the model through bundle.tools.

Fabric Harness is a Databricks partner-built application and agent accelerator. It composes and operationalizes Databricks-native capabilities; it does not replace or replicate them.

Fabric Harness and the current Databricks developer platform are complementary below the agent runtime and competitive at the agent-runtime boundary. The Databricks Developer Hub brings Apps, Lakebase, Agent Bricks, the Data Lakehouse, AppKit, agent skills, and coding-agent templates into one developer path.

Databricks remains the native data, AI, compute, identity, governance, and hosting platform. Fabric uses those capabilities as the native foundation. Databricks now also offers a beta AppKit agent host with TypeScript and Markdown definitions, scoped tools, subagents, threads, cancellation, human approval, and Responses-compatible routes. Those features overlap directly with part of Fabric Harness.

Use AppKit directly when a Databricks-only interactive agent and its request/thread lifecycle meet the requirement. Add Fabric when execution must survive process failure or a long approval wait, policy must travel across infrastructure, work needs an isolated shell or filesystem, or operators need a durable record of recovery and effects. The result remains a Databricks App, Job, Lakeflow pipeline, MLflow experiment, Unity Catalog securable, or other native resource that developers can inspect and operate with Databricks tooling.

The boundary

flowchart LR
  APP[Your TypeScript agent]

  subgraph Fabric[Fabric Harness durable control layer]
    RUN[Finite runs, persistent agents, recovery]
    GOV[Portable policy and durable approvals]
    ISO[Tasks, sources, shell, sandboxes]
    OBS[Replay, evidence, cost, artifacts]
  end

  subgraph Native[Databricks application and agent platform]
    APPKIT[Apps and AppKit agents]
    BRICKS[Agent Bricks]
    SDK[Official modular TypeScript SDKs]
    IAM[OAuth, App identity, OBO]
    UC[Unity Catalog and ACLs]
    DATA[SQL, AI Search, Genie]
    WORK[Jobs, Lakeflow, Model Serving]
    STATE[Lakebase, Volumes, MLflow]
  end

  APP --> RUN
  APP --> APPKIT
  RUN --> GOV
  RUN --> ISO
  GOV --> SDK
  APPKIT --> SDK
  APPKIT --> BRICKS
  SDK --> IAM
  IAM --> UC
  SDK --> DATA
  SDK --> WORK
  RUN --> STATE
  RUN --> OBS
  RUN -. governed endpoint .-> BRICKS

  classDef fabric fill:#f8e8d9,stroke:#b8541f,color:#0e1116
  classDef native fill:#f2ede4,stroke:#7a8290,color:#0e1116
  class RUN,GOV,ISO,OBS fabric
  class APPKIT,BRICKS,SDK,IAM,UC,DATA,WORK,STATE native

Stable Databricks operations use the official modular TypeScript SDKs. Every generated SDK package is exact-pinned to one reviewed version and exercised through serialization, authentication, and live-workspace tests. A small private protocol adapter is restricted to endpoints the SDK does not yet expose, such as selected Beta protocols; it is not a public general-purpose REST client.

Fabric does not replace Unity Catalog or weaken its decisions. Fabric can reject an operation before it reaches Databricks, but Databricks remains the final authorization boundary. Agent Bricks can be a managed agent endpoint that Fabric invokes, while Apps and Lakebase can host and persist the Fabric runtime.

Where the products overlap

Advantages to lead with

Durable execution beyond a request

Fabric distinguishes finite, bounded agents from persistent, addressable agents. Submissions carry stable identity and terminal state; retries are bounded and classified; leases prevent competing workers; cancellation propagates; checkpoints and replay make recovery inspectable. The optional Temporal runtime preserves this contract across worker restarts and long waits without making Temporal a requirement for local authoring.

Governance that remains attached to the effect

Definition policy is a security floor: invocation policy may narrow it but cannot silently widen it. Approval grants bind the exact tool or command input and executing principal. Policy covers more than model tools—it can constrain commands, filesystem reads and writes, network destinations, credentials, connectors, sandboxes, budgets, and timeouts. Events, lineage, cost, artifacts, and terminal state remain correlated with the governed operation.

Portable isolated execution

Fabric sessions can mount sources, run tasks and shell commands, create artifacts, checkpoint or fork capable sandboxes, and hand portable sandbox references across processes. Backend capability discovery keeps this contract explicit across local, Docker, Kubernetes, Cloudflare, Daytona, E2B, Modal, Databricks SQL, and other adapters.

One contract beyond Databricks

The same agent, session, tool, policy, source, store, and event contracts can run on Databricks or outside it. This matters when a workflow starts in a Databricks App but also coordinates GitHub, Slack, cloud infrastructure, external databases, an isolated code environment, or a durable worker.

Full Fabric feature surface on Databricks

The complete Fabric surface also includes typed inputs and results, roles, Markdown-first skills, session memory, tasks and subagents, attachments, artifacts, filesystem sources, MCP, channels, schedules, webhooks, queues, the Fiber console, React hooks, OpenTelemetry, evaluation helpers, portable builds, certification, and supply-chain evidence. Not every individual feature is unique; the differentiator is the durable, policy-constrained, portable contract that holds them together.

Typed clients and model tools are deliberately different

Fabric exposes two seams:

• bundle.sdk contains principal-bound native Databricks clients for deterministic application code. Calling one is no more autonomous than calling the Databricks SDK yourself.
• bundle.tools contains bounded ToolDef objects that a model may select. Write and execute tools carry effect metadata, governance descriptors, approval requirements, redaction, and lineage.

This separation prevents “the application can create a Job” from silently becoming “the model can create any Job.” Model-facing write surfaces are opt-in and fail initialization when their approval or compute policy is incomplete.

import { databricks } from '@fabric-harness/databricks';
import { init } from '@fabric-harness/sdk';

const dbx = databricks({
  host: process.env.DATABRICKS_HOST!,
  principal: {
    kind: 'service-principal',
    host: process.env.DATABRICKS_HOST!,
    clientId: process.env.DATABRICKS_CLIENT_ID!,
    clientSecret: process.env.DATABRICKS_CLIENT_SECRET!,
  },
  model: 'system.ai.gpt-oss-20b',
  warehouseId: process.env.DATABRICKS_WAREHOUSE_ID,
  aiSearch: {
    index: 'main.knowledge.docs_index',
    textColumn: 'chunk',
    idColumn: 'id',
  },
  governance: {
    catalogs: ['main'],
    stewardAudience: 'data-platform',
  },
});

const fabric = await init({
  modelProvider: dbx.modelProvider,
  tools: dbx.tools,
  policy: dbx.policy,
  store: dbx.store,
});

This bundle uses one identity for AI Gateway, generated SDK clients, SQL, retrieval, and optional Lakebase credential exchange. Add resource-management flags only when the agent truly needs them.

Choose the right runtime

Use Databricks AppKit directly when:

• the application and its users live entirely in Databricks;
• the agent is primarily interactive chat, Genie, analytics, files, or Model Serving;
• request-scoped approval and thread persistence meet the recovery requirement; and
• a Databricks-native application and deployment lifecycle is preferred over runtime portability.

Use Fabric on Databricks when one or more of these are requirements:

• a run must survive process failure, an approval delay, a worker replacement, or a multi-step workflow;
• policy must remain enforceable across Databricks and non-Databricks tools, commands, filesystems, networks, connectors, or sandboxes;
• the workload needs tasks, shell execution, mounted sources, checkpoints, forks, attachments, or artifacts around Databricks data and AI;
• the same finite or persistent agent needs local tests, a Databricks App, another cloud deployment target, or an optional Temporal worker;
• operators need retry and terminal-state classification, tenant/principal lineage, replay, cost attribution, cleanup evidence, and reproducible certification; or
• a workflow coordinates Databricks with channels, external systems, or isolated compute.

Use both when Fabric owns a broader durable workflow and calls Agent Bricks, Genie, Model Serving, Jobs, Lakeflow, AI Search, or another App as a governed native capability. Application code can use bundle.sdk, while only selected operations are exposed to the model through bundle.tools.

Use the native Databricks SDK without either agent runtime when the flow is short, deterministic application code.

What Fabric does not claim

• It is not a replacement for Databricks SDKs, CLI, Declarative Automation Bundles, Terraform, Apps or AppKit, Agent Bricks, Unity Catalog, MLflow, Jobs, Lakeflow, AI Search, Genie, Lakebase, Model Serving, or AI Gateway.
• It does not claim that ordinary TypeScript agent definitions, threads, scoped tools, streaming, or request-time HITL are unique to Fabric.
• It does not make a preview API stable; preview capabilities remain labeled and require their own workspace evidence.
• It does not infer AWS or GCP compatibility from an Azure certification run.
• It does not put workspace tokens, raw secret values, or user-supplied identity labels into model context.
• It cannot make an unbounded autonomous agent safe. Production deployments still need least privilege, explicit tools, budgets, approvals, evaluation, and workspace-specific tests.

Continue

• Build a Databricks agent
• Run RAG on Databricks
• Manage Databricks resources safely
• Understand identity and control flow
• Review native SDK and workspace compatibility
• Inspect live authoring certification evidence