How do you stop it from touching data a user shouldn't see?

Several independent layers. Sign-in at the product level. Then policies that scope a user to particular data through the semantic layer, so the agent can work only with what that user could. Operational sources are read-only unless you say otherwise. And a check on the structured response can reject an answer before it is returned if it contains fields you have disallowed.

Can it act on operational systems without a person watching?

Not on anything that matters. A step that changes something plans the change, freezes that plan with a fingerprint of its inputs, routes it for approval with timeouts and escalation, runs only on approval, and then writes an append-only record.

If something goes wrong three months from now, can we reconstruct what happened?

Yes. Look up the workflow and the run id and you get each step, the SQL it ran, the tools it called, the tokens and cost it spent, the outcome of every gate, and which person approved what.

Where does our intellectual property live?

In your own object storage. Workflow specs, the skill library, custom tools, project memory, run history and the audit log are all versioned there. None of it is held in our systems.

Do prompts or data leave our boundary to reach a model?

Only if you route them there. Models are chosen per step from a registry your admin controls. A step that touches sensitive data can be pinned to a model you host, and inside your VPC with your own keys, nothing calls home.

COST · RUNAWAY AGENT QUERIES

Yes, agentic AI-generated SQL can be contained before one Cartesian product burns thousands in warehouse credits.

AI agents don't write warehouse-optimized SQL - and on usage-based pricing, one bloated SELECT, unpruned scan, or accidental CROSS JOIN can auto-scale into thousands in seconds. Here is the problem as we're hearing it, what it costs, and the way out.

Book a demo All problems

THE PROBLEM

AI agents do not write warehouse-optimized SQL, so on usage-based warehouse pricing a single generated query with a bloated SELECT, an unpruned scan, or an accidental CROSS JOIN can trigger aggressive auto-scaling and burn thousands of dollars before anyone notices.

THE PROBLEM ANATOMY

Who it hits

FinOps lead

Owns monthly cloud spend forecasts and now faces unexplained credit spikes from agent sessions.

Platform team

Owns warehouse sizing and concurrency limits and must explain why a single agent query forced maximum clusters.

Data engineering lead

Owns production pipelines and sees agent-driven queries contend for the same warehouses used by ETL.

The situation

A team connects a text-to-SQL agent to the warehouse. In testing against small datasets, everything works. In production, the agent starts generating hundreds of queries a day against multi-billion-row fact tables, and neither the agent nor the warehouse estimates cost before execution. The warehouse responds to queue pressure the only way it knows how: it spins up more and larger clusters. A single generated join with a missing ON clause produces a Cartesian product, the warehouse scales toward its maximum cluster count, memory spills to remote disk, and the query runs for hours because the statement timeout was never tightened. The bill arrives without any warning or trigger.

The specific challenges

Missing join logic

agents default to comma syntax or CROSS JOIN without filters, producing mathematical products of table sizes instead of related rows.

Bloated column lists

generated SELECT * statements scan every column including large JSON and unused attributes, multiplying bytes processed on wide tables.

Absent partition pruning

predicates omit clustering or partition keys, forcing full scans of multi-year fact tables for single-day questions.

Unconstrained auto-scaling

usage-based warehouses respond to intermediate result size by spinning additional clusters, converting one bad plan into sustained peak billing.

No pre-execution bounds

agents lack runtime cost estimates or statement timeouts, so the query runs until the credit quota or human intervention stops it.

WHAT IT COSTS

PRACTICAL

Credit burn

one agent query with an accidental Cartesian product can consume thousands of warehouse credits in under an hour - days of normal team usage.

Queue blockage

legitimate ETL and dashboard queries wait behind the runaway agent workload, extending pipeline SLAs and delaying reports.

BUSINESS

Budget variance

monthly FinOps forecasts become unreliable when a single overnight agent session exceeds the entire planned analytics allocation.

Resource contention

shared warehouses run at sustained high utilization, forcing larger permanent sizing or frequent manual intervention.

EMOTIONAL

Usage anxiety

platform owners hesitate to expand agent access because every new prompt risks another cost event to explain to finance.

Trust erosion

data teams lose confidence in agent-generated SQL after repeated incidents of unexplained spend and stalled pipelines.

THE WAY OUT

A lakehouse compute engine with atomic vCPU billing

Swap in a pilot of e6data alongside the existing cloud data warehouse to:

01
Isolate agent workloads
agent SQL routes to the e6data endpoint while production ETL and BI remain on the current warehouse. Open tables, catalogs, agents, and dashboards stay unchanged. What changes is the compute path for the risky queries - now with independent scaling and cost attribution for agent traffic.
02
Apply query guardrails
thresholds on estimated cost, rows produced, or runtime cancel or alert before a Cartesian product or full scan expands. Existing access controls and governance remain in place - now with prevention of credit-burning plans without rewriting agent prompts.
03
Absorb the query storm
agents and BI tools fire hundreds of concurrent queries with heavy joins, window functions, and aggregations over large fact tables - exactly the shape the engine is built for. Existing batch pipelines stay on the current warehouse untouched during the pilot. What's unlocked is high concurrency without the queue pressure that triggers panic scaling in the first place.
04
Pay for work, not idle compute
billing occurs in 1-vCPU increments for actual execution time only. No idle clusters, no forced T-shirt jumps to the next size. What's kept is the current data model and agent code - but now with predictable spend even when agents issue complex joins.
05
Keep the existing stack
Iceberg, Delta, or Hudi tables continue to be the source of truth. Semantic layers, BI tools, and agent frameworks continue to issue SQL. Adoption is an endpoint swap for selected workloads, not a migration of storage or pipelines.

>95%less network shuffle on agent SQL

1-vCPUbilling, execution time only

1,000+concurrent queries absorbed

The engine reduces network shuffle by more than 95% and evaluates entire query plans to combine heavy operations, so even imperfect agent SQL completes with far lower intermediate data movement and lower total vCPU-seconds.

TALK TO US

Book a demo on your own workloads

Reach out to book a demo, share challenges you’re facing, and tell us how this fits into what you’re currently working on or thinking about.

Problems we’re solving