Grounded in your lakehouse. Governed in Unity Catalog.
Coding agents are arriving on your data platform whether you're ready or not. lakecode is built for the team that has to answer for them: the substrate ingests Unity Catalog lineage and notebooks, grounds every agent in lakehouse reality, and projects what agents know back into UC — so you govern them with the tooling you already trust.
The payoff: a domain expert for your data platform — scoped to a service, a dataset, or the whole lakehouse, and consultable by your team and your agents.
Databricks-native · runs in your workspace
Prefer email? Reach the founder directly.
select e.name, c.claim, c.confidence, c.source
from entities e join claims c on c.entity_id = e.id
where e.corpus = 'payments-api' and c.reviewed
order by c.confidence desc limit 5;The glass box — every claim is a row you can query, with confidence and provenance as columns.
Native to the platform you already operate.
lakecode doesn't sit beside Databricks — it's assembled from it. Each piece of the product maps onto a primitive your platform team already governs.
Mount it into Omnigent, too.
Omnigent is the open-source agent meta-harness Databricks just released — a layer over Claude Code, Codex, Pi, or your own agent. Mount lakecode's substrate into it with a 6-line MCP config, and every agent it runs gains a compounding, cross-session memory: one shared substrate it reads from and writes back to. No code changes on either side.
verified end-to-end · 2026-06
Omnigent runs
every agent it spawns
one shared substrate
compounds across every session
A conformant MCP server.
lakecode exposes 20 substrate tools — query_substrate, record_finding, pull_entity_source, … — serving live grounded data, spawned exactly the way Omnigent spawns any stdio MCP server.
Omnigent's own client mounts it.
Driven through the same MCP client Omnigent uses to run an agent, it discovered all 20 tools, and a query_substrate call returned correct grounded context on the first request — the right intent, the right anchor, and the exact relevant entities.
verified end-to-end · 2026-06 · driven through Omnigent's own MCP client · reproducible verification shipped
The substrate-over-MCP thesis, validated on a second harness: the engine and the MCP surface pay off the moment any Omnigent agent mounts lakecode.
Builds on Databricks stateful agents.
Databricks stateful agents give each agent durable state in Lakebase — per thread, per user. lakecode runs on that same Lakebase foundation and mounts over MCP, so a stateful agent gains what per-agent state can't: one shared, governed substrate across every agent and human — ranked claims, provenance, and review, projected into Unity Catalog. Their primitive; your org's memory.
lakecode
one shared, governed substrate — across every agent and human
- ranked claims · provenance · gated write-back
- projected into Unity Catalog lineage & audit
- mounts over MCP — into a stateful agent, or any agent
Databricks stateful agents
durable per-agent state in Lakebase
- per-thread + per-user memory · LangGraph checkpointing
- the runtime-state primitive you already run
You can't adopt what you can't govern.
Black-box agent memory is a compliance non-starter on a data platform — and an ontology baked into a vendor's tool is just another black box: it makes that tool smarter, but you still can't see, query, govern, or move what it learned. Don't trade one black box for another. Ours is the glass box — an ontology your agents act on out of the box, not a vendor tool that just got smarter. Before an agent touches production work, your platform team needs three answers — continuously, not a one-time review — and the glass box answers all three.
What does the agent know?
Every piece of substrate knowledge is a structured claim with confidence — inspectable and editable in the console, not embedded in opaque weights or a context window that vanished.
Where did it learn it?
Claims carry provenance: the source file, commit, notebook, lineage edge, or session that produced them. Knowledge without a paper trail doesn't get promoted.
Who approved it?
Agent write-back is gated. Proposed knowledge climbs a promotion ladder — local → workspace → org — with review before anything becomes org-wide truth.
what the agent knows · payments-api
Entities, the claims that connect them, and the source and sign-off behind each — queryable in the open, not buried in a vendor's weights.
The lakehouse loop.
The same work → capture → govern → ground loop, wired into the platform you already operate.
01
Ingest the lakehouse.
Unity Catalog metadata, table- and column-level lineage, and notebook↔table reference graphs flow into the substrate — alongside your repos and docs. The agent learns how your data actually derives, not how the wiki says it does.
02
Ground the agents.
Sessions auto-prime from lakehouse knowledge: which IDs are valid, why a constant is what it is, what failed last quarter. This is the knowledge-bound regime — where grounding flips answers from confidently wrong to correct (0/3 → 3/3, 2026-06-08).
03
Project back into UC.
What agents learn is projected into Unity Catalog lineage and audit surfaces. Agent knowledge shows up where your governance reviews already happen — your controls become the distribution channel, not an afterthought.
04
Run it in-workspace.
The Databricks edition ships as an in-workspace Databricks App. We validate the governance projection with your platform team during onboarding, against a pass/fail bar agreed up front.
step 03, as it appears in unity catalog
agent knowledge, attached to the lineage your governance reviews already walk
Everything runs in your workspace.
The same substrate and compiler run inside your governed Databricks environment — governed storage, continuous ingest, agent serving, traceable evidence. Nothing leaves the workspace.
customer databricks workspace
1 engineering sources
where knowledge already lives
- GitHub · repos
- Slack · Jira · docs
- CI · incidents · sessions
2 Jobs / Lakeflow
turn fragments into memory
- ingest · extract claims
- embed + detect patterns
- refresh changed memory
3 Lakebase substrate
managed Postgres + pgvector
- entities · claims · edges
- embeddings · findings
- evidence · lifecycle
4 agent layer
compiled memory into work
- Databricks App · CLI
- Mosaic serving
- MCP · PR bots
↩ session findings · fixes · decisions flow back into the substrate
Agents read compiled context and write back governed memory — with every retrieval, plan, citation, and model call traceable.
Start in the terminal. Scale into governed engineering memory.
The bar an own-agent has to clear — and the evidence.
Governance requires owning the loop — capture at commit time and gated write-back can't be bolted onto someone else's agent. So lakecode has to be a credible agent in its own right. The bar, with receipts:
6/6 = 6/6
Agent mechanics at parity
Coding parity with Claude Code; bug-fixes byte-identical, same model both arms.
coding-bench v1 · 2026-06 · n=1/task
0/3 → 3/3
A decisive grounding edge
On knowledge-bound tasks, one substrate claim flips correctness from 0% to 100% — the regime where lakehouse knowledge lives.
grounded-coding bench · 2026-06-08 · claude-sonnet-4-6
Glass box
Governance built in
Provenance on every claim, gated write-back, promotion governance — and the UC projection validated with your platform team during onboarding.
validation gate agreed per design partner
Honest terms for the beta.
What we offer design partners today — written into a one-page agreement, not just this website.
isolation & data handling
- Dedicated database per beta org — physical isolation
- Cross-tenant isolation proven by automated test before handover
- The substrate is your data: exportable any time, deleted on exit
- Backups with point-in-time recovery, restore tested
- BYO Anthropic key, or a managed key with a spend cap
onboarding, done with you
- We ingest your repos, docs, and (wave 2) UC metadata
- A golden-question acceptance set written with your team, pass bar agreed before commitment
- The flywheel demo — cold fail, teach once, warm pass — live on your repo
- Weekly usage & cost reports; named feedback channel
- Known rough edges disclosed up front
Not on Databricks? The team substrate stands alone.
The shared org substrate — promotion ladder, review, provenance — works on any codebase. The lakehouse edition is the enterprise wedge, not the boundary.
Become a design partner.
One org at a time, onboarded personally — with an acceptance bar we agree on before you commit.
Prefer email? Reach the founder directly.