Context engineering and silent truncation

An agent can reason correctly and still produce the wrong answer because the relevant evidence never entered its context. The failure often begins before inference: a search tool, parser, database wrapper or orchestration layer returns only the first set of matches. The model sees a coherent result and treats it as complete.

That makes a cap unusually difficult to diagnose. The final answer may omit a late-defined covenant exception, a guarantor appearing near the end of an entity list or an amendment that ranks below earlier search results. Reviewers blame retrieval quality or model discipline. The actual defect is simpler: the interface removed evidence without giving the agent a reliable way to discover or recover it.

What is silent truncation?

Silent truncation occurs when a tool has more responsive data than it returns, but its response does not communicate that fact. The agent receives twenty matches and has no way to distinguish between “exactly twenty exist” and “the system stopped after twenty.”

This can happen at several layers:

• A document search endpoint limits matching passages.
• A PDF extraction service caps pages, characters or table rows.
• A database connector returns a default page size.
• An orchestration framework shortens large tool responses before inserting them into the model context.
• A model-facing adapter drops fields or list items to meet its own token budget.
• A logging system stores less than the agent originally received, concealing the event during review.

The cap need not be small. A limit of 100 results is still material if the responsive universe contains 104 and the decisive item is last. The problem is not the number itself. It is the mismatch between the tool’s bounded output and the agent’s belief about completeness.

Credit-document work is particularly sensitive to this mismatch because enumeration frequently matters. A professional may ask for every unrestricted subsidiary designation, every debt basket referenced by an incremental facility, or all transfers involving specified collateral. Missing one item can change the conclusion even when every returned item was extracted correctly.

Why is an announced cap still unsafe?

A tool that says “showing the first 50 results” is better than a silent tool, but it is not a complete design. It has announced the loss without providing a means to reverse it.

The positional bias remains. Items that enumerate early are available for analysis. Items that enumerate late are excluded. Ordering may reflect page location, database insertion order, search relevance or an implementation detail. None of those is necessarily aligned with legal or analytical importance.

Consider a tool response shaped like this:

{
  "message": "Showing the first 50 matches",
  "results": [ ... ]
}

The agent now knows that it may have an incomplete set. But what action can it take? Asking the same question may produce the same 50 results. Narrowing the query may help, but it forces the model to invent partitions without knowing the omitted population. It may search separately for “restricted payments,” “investments” and “dividends,” yet still miss an exception described using different language.

The announced cap therefore converts an invisible failure into a visible but unresolved one. It may improve the wording of the agent’s caveat. It does not make the underlying analysis complete.

The distinction matters in evaluations. A grader may penalise the agent for failing to identify an item that the tool never made reachable. Prompt changes will not fix that failure. Neither will instructions to “be exhaustive.”

What does progressive disclosure require?

Progressive disclosure gives the agent a bounded result while preserving a route to the complete responsive set. A useful response contains four elements:

1. Results: the current bounded page.
2. Total: the number of responsive items, or a clearly labelled estimate if an exact count is unavailable.
3. Completeness: an explicit statement of whether the response contains the entire result set.
4. Cursor: an opaque continuation value when additional results remain.

For example:

{
  "results": [ ... ],
  "returned": 50,
  "total": 137,
  "complete": false,
  "next_cursor": "opaque-continuation-token"
}

The agent does not need all 137 items in one context window. It needs to know that 137 exist and to control how the remaining items are retrieved. It can request the next page, aggregate selected fields, or delegate page-level review while maintaining an auditable count.

A cursor is preferable to asking the model to construct offsets. It can preserve the query, filters, permissions and ordering state. The cursor should be opaque to discourage the agent from editing it and should expire predictably rather than failing without explanation.

Stable ordering is equally important. If the underlying result set changes between calls, offset pagination can skip or duplicate items. A cursor tied to a snapshot, document version or deterministic sort key reduces that risk. The response should identify the source version when later reproducibility matters.

How should an agent consume paginated results?

