Alien
Islo proved for me that the dream of having an actual software factory is actually realistic.
Solutions
Agentic data engineering powered by Databricks, run on Islo.
Connect a Databricks workspace and use Databricks Model Serving to drive AI agents with scoped, audited access to the lakehouse. Data engineering, analysis, and batch jobs run inside Islo's isolated, secure agent environments.
What's slowing you down
Data agents need real compute, not a toy sandbox
A notebook running in a generic container cannot touch the scale of data your pipelines actually process. Agents doing real data work need a secure runtime and powerful compute.
Nobody wants an agent holding a standing warehouse credential
A workspace token sitting in context an agent can read is a liability the moment that agent goes off script. Data access needs to be scoped to the job and gone when the run ends, not a permanent key a model can see.
A job that finishes is not the same as a job that is right
Batch jobs and analysis need evidence, not a status code. Without a record of what ran, what it touched, and what it returned, "it completed" says nothing about whether to trust the output.
How the integration works
Connect your Databricks workspace
Add a Databricks connection the same way you would AWS or GCP: scoped credentials, held at the gateway, never inside context an agent can read.
Agents get brokered access to your compute
A run requests exactly the cluster and data access it needs. The gateway injects credentials at egress, so the token that reaches Databricks is never the token the agent could expose.
The job runs on real data, in isolation
Each run gets its own computer. A pipeline or analysis job that misbehaves cannot reach another run, another workspace, or anything outside what it was scoped for.
You get a result and a full trail
Every query and job Databricks executed for that run is logged per request, so reviewing it means reading a trail instead of re-running the job to check.
How Islo maps to it
Compute
Your Databricks clusters, not a stand-in
Agents run data engineering, analysis, and batch jobs on the compute engine you already operate, sized for real workloads instead of a sandboxed approximation.
Credentials
Databricks access brokered at the gateway
Tokens are scoped per run and injected at egress. An agent can use your workspace without ever holding a credential that outlives the job.
Isolation
One computer per run
A batch job or exploratory query runs in its own sealed environment, so a bad job affects nothing beyond the run it belongs to.
Audit
Every query and job logged
A per-request trail of what an agent asked Databricks to do, exportable to the SIEM you already use for review.
Where teams start
Teams running agents on Islo
Common questions
What does the Databricks integration actually connect?
It connects the Islo agent runtime to your Databricks workspace so you, or your agents, can use any AI models available from Databricks Model Serving against your data, with the same credential brokering and isolation every other Islo run gets.
Where does the data and compute actually run?
On your Databricks workspace, on the clusters you already operate. Islo provides the isolated agent computer and the scoped access to reach them, not a copy of your data.
How are Databricks credentials kept safe from the agent?
Credentials are held at the gateway and injected at the point of egress, so the token that talks to Databricks is never a token visible in context the agent can read.
What kind of work fits this integration?
Data engineering pipelines, exploratory analysis, and batch processing jobs that need real compute and benefit from an agent driving them end to end, with a verifiable trail when they finish.
Do we need an existing Databricks workspace to start?
Yes. Connect the workspace you already run, the same way you would connect AWS or GCP, and agents get scoped access to it from there.