Databricks integration

Turn enterprise intelligence into durable operational work.

Databricks now supports agents, MCP/REST tools, model serving, and governed AI access. Orchestrate complements that intelligence layer when model signals, agents, or data products need to drive a durable process across operational systems and human approvals.

Integration posture
Operationalize

Keep the surrounding platform responsible for what it already does well. Use Orchestrate where durable cross-estate execution and one delegation/audit chain become the requirement.

Databricks intelligence
initiates or contributes work
↓ governed handoff
Aizen Orchestrate
durable execution + identity
↓ governed handoff
Operational systems
system-of-record action
Division of responsibility

Complement the platform. Do not duplicate it.

Databricks remains responsible for

Data, models, agents, and AI governance

Lakehouse data and Unity Catalog governance remain in Databricks.
Model training and serving remain where teams already manage analytical and ML workloads.
Databricks agents and AI Gateway can continue using governed tools, MCP services, and REST APIs.
Data-native analysis stays close to the governed data assets that ground it.
Orchestrate ads

Neutral durable execution

Predict-then-act workflows that turn signals into operational processes.
Durable state across business systems after a model or agent produces a recommendation.
Confidence and human gates before a prediction becomes a consequential action.
Closed-loop outcomes that can be written back for analytics, audit, and future training.
Connection pattern

Three seams. One governed run.

Jobs / signals / APIs

A model result, monitor, job, event bridge, or API call can create or resume the Orchestrate run.

Scoped service identity

Use Databricks-supported authentication for data/model access while Orchestrate applies its own run-level grant and egress policy.

Models as tools + enterprise action

Call model, agent, REST, or MCP endpoints as governed tools, then carry the resulting process into ERP, ITSM, SaaS, or human approval surfaces.

Databricks intelligence

trigger / delegation / intelligence

Aizen Orchestrate

durable state · joins · HITL · identity

Operational systems

governed side effect

Reference workflow

Predict-then-act maintenance across data and operations.

Reference workflow · not a customer claim

A model signal becomes a governed business process rather than a terminal prediction.

This sequence illustrates how the integration pattern maps into a durable run. Production topology, permissions, latency, and exact APIs depend on the customer's environment.

01

Detect the signal

A model, monitor, or data pipeline identifies elevated risk and emits the event.

02

Gather operational context

Orchestrate combines model output with maintenance history, inventory, asset state, or external evidence.

03

Re-evaluate if needed

A model or Databricks agent can be called again as a governed tool during the run.

04

Apply the gate

Low confidence or high impact routes to human review; approved cases proceed.

05

Act and close the loop

The run creates the work order or downstream action and records the outcome for future analysis.

Publication boundary

Be precise about ecosystem claims.

Avoid saying the lakehouse or Databricks agents cannot act: current Databricks agent tooling supports external MCP services and REST APIs. Position Orchestrate as the durable operational state machine that can consume Databricks intelligence and then coordinate action across the wider enterprise.

Databricks working session

Bring the workflow not a generic connector request.

We'll map where Databricks should remain authoritative and where Orchestrate should carry durable process state across the rest of the estate.