Source-linked AI summary
Safe, Untrusted, "Proof-Carrying" AI Agents: toward the agentic lakehouse
Jacopo Tagliabue, Ciro Greco
TL;DR
The paper asks how agents can manage data lifecycles in sensitive lakehouse workloads, and proposes programmable lakehouse abstractions with a Bauplan pipeline-repair prototype. It presents branching and declarative environments as agent-ready mechanisms for observability and reproducibility, while framing the prototype as a feasibility demonstration rather than a full benchmark.
Problem
The paper asks how agents can manage lakehouse data lifecycles when lakehouses support sensitive workloads and are not designed for point-wise end-to-end automation.
Source: §I · p. 1Method
The paper develops API-first, code-based lakehouse abstractions and uses Bauplan with an agentic loop to prototype pipeline repair.
Source: §I · p. 1, §II · p. 1Results
The prototype is presented as a feasibility demonstration of safe-by-design data agents, not as a full-fledged experimental benchmark.
Source: §I · p. 1Takeaways & Limitations
The paper argues that typed, documented lakehouse methods for observing runs and reproducing pipelines can be exposed to agents by wrapping them in MCP routes.
Source: C. Code as the universal interface · p. 3The working prototype is a feasibility demonstration, not a full-fledged experimental benchmark.
Source: §I · p. 1
Abstract
from arXiv · showhide
Data lakehouses run sensitive workloads, where AI-driven automation raises concerns about trust, correctness, and governance. We argue that API-first, programmable lakehouses provide the right abstractions for safe-by-design, agentic workflows. Using Bauplan as a case study, we show how data branching and declarative environments extend naturally to agents, enabling reproducibility and observability while reducing the attack surface. We present a proof-of-concept in which agents repair data pipelines using correctness checks inspired by proof-carrying code. Our prototype demonstrates that untrusted AI agents can operate safely on production data and outlines a path toward a fully agentic lakehouse.
I. INTRODUCTION
The paper asks how agents can manage lakehouse data lifecycles despite the difficulty and breadth of automating sensitive production workloads. It introduces programmable-lakehouse abstractions and a pipeline-repair prototype as a preliminary answer.
I. INTRODUCTION
- The paper frames agent management of lakehouse data lifecycles as an open question because lakehouses support sensitive workloads and are built for human collaboration, not point-wise automation.The paper describes the automation challenge as both too hard and too broad.Source: §I · p. 1
- Pipelines are a case study because they occupy substantial developer time and compute, require significant repair effort, and test agents in high-stakes scenarios.The paper cites prior work for each motivation: workload share,, repair effort,, and scenario difficulty,.Source: §I · p. 1
- The paper introduces code-based abstractions for lakehouse lifecycles, reviews trust and correctness concerns, and releases a proof-of-concept pipeline-repair agent.The prototype uses Bauplan and an agentic loop; the paper presents it as a feasibility demonstration, not a full experimental benchmark.Source: §I · p. 1
- The authors say the paper’s insights—programmability and safety—can be replicated independently of the chosen APIs.They see the paper as useful both as a conceptual map and as inspiration for inspecting and tinkering with implementations.Source: §I · p. 1
II. A PROGRAMMABLE LAKEHOUSE
A programmable lakehouse exposes its data lifecycle through code-based abstractions. Bauplan serves as an implementation example, while its composable design is presented as portable across architectures.
II. A PROGRAMMABLE LAKEHOUSE
- A programmable lakehouse exposes data, user and infrastructure management, pipeline and query execution, and runtime observability through code abstractions.The interfaces include server-side APIs, SDK methods, and CLI shortcuts.Source: §II · p. 1
- Bauplan snippets serve as sample implementations, and the platform’s composable nature makes the described functionality replicable in different architectures.The section separates pipeline lifecycle into definition and execution.Source: §II · pp. 1–2
- The paper provides open-source code for its implementation.The repository is identified as the agentic-lakehouse project.Source: §II · p. 1
A. Pipeline definition
The paper models pipelines as directed acyclic graphs of transformations and describes function-based definitions with declarative inputs, outputs, and environments. Its examples use two transformations to produce tables A and B.
A. Pipeline definition
- A pipeline is a DAG of transformations that progressively cleans, augments, or aggregates source tables into intermediate and final assets.The recurring example takes two NYC taxi tables and defines output tables A and B through transformations 1 and 2.Source: A. Pipeline definition · p. 2
- Function-as-a-service abstractions express business logic as plain functions with a Table(s) →Table signature, with DAGs chained through naming conventions.The paper says these abstractions map naturally to a serverless runtime.Source: A. Pipeline definition · p. 2
- Declarative I/O and infrastructure isolate functions, specify Python environments, and let users declare table inputs and desired outputs for platform-managed physical operations.The example notes that separate functions can use different pandas versions.Source: A. Pipeline definition · p. 2
B. Pipeline execution
Pipeline execution uses Git-inspired branches and merges to keep production reads while sandboxing writes. Successful runs merge atomically; failed runs leave production unchanged, supporting reproducible runs and a testing-and-review hook.
B. Pipeline execution
- The run API repurposes Git concepts for table evolution, treating data and compute as a logical whole despite physical decoupling.Branches and merges represent sequences of commits and atomically combine commits from separate branches.Source: B. Pipeline execution · p. 2
- The branch-and-merge design provides a natural hook for testing and reviews, and runs are immutably and deterministically identified by their starting commit and a copy of the code.These are presented as execution-level Git-for-Data use cases.Source: B. Pipeline execution · p. 2
- A failed run after materializing A does not merge, so production retains a consistent pair of tables rather than mixing old and new outputs.Runs start from production data on a copy-on-write branch, and successful outputs are merged atomically.Source: B. Pipeline execution · p. 2, Figure 1 · p. 2
- Branch-then-merge execution allows production data to be read while writes remain sandboxed until success, avoiding dirty reads and production damage from failed runs.A successful run promotes its materialized tables to main in one atomic operation.Source: B. Pipeline execution · p. 2
C. Code as the universal interface
Programmable lakehouses expose observability and reproducibility through typed methods that can be wrapped as agent tools. Their code interface is presented as easier for agents to use, cloud systems to run, and humans to supervise than the fragmented interfaces of traditional systems.
C. Code as the universal interface
- Typed methods for observing present and past runs and reproducing pipelines can be exposed to agents by wrapping them in MCP routes.The paper argues that relevant programmable-lakehouse abstractions already make it an agentic lakehouse.Source: C. Code as the universal interface · p. 3
- Code offers a shared interface that agents can master, the cloud can run, and humans can supervise.The paper contrasts this with practitioners switching among Spark clusters, notebooks, SQL editors, and cloud warehouses.Source: C. Code as the universal interface · p. 3
III. THE SAFETY CHECKLIST
Purpose-built abstractions are necessary but not sufficient for production pipeline repair: the paper addresses trust in data and code, and correctness in data and code. Its proposed safeguards include platform-mediated access, isolated execution, controlled merges, and owner-defined checks of pipeline outputs.
III. THE SAFETY CHECKLIST
- Production pipeline repair requires purpose-built abstractions and additional safeguards for trust and correctness.The paper identifies trust and correctness concerns over malicious or incorrect use as requirements to address.Source: §III · p. 3
- Platform-mediated I/O and fine-grained RBAC over API keys restrict agents from accessing unauthorized data.Agents have no access to the physical data layer, and operations occur in platform space.Source: §III · p. 3
- Isolated function processes, no internet access, and a package whitelist constrain untrusted code execution.The declarative syntax makes package allowance a whitelist check, with one dependency-management entry point.Source: §III · p. 3
- Incomplete pipelines do not affect downstream systems, while merge permissions and commit history support human review and reversion.Removing merge-to-main permission makes human review necessary before production.Source: §III · p. 3
- An owner-defined verifier checks whether generated tables meet criteria before an agent branch can be merged.The verifier is a Branch →bool function; its checks reflect business context and use the same APIs as the agent.Source: §III · p. 3
IV. A PROOF OF CONCEPT
After describing a failed run, the paper asks whether an agent can repair it and turns to an agentic loop and preliminary conclusions from the prototype.
IV. A PROOF OF CONCEPT
- Run 2 failed, setting up the paper's question of whether an agent can repair it.The passage refers to the failed run shown in Fig. 1.Source: §IV · p. 3
- The paper combines the preceding safety and lakehouse abstractions into an agentic loop.Source: §IV · p. 3
- The prototype is used to draw preliminary conclusions.Source: §IV · p. 3
A. The self-repairing setup
The self-repairing setup uses Bauplan and an MCP server to expose lakehouse APIs to an agent loop, with a verifier checking before merge. The figures depict a two-step pipeline and an outer-loop production check.
A. The self-repairing setup
- The setup uses Bauplan as its programmable lakehouse and exposes its APIs as tools through the Bauplan MCP.Tools support observability, data exploration, and execution.Source: A. The self-repairing setup · p. 3
- smolagents handles the ReAct loop, tool calls, and logs, with reasoning performed in Python.The passage says this is effective for pipeline reasoning compared with JSON-based tool calling.Source: A. The self-repairing setup · p. 3
- LLM inference is provided through a configurable LiteLLM interface connecting OpenAI, Anthropic, and TogetherAI.Source: A. The self-repairing setup · p. 3
- A Branch →bool verifier performs the proof-checking step before an agent branch can merge into main.The figure shows a deterministic check in the outer loop verifying whether an answer is safe to merge to production.Source: A. The self-repairing setup · p. 3, Figure 3 · p. 4
- The pipeline example has two source tables, two compute steps, two output tables, and multiple downstream consumers.The figure depicts a two-node DAG, with compute steps 1 and 2 and tables A and B.Source: Figure 2 · p. 4
B. Running an experiment
The experiment demonstrates a pipeline-repair workflow built on programmable lakehouse abstractions, while the authors leave broad exploration of the experimental space beyond scope. Model performance varies, but even failed models did not disrupt the lakehouse or produce unsafe behavior.
B. Running an experiment
- The sample run retrieves logs, queries lake state, specifies infrastructure changes declaratively, creates debug branches from production data, and runs code safely.The example simulates a package mismatch around NumPy 2.0 and pandas 2.0 that causes container crashes.Source: B. Running an experiment · p. 4
- The paper demonstrates feasibility and maps abstractions, but a thorough exploration of the experimental space is beyond scope.Source: B. Running an experiment · p. 4
- Even when models failed, the lakehouse exhibited no disruption or unsafe behavior.Frontier models varied in success rate, token usage, and number of tool calls.Source: B. Running an experiment · p. 4
- The authors note that Snowflake with dbt do not support agentic repair despite having MCP servers, so MCPs alone are insufficient for automation.Source: B. Running an experiment · p. 4
- Switching models is a single configuration change, allowing imagined budget-constrained, step-dependent model selection.The authors also envision data branches supporting concurrency control for parallel models in time-constrained settings.Source: B. Running an experiment · p. 4
V. CONCLUSION AND FUTURE WORK
The conclusion argues that programmable lakehouses are already agentic in their abstractions and that declarative DAGs and Git-like data management suit safe-by-design agent use. The prototype excludes massive parallelism, which the authors identify as a primary OLAP challenge for agentic data exploration.
V. CONCLUSION AND FUTURE WORK
- Programmable lakehouses are presented as supporting agentic reasoning across the data lifecycle, beyond the specific tasks targeted by most infrastructure agents [23].Source: §V · p. 4
- Declarative DAGs and Git-like data management are described as well suited to safe-by-design agentic usage.Source: §V · p. 4
- Massive parallelism is outside the prototype’s scope and is identified as a primary OLAP challenge for agentic data exploration [24].Source: §V · p. 4