Databricks AppKit interop

Databricks AppKit and Fabric Harness overlap at the agent-runtime layer. AppKit's beta Agents plugin provides TypeScript agents, threads, streaming, tool budgets, human approval, sub-agents, and hosted MCP. Fabric's value is not replacing those features. It is preserving the durable organizational contract around them: separation of duties, policy and artifact binding, promotion, recovery, cross-system lineage, certification, and retained evidence.

The currently proven integration is additive:

AppKit beta agent -> MCP -> authenticated Fabric Harness server -> governed tool

Use this shape when a Databricks-native AppKit experience should read from or request work through a Fabric-governed boundary. The existing self-contained Fabric databricks-app artifact remains the default when the application needs Fabric sessions, submissions, durable approvals, restart recovery, or a single certified runtime.

Runnable proof

The examples/with-databricks-appkit-interop example pins AppKit 0.53.0. It starts a local Harness MCP server, creates an AppKit beta agent with that server as a hosted tool, invokes /responses, and checks the Fabric-side evidence.

pnpm --filter @fabric-harness/example-with-databricks-appkit-interop test
pnpm --filter @fabric-harness/example-with-databricks-appkit-interop build
pnpm --filter @fabric-harness/example-with-databricks-appkit-interop start

Expected output includes:

{
  "responseStatus": "completed",
  "boundary": "AppKit agent -> MCP -> governed Harness tool",
  "fabricEvidence": {
    "actorId": "fabric-interop-user",
    "tenantId": "fabric-interop-tenant",
    "policyVersion": "fabric-policy-v1",
    "cancellable": true
  }
}

The proof is local contract evidence. It is not a live workspace or release certification.

Authentication and OBO

The Fabric /mcp endpoint must authenticate every request and resolve the actor and tenant before tool dispatch. AppKit's MCP host policy only forwards workspace credentials to endpoints it classifies as same-workspace. Do not pass an OBO token to an arbitrary external MCP URL, and do not derive identity from model-controlled tool arguments.

For a production same-workspace deployment:

1. register only the Fabric App MCP URL intended for the environment;
2. validate the bearer token at Fabric ingress;
3. bind the verified principal and tenant to ToolContext;
4. resolve approval and policy context server-side; and
5. retain both AppKit/Gateway and Fabric correlation evidence.

Current safety boundary

Keep the AppKit bridge read-only unless the remote mutation is independently approved and enforced by Fabric. In the pinned AppKit version, MCP discovery does not preserve remote effect annotations in the agent tool index, so AppKit's local approval gate cannot distinguish a read from a remote mutation.

End-to-end MCP cancellation is also not yet certified. AppKit supplies an abort signal to the agent adapter and its lower-level MCP client accepts one, but the beta Agents dispatch path in 0.53.0 does not forward that signal into the MCP call.

These are version-specific limitations. Fabric rechecks them before changing the tested pin.

What remains authoritative

Failure behavior

• Harness rejects an MCP tool whose effect is missing. Write and execute tools also require an explicit governed marker after server-side wrapping.
• AppKit host-policy or MCP discovery failures leave the tool unavailable; the example fails if discovery does not expose the expected tool.
• Invalid Fabric authentication fails before tool dispatch.
• Missing durable storage means AppKit's default in-memory threads are lost on restart. Configure and certify a persistent thread store before relying on App restart continuity.
• A remote mutation through this beta bridge is unsupported until effect, approval, cancellation, and live evidence gates close.

Packaging decision

No AppKit-specific Fabric build target is published today. The spike did not change the default target and did not remove the self-contained Node server from Fabric artifacts. AppKit interop therefore adds a Databricks-native front end to Fabric governance; it does not yet reduce the number of runtimes operators must own.

See Databricks integrations, self-contained application development, and protected live certification.