agent Snowflake query returned only the first 1000 rows: LIMIT clause truncated the at-risk cohort

TL;DR

A round number in a result set is a confession. Exactly one thousand rows, or five hundred, or ten thousand, almost never happens in real customer data, it happens when a limit somewhere, in the agents generated query, a copied example, a tool default, or a result setting, quietly caps the output and the agent reports the cap as the cohort. Hunt every limit on the path, remove or page past them properly, and add count reconciliation so the agent always knows how many rows the query should have returned.

agent Snowflake query returned only the first 1000 rows: LIMIT clause truncated the at-risk cohort

Use this when

• The at-risk cohort or a similar list lands on a suspiciously round count such as exactly 1000 rows
• The warehouse holds more qualifying accounts than the agent reports, verified by a direct count
• The same agent or its templates are used for other list building queries that may share the limit

Not for this skill when

• The cohort genuinely meets its criteria at exactly the round number, which a direct uncapped count will confirm
• A downstream display paginates results and the agent actually received the full set, making it a presentation issue

Steps

1. Count the truth in Snowflake directly. Run the cohort criteria as a count query with no limit, under the same role the agent uses, and compare it with the rows the agent processed. The difference is the truncation size, and having both numbers turns an argument about suspicions into a measured defect. Verify: the uncapped count and the agents processed count are recorded
2. Find the limit on the path. Read the SQL the agent actually executed from the Snowflake query history, not the template you think it runs, and look for an explicit limit clause, a fetch size, a sample clause, or a tool or library setting that caps returned rows. Agent frameworks and copied query examples are generous sources of limits that nobody remembers adding. Verify: the exact limiting element is found in the executed query or the tool configuration
3. Fix it at the right layer. Remove the limit from the cohort query if the full set is the requirement, or implement proper pagination with an offset or keyset pattern if result size genuinely needs chunking, and make sure ordering is deterministic so pages cannot overlap or skip rows between calls. Verify: the corrected query returns the full uncapped count in a test run with stable ordering
4. Re-run the affected scoring and repair the consequences. Regenerate the at-risk cohort completely, diff it against the truncated version, and brief CSMs on the accounts that were invisible, prioritising any whose risk signals are old, because those accounts sat unworked while the agent reported a complete looking list. Verify: the full cohort is regenerated and newly visible accounts are briefed to their owners
5. Add count reconciliation to every list building run. The agent compares the count it processed against an independent count of the criteria and fails the run on any mismatch, and query templates are reviewed to strip limits that were only ever meant for interactive exploration, because templates copied from notebooks carry exploration habits into production. Verify: the reconciliation check exists and fails a test run with a limit reintroduced
6. Audit sibling queries and tools. Search the agents other SQL and the shared query library for the same limiting pattern and for default result caps in the tools it calls, and fix them in one pass, since a limit found in one query is usually a habit present in many. Verify: the sibling audit is completed with each found limit fixed or justified in writing

Why it happens

Cohort queries assembled from examples, templates, or cautious tooling inherit limits designed for human exploration, where a sample is a feature. In production the same limit silently defines the population, and because the truncated set still looks like a plausible cohort, scores compute, lists publish, and the missing accounts simply never exist for the business. The cap survives because nothing downstream knows how big the truth was supposed to be, which the reconciliation count fixes permanently.

Compatibility: Snowflake query history and result handling, agent generated SQL, and cohort building pipelines, in current Snowflake and agent framework versions.

Variants and edge cases

Snowflake query returned first 1000 rows LIMIT

['The direct phrasing. Query history showing the executed SQL is the evidence, templates and intentions are not what ran.']

at-risk cohort truncated round number rows

['The round number variant. Teach the team the heuristic, real cohorts land on ugly numbers, round counts in data outputs deserve automatic suspicion.']

agent cohort incomplete result limit Snowflake

['The framework variant. Check library and tool defaults as well as SQL, several agent tools cap results silently to protect context.']

Edge cases to work through before you close the incident:

• Pagination without a deterministic order is truncation in disguise. Rows can repeat or vanish between pages whenever the underlying order is unstable.
• Some limits protect the warehouse from runaway queries. Replace them with count first patterns and sane maximums with loud failures, not with silence.
• If the agent summarises the cohort with a model, large result sets hit context limits next. Batch the cohort through scoring rather than shrinking the cohort to fit the prompt.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_3ku9LunWNbiIcIdcSW5B-g