zeb Agentic Lakebase. From prototype to production: agentic apps that own their data.

What "agent-native" means here

Most agent patterns give the model read-only context. zeb Agentic Lakebase inverts that. The agent owns the database, which is what lets it build and operate real apps rather than describe one.

• Query and execute

  The agent reads across its schemas and runs transactional statements against live tables, not just retrieval for context.

• Create and evolve schemas

  It provisions Lakebase databases and alters schemas as requirements change, in FK-aware order.

• Ingest as data arrives

  It seeds and ingests data, then hands back a running application rather than a script for a human to run.

Aligned to the Lakebase GTM priorities

• Application development. Prompt to live URL inside the workspace.
• Agentic AI with low-latency serving. Transactional reads and writes at application latency.
• Reverse ETL. Governed lakehouse data becomes an operational, application-facing surface.

The ten-node pipeline

• Intake (greenfield). Extracts entities, relationships, a project name, theme, and layout from the prompt; asks for more if the prompt is thin.
• Exploration (brownfield). A ReAct agent walks the uploaded prototype, discovering structure, stack, entry points, and entities.
• Review checkpoint. Pauses and presents everything; you approve or correct. Structural edits route back for re-analysis.
• Data model. DDL with proper types, foreign keys, indexes, and a topologically sorted creation order.
• Schema provisioning. Creates a fresh, isolated Lakebase schema and runs CREATE TABLE in dependency order.
• Seed data. Realistic sample rows via parameterized queries, respecting foreign keys.
• Backend and frontend. FastAPI routes and models, a database layer, and a themed React frontend, in parallel.
• Integration and deployment. Validates the bundle, writes app.yaml, deploys a Databricks App, and grants the app's service principal access to its schema.
• Self-healing. A failed integration or deploy routes back for an automatic fix, up to two retries, with errors surfaced live.

Two modes, one production output

Both modes converge on the same production output: an isolated Lakebase schema, a generated app, a scoped service principal, and Unity Catalog governance.

Layer by layer

• Control plane

  A React UI and FastAPI backend run as a Databricks App and drive the LangGraph agent that orchestrates the pipeline.

• Agent runtime

  A scoped service principal carries the agent's toolset against Lakebase; tokens auto-rotate, no static passwords.

• Serving layer

  Lakebase holds metadata and each app's data in its own schema, named project_{name}_{hex} for hard isolation.

• Intelligence

  Databricks Model Serving provides the Foundation Model for analysis, data modeling, and code generation.

• Governance and storage

  Unity Catalog governs every generated schema; Volumes hold brownfield uploads.

• Output plane

  Each app deploys as its own Databricks App with its own service principal and schema.

Representative use cases

• Internal operational apps. Trackers, consoles, and admin tools on governed data, with transactional write-back.
• Customer- and partner-facing apps. Net-new apps that need a real database and a deployment path, built on the lakehouse.
• Agentic applications with memory. Products where an agent must write, not just read, backed by a store it owns.
• Reverse ETL surfaces. Scores and signals computed in the lakehouse, served to an app at application latency.
• Prototype operationalization. The demo that won the room, taken to a governed, production-grade deployment.

What teams see

• Time to production. From an idea or a prototype to a live, governed app in hours or days.
• One platform. No separate application tier to stand up, secure, and operate.
• Governed by default. Unity Catalog governance and schema isolation from the first app.
• A reusable pattern. The same rails apply across teams, so the second app is faster than the first.

Getting started

• Pick a mode. Greenfield from a prompt, or brownfield to operationalize a prototype.
• Run the first app in a workshop. A scoped use case goes from prompt or prototype to a live Databricks App, with your team at the checkpoint.
• Roll out with governance. Standardize the schema-isolation and service-principal pattern, then let teams self-serve.