Two things became true at once
AI agents got good enough to write working application code. And a generation of vibe-coding tools made it trivial to stand up a prototype in an afternoon. The demo is no longer the hard part.
What did not get easier is the part that matters to an enterprise: turning that prototype into something governed, transactional, and operationally owned. The prototype runs on a throwaway database with no governance, no isolation, and no path to the lakehouse where the company's real data lives.
The part nobody productizes
Databricks closed the platform side of that gap with Lakebase, a serverless PostgreSQL-compatible database built for the AI era and integrated with the lakehouse. zeb Agentic Lakebase closes the workflow side. It gives an AI agent full transactional ownership of a Lakebase environment and a deployment path onto Databricks Apps.
The result is one pattern that serves two jobs: building net-new applications from a description, and operationalizing the prototypes teams have already built.
What "agent-native" actually means
Most agent patterns give the model read-only context. The agent can see data, reason about it, and answer questions, but it cannot change the world. zeb Agentic Lakebase inverts that. The agent receives a scoped Lakebase environment as its persistent memory and transactional runtime, with a toolset to act on it:
- Query. Read across the schemas it owns, with full SQL, not just a vector lookup.
- Execute. Run transactional statements against live tables, inserts, updates, and deletes inside real transactions.
- Create and evolve. Provision databases and alter schemas as requirements change, in foreign-key-aware order.
- Ingest. Pull data in as it arrives and seed realistic starting data for the application.
The agent does not hand back a script for a human to run. It owns the database, which is what lets it build and operate a real application rather than describe one.
How it works: from a prompt or a prototype to a live app
Under the hood, a LangGraph agent runs a ten-node pipeline. A human-in-the-loop checkpoint sits near the front so a person reviews and corrects the design before any code is generated. The same pipeline serves both modes; only the first step differs.
- Intake (greenfield). Extracts entities, relationships, a project name, theme, and layout from the prompt. If the prompt is too thin, it asks for more rather than guessing.
- Exploration (brownfield). A ReAct agent walks the uploaded prototype, discovering structure, stack, entry points, entities, and seed data through file tools.
- Review checkpoint. The pipeline pauses and presents everything it decided. You approve, or correct the data model, branding, and layout. Structural edits route back for re-analysis.
- Data model. Turns entities and relationships into DDL with proper types, foreign keys, indexes, and a topologically sorted creation order.
- Schema provisioning. Creates a fresh, isolated Lakebase schema and runs the CREATE TABLE statements in dependency order.
- Seed data. Generates realistic sample rows and inserts them through parameterized queries, respecting foreign keys.
- Backend and frontend. Generates FastAPI routes and models, a database layer, and a React frontend with the chosen theme and layout, in parallel.
- Integration and deployment. Validates the bundle, writes app.yaml, deploys a Databricks App, polls to running, and grants the app's service principal access to its schema.
- Self-healing. If integration or deployment fails, the pipeline routes back for an automatic fix attempt, up to two retries, with errors surfaced as they happen.
What it looks like in practice
Greenfield
Describe the app in plain language. The agent extracts entities and relationships, provisions a Lakebase schema, generates a FastAPI backend and React frontend, seeds data, and auto-deploys a live Databricks App. A checkpoint pauses the pipeline to review the data model, branding, and layout first.
Brownfield
Point it at an existing prototype, app screens or a code repo from Lovable, Bolt, v0, or Cursor. The agent explores the project, infers the data model, and migrates it to a production-grade Lakebase plus Databricks Apps deployment.
Reference architecture, layer by layer
Every layer runs inside the Databricks workspace boundary. The accelerator is itself a Databricks App; each app it generates is another, with its own schema and service principal.
Control plane
A React UI and a FastAPI backend run as a Databricks App and drive the LangGraph agent that orchestrates the pipeline and streams progress back to the user.
Agent runtime
A scoped service principal carries the agent's toolset against Lakebase. OAuth tokens auto-rotate; no static passwords are stored anywhere.
Serving layer
Lakebase, a serverless PostgreSQL-compatible database, holds accelerator metadata and each generated app's data in its own schema, named project_{name}_{hex} for hard isolation.
Intelligence
Databricks Model Serving provides the Foundation Model that powers requirement analysis, data modeling, and code generation.
Governance and storage
Unity Catalog governs every generated schema so lineage and access control hold at the application boundary; Volumes hold brownfield uploads.
Output plane
Each generated app is deployed as its own Databricks App with its own service principal and schema, so one app can never reach another's data.
Why this is the right trade
- Transactional ownership. The agent owns a Lakebase environment, not a read-only view, so it can build and operate real apps.
- Data isolation. Each app runs in its own schema with its own service principal. One app cannot reach another's data.
- Inside the boundary. Traffic and data stay inside the Databricks workspace, governed by Unity Catalog, with no static passwords.
- Two front doors. Build net-new from a prompt, or operationalize a vibe-coded prototype. Both reach the same production output.
Where teams put it to work
- Internal operational apps. Trackers, consoles, and admin tools that read governed data and capture state transactionally, without a separate app stack.
- Customer- and partner-facing apps. Net-new applications that need a real database and a deployment path, built on the lakehouse from day one.
- Agentic applications with memory. Products and workflows where an agent needs to write, not just read, backed by a transactional store it owns.
- Reverse ETL surfaces. Scores, segments, and signals computed in the lakehouse, served to an operational app at application latency.
- Prototype operationalization. The demo that won the room, taken to a governed, production-grade deployment instead of rebuilt.
What teams see
- Time to production. From an idea or a prototype to a live, governed app in hours or days, not a quarter.
- One platform. No separate application tier to stand up, secure, and operate alongside the lakehouse.
- Governed by default. Unity Catalog governance and schema isolation are there from the first app, not retrofitted.
- A reusable pattern. The same pipeline and guardrails apply across teams and apps, so the second app is faster than the first.
Getting started
An engagement starts small and proves the pattern on one real app before it scales.
- Prerequisites. A Databricks workspace with Lakebase enabled, Unity Catalog, and a Model Serving (Foundation Model) endpoint your policy allows.
- Pick a mode. Greenfield from a prompt for a net-new app, or brownfield to operationalize an existing prototype.
- Run the first app in a workshop. A scoped use case goes from prompt or prototype to a live, governed Databricks App, with your team at the review checkpoint.
- Roll out with governance. Standardize the schema-isolation and service-principal pattern, then let teams self-serve new apps on the same rails.
Honest trade-offs
- Not a bespoke-app replacement. Where every line must be hand-crafted, this is a starting point, not the finish.
- Strongest when already on Databricks. The time-to-production gain is real where teams want governed apps on their own lakehouse data.
- Model and data policy apply. The Foundation Model endpoint and data locality must match your controls.
- Production means an SDLC. Generated apps go through the same review, testing, and change control as any production app.