What is Fabric Harness

The 30 second answer

Databricks (or any host platform) decides who can touch data, models, and compute. Fabric Harness decides how an autonomous agent runs.

Fabric is a headless TypeScript framework for durable, deployable agents. Finite jobs live in .fabricharness/jobs/; persistent, addressable agents live in .fabricharness/agents/. Run them locally and build for Node, Docker, Temporal, Cloudflare, Azure-oriented targets, or Databricks Apps and Model Serving proxy deployments.

Its distinctive boundary is not the prompt loop, threads, or request-time tool lists. Fabric keeps execution recoverable and governance enforceable when work:

• outlives a request or process,
• waits minutes or days for an exact-operation approval,
• crosses infrastructure (shell, sandboxes, channels, other clouds),
• or must leave correlated operator evidence behind.

For the full overlap analysis, see Why Fabric Harness on Databricks.

Headless runtime, optional clients. Agents run through the SDK, HTTP, schedules, channels, or Temporal without requiring a UI. Use fh fiber for terminal interaction or @fabric-harness/react for an application UI; both consume the same authenticated public protocol.

New to the framework? Follow Learn Fabric Harness. It gives every shipped feature family a progressive guide, runnable practice workspace, failure/cleanup expectation, and production proof instead of asking you to discover the framework from the API reference.

Why a framework, not just an SDK

Most agent libraries leave you to wire up the runtime, the build, the dev server, the deployment story, and the durability story yourself. Fabric Harness is opinionated about those things so the agent code stays focused on the work:

• Workspace conventions — .fabricharness/jobs, agents, roles, skills, policies, sandboxes, plus a project AGENTS.md.
• CLI — discover, run, build, deploy, inspect, replay, and verify everything from one binary (fabric-harness or fh).
• Runtime adapters — local Node, Docker sandbox, Temporal worker, Cloudflare Workers, Foundry-hosted, more on the way.
• Headless by default — agents complete autonomously. Approvals are an explicit hook, not a default user prompt.
• Durable by design — bounded runs, persistent sessions, submissions, cancellation, checkpoints, retry classification, and optional Temporal workflows survive process and worker failure.
• Capability-scoped security — definition policy remains a security floor across tools, commands, filesystems, networks, sandboxes, and connectors; secrets stay out of model context.
• Durable governance — approvals bind the exact operation and principal, survive long waits, and remain correlated with lineage, cost, artifacts, and terminal state.
• Portable contracts — agent, session, tool, policy, source, sandbox, store, and deployment contracts do not belong to one cloud or data platform.

What is distinctive

Many platforms now provide TypeScript agent definitions, threads, scoped tools, streaming, and request-time approval. Fabric includes those features, but does not present them as unique. Its strongest advantages begin where a request-scoped agent host stops:

How Fabric Harness works

Definitions declare what an agent can do. The runtime creates an isolated session, assembles roles, skills, tools, policy, and context, then drives the model loop. Every tool or shell action passes through capability policy before a sandbox or provider adapter executes it. Events, approvals, artifacts, cost, and results remain correlated to the session and submission.

flowchart LR
  INPUT[CLI, HTTP, schedule, or channel] --> DEF[Job or persistent agent]
  DEF --> SESSION[Session runtime]

  subgraph Context[Context assembly]
    ROLE[Roles]
    SKILL[Skills]
    MEMORY[Memory and mounted sources]
  end

  ROLE --> SESSION
  SKILL --> SESSION
  MEMORY --> SESSION
  SESSION --> MODEL[Model provider]
  MODEL --> ACTION{Next action}
  ACTION -->|Tool| POLICY[Capability policy]
  ACTION -->|Shell or file| POLICY
  ACTION -->|Final result| RESULT[Typed result and events]
  POLICY -->|Approval needed| APPROVAL[Durable approval]
  POLICY -->|Allowed| EXEC[Sandbox or connector]
  APPROVAL --> EXEC
  EXEC --> SESSION
  SESSION --> STORE[(Session and submission store)]

  classDef entry fill:#f4f4f5,stroke:#71717a,color:#18181b
  classDef fabric fill:#dbeafe,stroke:#2563eb,color:#172554
  classDef control fill:#fef3c7,stroke:#d97706,color:#422006
  classDef state fill:#dcfce7,stroke:#16a34a,color:#052e16
  class INPUT,DEF entry
  class SESSION,MODEL,RESULT fabric
  class ACTION,POLICY,APPROVAL control
  class EXEC,STORE,ROLE,SKILL,MEMORY state

On Databricks, the same runtime can use Model Serving, SQL Warehouses, Unity Catalog, AI Search, Genie, Feature Serving, Lakeflow, Lakebase, MLflow, and Databricks Apps under one propagated identity. It can also author Jobs, pipelines, indexes, endpoints, grants, workspace objects, and secret references through opt-in approval-bound tools. Start with Fabric Harness on Databricks.

