ETL Infrastructure for AI Agents: How SchemaBounce Connects Databases to LLM Workflows

AI agents are no longer a research novelty — they're being deployed inside real companies to automate workflows, answer internal questions, and act on live data. But there's a persistent infrastructure gap that slows every team down: agents can't reliably read from or write back to the databases your business actually runs on.

This post explains why traditional ETL falls short for agentic workloads, what "ETL for AI agents" actually means technically, and how SchemaBounce's Kolumn CLI solves the schema-visibility problem that blocks most teams.

---

Why Traditional ETL Breaks for AI Agents

Traditional ETL (Extract, Transform, Load) was designed for batch pipelines moving data between warehouses on a schedule. The assumptions baked in:

• One-directional: data flows from source to destination, not back
• Schema-static: the pipeline is rebuilt when schemas change
• Latency-tolerant: hourly or daily refresh cycles are fine
• Human-in-the-loop: schema changes go through a migration PR and a deploy

AI agents flip every one of these assumptions.

An agent querying your customer database to answer a support question needs real-time read access. An agent writing back a resolved ticket status needs bidirectional access. And when your engineers add a resolved_at column to the tickets table at 2pm on a Tuesday, the agent that runs at 2:05pm needs to know about it — without a redeploy.

The mismatch isn't a tooling preference. It's a fundamental architectural difference.

Traditional ETL          vs.     Agent ETL
─────────────────────────────────────────────
Batch (hourly/daily)     →       On-demand, event-driven
Source → Destination     →       Bidirectional read/write
Schema baked into config →       Schema discovered at runtime
Pipeline = code artifact →       Schema state = live metadata

---

The Schema Visibility Problem

Before an agent can query a table, it needs to know the table exists, what columns it has, what types those columns are, and which ones are safe to write to.

This is the schema visibility problem. It sounds trivial. It isn't.

Small data teams (2–5 engineers) typically manage schemas through a mix of migration files, ALTER TABLE statements run ad hoc, and tribal knowledge. There's no single source of truth the agent can query. Options teams try:

1. Hardcode the schema in the agent's system prompt — breaks silently on every migration
2. Pull schema from information_schema at runtime — works, but raw DDL is noisy, expensive to send to an LLM, and reveals everything (including sensitive columns you don't want the agent to touch)
3. Build a custom schema registry — takes weeks, requires maintenance, and most small teams don't have the bandwidth

None of these scale. What agents need is a layer that maintains a stateful, filtered view of the schema — updated automatically when migrations run, queryable via a simple API.

That's what Kolumn CLI is.

---

What Kolumn CLI Does Differently

Kolumn CLI gives data engineers remote, stateful schema management. From the agent infrastructure perspective, the key capabilities are:

1. Remote Schema Visibility

Kolumn maintains a live registry of your database schema — tables, columns, types, nullability, and relationships — updated as migrations run. Agents query the registry rather than raw information_schema.

# Connect Kolumn to a Postgres database
kolumn connect --db postgres://user:pass@host:5432/mydb --name prod-db

# Inspect current schema state
kolumn schema show prod-db

# Output:
# Table: tickets
#   id          uuid        NOT NULL  PK
#   customer_id uuid        NOT NULL  FK → customers.id
#   status      varchar(20) NOT NULL
#   created_at  timestamptz NOT NULL
#   resolved_at timestamptz NULL      ← added 2026-05-20

The agent asks Kolumn for the schema. Kolumn returns only what the agent is authorized to see — not the full raw DDL of every internal table.

2. Stateful Migration Tracking

Kolumn tracks migration history, so your agent knows not just the current schema but what changed and when. This matters for agents that process records created before vs. after a schema change.

# See migration history
kolumn migrations list prod-db --limit 10

# Output:
# 2026-05-20T14:22:00Z  add_resolved_at_to_tickets     applied
# 2026-05-15T09:10:00Z  add_customer_tier_column       applied
# 2026-05-10T16:45:00Z  create_sla_policies_table      applied

3. Schema-Aware Agent Reads

Once an agent knows the current schema state via Kolumn, it can generate correct, targeted SQL — referencing real column names, using the right types, and avoiding deprecated fields.

# Agent workflow: fetch schema context, then query
schema = kolumn_client.get_table_schema("prod-db", "tickets")
# Returns: { table: "tickets", columns: [...], fk_refs: [...] }

query = llm.generate_sql(
    user_request="Find all unresolved tickets older than 7 days",
    schema_context=schema
)
# Generated: SELECT id, customer_id, created_at
#            FROM tickets
#            WHERE status != 'resolved'
#            AND resolved_at IS NULL
#            AND created_at < NOW() - INTERVAL '7 days'

Without schema context, the LLM guesses column names. With Kolumn providing a live schema snapshot, the generated SQL is accurate and executable.

---

Architecture: Connecting Databases to LLM Workflows

Here's what the full architecture looks like when SchemaBounce is the ETL layer between your databases and your AI agents:

graph LR
    subgraph Data Sources
        PG[(PostgreSQL)]
        DW[(Data Warehouse)]
        SAAS[SaaS APIs]
    end

    subgraph SchemaBounce Layer
        KC[Kolumn CLI]
        SR[Schema Registry]
        EP[ETL Pipeline]
    end

    subgraph Agent Runtime - OpenCLAW
        AG[AI Agent]
        LLM[LLM]
        TOOLS[Tool Calls]
    end

    PG --> KC
    DW --> KC
    SAAS --> EP
    KC --> SR
    EP --> SR
    SR --> AG
    AG --> LLM
    LLM --> TOOLS
    TOOLS --> SR
    SR --> PG

The agent never touches the database directly. All reads and writes flow through the SchemaBounce layer, which enforces schema awareness, tracks state, and maintains an audit trail of what the agent read or modified.

---

A Practical Agent Workflow

Here's a concrete end-to-end example: an OpenCLAW agent that monitors SLA compliance and writes back status updates.

Step 1 — Schema discovery (run once per deployment, refresh on schema change events):

kolumn schema export prod-db --format json --output ./agent-schema-context.json

Step 2 — Agent reads tickets needing review:

The agent uses the exported schema context to generate a query. It reads from tickets where status = 'open' and created_at < NOW() - INTERVAL '48 hours'.

Step 3 — Agent evaluates SLA breach:

The LLM analyzes each ticket, determines if the SLA threshold is breached, and classifies the required action.

Step 4 — Agent writes back:

# Write-back via SchemaBounce ETL pipeline
result = schemabounce_client.write(
    source="prod-db",
    table="tickets",
    record_id=ticket_id,
    updates={"status": "sla_breached", "resolved_at": None}
)
# Kolumn validates the write against the registered schema before execution

The write is schema-validated before it hits the database. If status doesn't accept "sla_breached" as a value (wrong type, constraint violation), the agent gets a clear error — not a silent database failure at 3am.

---

Why This Matters for Small Data Teams

If you're a data engineer on a team of two to five people, you're probably managing three or four databases, a warehouse, a handful of SaaS integrations, and now a backlog of "add AI to this" requests from your product team.

You don't have time to build a custom schema registry. You can't hardcode schemas into every agent prompt and manually update them after every migration. And you can't afford the downtime or data quality issues that come from agents running blind.

SchemaBounce's approach — stateful schema management as a first-class infrastructure layer — gives your agents the same thing your engineers take for granted: a reliable, up-to-date picture of what the database looks like right now.

The result is agents that generate correct SQL, write back safely, and don't break silently when your schema evolves.

---

Getting Started

If you're building LLM-powered workflows and need your agents to interact with real databases:

1. Connect your database with kolumn connect
2. Export schema context for your agents with kolumn schema export
3. Set up write-back pipelines through the SchemaBounce ETL layer
4. Register schema change webhooks so agents always have current context

The infrastructure problem is solved. Your agents can focus on the actual work.

---

SchemaBounce provides ETL infrastructure for AI agent workflows. Kolumn CLI is the data engineer's tool for stateful remote schema management.

Related reading

• Managing Remote Database Schemas with Kolumn CLI: A Practical Guide for Data Engineers
• CDC vs ETL: What's the Difference and When to Use Each
• 133 Built-in Tools vs 20 GPT-4o Wrappers: Why Deterministic Agent Tools Win