Databricks architecture
How Fabric Harness routes identity, policy, model calls, data tools, durable state, telemetry, and deployments through Databricks.
Fabric Harness separates the agent runtime from the services the agent is allowed to call. A single Databricks principal can be threaded through Model Serving, REST tools, SQL, and Lakebase credential exchange. Fabric policy adds approvals, egress restrictions, budgets, and audit correlation; Unity Catalog still makes the final data authorization decision.
Runtime layers
One request, one governed identity
Finite jobs and persistent agents
Finite jobs live in .fabricharness/jobs/, return one typed result, and are invoked at
POST /jobs/:name. Persistent agents live in .fabricharness/agents/, retain an addressable
conversation, and return a submission receipt from POST /agents/:name/:id. Both use the same model,
tool, policy, and Databricks integration surfaces.
Lakebase can back sessions, submissions, and conversation streams. The runtime exchanges a workspace OAuth token for a short-lived database credential, supplies that credential through the Postgres pool, refreshes early, and deduplicates concurrent refreshes.
Deployment boundaries
databricks-app runs the bundled Node server inside Databricks Apps. databricks-serving builds an
MLflow ChatAgent proxy that calls an agent hosted elsewhere; it does not execute the TypeScript
runtime inside Model Serving. The proxy uses asynchronous Harness admission and streams model deltas
to Model Serving as ChatAgentChunk values, while preserving a normal aggregated predict response.
See Databricks deployment for target details.