Agents Do Not Query Like People. Review Has to Match the Volume

A person who is good at SQL usually asks a warehouse a small number of careful questions. Latency, social cost, and the fear of locking production all punish sloppy scans. An agent does not feel those costs. It lists schemas, peeks at columns, tries a join, misses a filter, tries again. That is search, not diligence.

In early September 2026, MotherDuck reported that in a slice of their query history, agents ran on the order of 29 times more queries than humans, with the gap still widening. Treat the multiple as their observation, not a constant of nature. Your ratio might be 5x or 50x. The design implication is stable: review rituals built for one query per question will not survive agent traffic.

If you leave with one uncomfortable truth: you cannot staff a human on every SELECT, and you cannot pretend the tenth retry was “being thorough.” Volume is a different species of traffic. Policy has to name it.

Twelve queries that are one question

A human types: “August net revenue by category versus July.”

An agent, unless you constrain it, often does something like this:

1. SHOW / list schemas
2. List tables matching %order%
3. SELECT * FROM orders LIMIT 5
4. SELECT * FROM order_items LIMIT 5
5. Distinct status values
6. A join that uses user_id on the wrong table
7. The join again with customer_id
8. A date filter in UTC
9. The same in local time
10. A group by category
11. A version that includes refunds twice
12. The version you would have written first if the catalog had said so

That is not incompetence. It is how tool-using models explore. If step 3 is SELECT * on a billion-row table, “exploration” is an incident. If all twelve are logged like privileged writes, the audit log is unreadable by Wednesday.

Your job is not to make the agent query like a person. Your job is to make retries cheap, visible, and bounded, and to put a human only where the blast radius is real.

What volume changes in the system

Audit noise. If every read is a “privileged action,” nobody reads the log when something matters. Separate discovery from create/modify/export.

Cost and lock risk. Retry loops scan. A human notices a three-minute query. An agent may start three more. Timeouts, statement timeouts, row caps, and read-only roles are load-bearing, not style.

Schema thrash. Agents over-request metadata. An unbounded information_schema dump burns tokens and confuses joins. Curate what the agent may see. Staging tables are not a personality test; they are bait.

False confidence. Ten queries can still encode the wrong grain. Volume is not a substitute for a definition. The tenth statement needs the same grain check as the first.

Match the review loop to the traffic

Copy this split. Adjust the borders for your regulator, not for your optimism.

Traffic	Default	Review	Log
List connections, schemas, table names, column types	Auto	None per call	Sampled
SELECT with row/time caps on an allowed connection	Auto or light confirm	SQL always visible in the notebook	Full SQL text
Uncapped extracts, SELECT * on large facts, unbounded CROSS JOIN	Block or hard confirm	Person	Full + reason
Production writes, DDL, save, schedule, ticket, export to CSV/email	Hard confirm	Person, every time	Full + actor

If your organization needs a human on every read, you do not have an analytics agent. You have a slower form. That can be correct for a regulated extract. It is a poor default for exploratory SQL. Mixing the two is how agents get banned after one scare, then everyone pastes CSVs into a consumer chat product with no log.

Design for retries without hiding them

Agents will retry. Make retries the product, not the shame.

• Enforce LIMIT, max bytes, and max runtime in the tool wrapper, not only in a prompt that says “be careful.”
• Prefer aggregate-first tools: counts and sums before samples.
• Surface the attempt list: which SQL ran, which failed, which was kept. Do not collapse ten attempts into “the agent found revenue.”
• Forbid silent schema mutation. A “helpful” CREATE INDEX on production is not helpful.

This is how a teammate debugs a wrong number at 6 p.m. without replaying a chat transcript they do not have.

Context is not an infinite catalog

Vendor blogs this year split context, semantics, and ontology. For traffic control, only one sentence matters: an agent that can see every staging table will query every staging table. That is a locally generated 29x.

Hide staging from the agent connection. Document the five metrics. Name forbidden joins. Refresh when DDL lands. The next post in this series is how small that document can be and still work.

A one-page policy you can adopt without a platform

If you do nothing else this week:

1. Give the agent a read-only role on a replica or a curated schema.
2. Set statement_timeout and a hard row cap in the proxy.
3. Log SQL text for every tool call into the investigation, not only into a SIEM nobody opens.
4. Require a person for anything that is not a capped SELECT.
5. Review a sample of auto-run reads weekly for SELECT * and cartesian joins. Fix the wrapper when you find them. Do not scold the model.

Those five lines already separate teams that can live with agents from teams that will have an event.

Product shape when the volume is real

Kole distinguishes read-only discovery from consequential proposals inside Quantum Lab. Approval workflow is the human gate for work that should not auto-run. The volume problem is why that split exists: you cannot staff a reviewer per metadata lookup, and you should not skip a reviewer for a scheduled write.

The question-to-action loop still needs a person at the action. It should not need a person at every SELECT 1.

Take this home: people query like people; agents query like search. If your controls assume the first, the second will either get banned or get you paged. If you want the attempts, the SQL, and the gate in one notebook, that is what Kole and Quantum Lab are for.