Pagination alone does not guarantee completeness. The orchestration policy must recognise and act on the response contract.

For exhaustive tasks, the default loop is straightforward:

request first page
record total and source version
process returned items
while complete is false:
    request next_cursor
    process returned items
verify processed count against total

The agent should not concatenate every raw page indefinitely. That merely transfers the cap from the tool into the model’s context window. Instead, it can maintain a structured ledger containing identifiers, document locations, classifications and short evidence extracts. Detailed text can be fetched again when a conclusion requires it.

The right stopping rule depends on the task. “Find an example of an asset-sale exception” may stop after one well-supported result. “List every exception that permits value leakage” requires continuation until the completeness flag is true, followed by reconciliation against the total.

This distinction should be part of the task specification, not improvised after retrieval begins. Tools can help by accepting an intent such as mode: exhaustive or mode: first_sufficient, but the completeness metadata remains necessary in both modes.

Errors also need explicit treatment. If page four fails, the orchestration layer should retain the last confirmed cursor and report that the set is incomplete. Returning the first three pages as though the loop completed recreates silent truncation at a higher layer.

Why does aggressive compression reveal a cap?

One of the strongest diagnostic signals is an agent repeatedly compressing its own data. It shortens extracts, replaces names with codes, groups items into increasingly broad categories or asks the tool for narrower slices. This behaviour is often described as poor planning. It may instead be rational adaptation to a binding limit.

The limit could be a context window, maximum tool-response size, message-length ceiling or orchestration budget. The agent is attempting to preserve coverage by reducing representation cost. If the system gives it no total and no cursor, compression becomes its only available control.

Transcript review should therefore examine the sequence before the wrong answer. Look for:

• Repeated calls that return exactly the same number of items.
• Requests to “summarise more tightly” before all records have been enumerated.
• Query splitting that appears only after a large response.
• Lists that end at round boundaries such as 20, 50 or 100.
• Tool messages that disclose a limit without offering continuation.
• Count discrepancies between tool logs, intermediate state and the final answer.

These are system-level clues. They should not automatically be scored as model errors.

How should cap binding be measured?

A stated limit tells you capacity. It does not tell you how often the limit affects real work. The useful measure is the cap-binding rate: how frequently responsive results exceed the amount returned.

Instrument each call with the number returned, the total available, the completeness flag, the cursor state and the task identifier. Then analyse binding by tool, query type, document class and workflow stage. A cap may rarely bind overall yet bind routinely on covenant enumeration or cross-document searches.

Also measure continuation behaviour. When a cap binds, does the agent request another page? Does it stop for a valid task-specific reason? Does it lose the cursor? Does a downstream summariser truncate the combined results after retrieval succeeded?

Sample transcripts should include cases just below, exactly at and just above the limit. Exact-boundary cases deserve special attention because a response containing 50 items under a 50-item cap may be complete or truncated. Without a total or completeness flag, the agent cannot tell which.

The evaluation set should score evidence availability separately from reasoning quality. If the gold answer depends on an item beyond an unreachable cap, the harness is testing the interface failure and attributing it to the model.

What should teams change first?

Start with the response contract. Every tool capable of returning a variable-length collection should expose whether the collection is complete. If it is not complete, provide a continuation path.

Then trace the entire route into the model. A well-designed search API can still be undermined by middleware that shortens JSON, a framework that clips tool messages or a prompt builder that keeps only the first records. Completeness metadata must survive every layer.

Finally, review actual transcripts rather than treating configured caps as harmless. An announced cap still binds. The practical question is whether the agent can observe that binding, retrieve what was omitted and reconcile the completed set.

For credit analysis systems, this is foundational context engineering. The objective is not to place every page and every match into one prompt. It is to preserve the agent’s knowledge of what exists, what it has seen and what remains available. This is the principle CreditGPT is designed around where document analysis requires bounded retrieval: partial results should remain identifiable as partial, with a controlled path to the remaining evidence.