Build governed agents around Databricks workloads

Fabric Harness is designed for enterprises that already use Databricks as their governed data and AI platform and need an application runtime around it. Data, models, compute, and authorization stay native to Databricks. Fabric adds durable agent sessions, model-safe tools, approval routing, identity propagation, deployment contracts, lineage, and cost correlation.

Start with the Databricks workload map, use the enterprise adoption guide to plan a production rollout, and review workspace compatibility evidence before making a cloud, region, or preview claim.

Databricks now also provides a beta TypeScript AppKit agent host with threads, tools, subagents, cancellation, human approval, and Responses-compatible routes. That is real overlap. Use AppKit directly for a Databricks-only interactive agent when its request and thread lifecycle is sufficient. Use Fabric when the workload needs recoverable execution, durable waits, portable policy, isolated shell/filesystem work, cross-system orchestration, or the option to move the same contract beyond Databricks. The approaches also compose: Fabric can use Databricks Apps, Agent Bricks, Unity AI Gateway, Lakebase, Jobs, and Unity Catalog as native services.

Complete capability map

Standard agent terminology

Fabric Harness keeps the terms that are converging across the agent ecosystem. You will find these everywhere in the docs:

Agent functions for conversations, finite jobs for results

Use a persistent agent function when people or systems will message the same address over time. Hooks keep its model, tools, skills, sandbox, and instructions together in one readable definition:

import {
  createAgent,
  useModel,
  useSandbox,
  useSkill,
  useTool,
} from '@fabric-harness/sdk';
import { reviewChecklist } from '../skills/review';
import { proposeFix, searchIssues } from '../tools/github';

function TriageAgent() {
  useModel('anthropic/claude-sonnet-4-6');
  useSandbox('docker', { cwd: '/workspace' });
  useSkill(reviewChecklist);
  useTool(searchIssues);
  useTool(proposeFix);

  return `Triage the reported issue end to end.
Reproduce it, identify the root cause, propose a fix,
and verify the result before you finish.`;
}

export default createAgent(TriageAgent, {
  durability: { maxAttempts: 5, timeoutMs: 2 * 60 * 60_000 },
});

The function renders before each interaction. Its return value is the instruction, while hooks compose capabilities in call order. Static policy, durability, triggers, and initial-data validation belong in createAgent()'s second argument so the host can enforce them even when the function cannot render.

Use a finite agent when one typed invocation should return one bounded result:

import { defineAgent, schema } from '@fabric-harness/sdk';

export default defineAgent({
  name: 'echo',
  input: schema.object({ message: schema.string() }),
  output: schema.string(),
  run: ({ input, prompt }) => prompt(input.message),
});

The bare @fabric-harness/sdk import gives finite agents headless defaults (runtime: 'stateless', sandbox: 'virtual', the Pi loop runtime, and automatic compaction). Definition-level instructions, tools, policies, cost budgets, and approval timeouts become runtime defaults; invocation policy and budgets cannot weaken the definition's security floor.

For Temporal-backed finite agents or compliance/audit workloads where implicit defaults are undesirable, switch to @fabric-harness/sdk/strict. The call shape stays the same, but every runtime option is explicit. Runtime (stateless / inline / temporal) and deployment target remain separate choices.

import { defineAgent, schema } from '@fabric-harness/sdk/strict';

export default defineAgent({
  name: 'triage',
  model: 'openai/gpt-5.5',
  input: schema.object({ issueNumber: schema.number(), title: schema.string() }),
  output: schema.object({ severity: schema.enum(['low','medium','high']), summary: schema.string() }),
  triggers: { webhook: true, schedule: '*/15 * * * *' },
  run: async ({ init, input }) => {
    const fabric = await init({
      runtime: 'temporal',
      sandbox: 'local',
      compaction: { enabled: false },
      policy: triagePolicy,
    });
    const session = await fabric.session();
    return await session.prompt(`Triage issue #${input.issueNumber}: ${input.title}`);
  },
});

Persistent and finite definitions deploy through the same CLI and share the same session, tool, skill, sandbox, policy, and model contracts. See Dynamic agents and hooks, Persistent agents, and SDK entrypoints, runtimes, and targets for the full distinction.

Public API surface

const fabricAgent = await init(options);
const session = await fabricAgent.session(id?, options?);

await session.prompt(text, options?);
await session.skill(name, options?);
await session.task(text, options?);
await session.shell(command, options?);

Where to go next

• Want the 10-line agent? Headless agents with the minimal entrypoint.
• Confused by entrypoints, stateless, inline, or Temporal? SDK entrypoints, runtimes, and targets.
• New here? Use cases → Installation → Your first agent.
• Want CLI specifics? CLI reference.
• Ready to deploy? Deployment.
• Building on Databricks? Architecture, integrations, quickstart, and validation.
• Curious about scope? See the capability matrix.