Engineering · · 4 min read
Your agent listed the first page. Did it finish the inventory?
Distinguish a sample, a complete inventory, and a time-bounded snapshot when tools return paginated data.
The agent returns a tidy list of company applications. A platform engineer notices one missing service and asks for it by name. The agent finds it immediately: the connection could read the service all along, and the inventory ended too early.
Pagination failures look like poor reasoning because the first page looks complete. A public LangChain loader change added pagination for GitHub issues, showing that completeness depends on connector behavior underneath an otherwise successful retrieval.
Define what "all" means before fetching#
An inventory needs a scope, a completion condition, and a time interpretation. "All applications" could mean active applications in one tenant, applications visible to the current identity, or every application a department owns. State which one.
Separate an enumeration from a snapshot. Completing a page sequence proves only that the client followed it to the end, not that every page represents one instant while the collection changes. If the provider offers snapshot semantics, use them. Otherwise attach the collection interval.
Microsoft Graph's paging documentation explains that clients follow @odata.nextLink until it is absent. Use the continuation URL as supplied, and do not make the model reconstruct a skip token from memory or infer completion from a short page.
Let code own the cursor#
The agent decides it needs a complete application inventory. A connector routine traverses the pages, preserves the original scope, deduplicates by stable identifier, and returns a result that states whether enumeration finished.
Code walks every page and reports the pages it could not reach.
Suppose the first page contains applications A through M and the next request times out after the server received it. The connector has thirteen useful entries and an unresolved continuation. It returns a partial result with a resumable checkpoint and never a completed inventory.
The checkpoint needs the scope and identity context as well as the cursor. Resuming with a different tenant or broader credential produces a blended list that no single principal was authorized to collect, and resuming after the continuation expires can require restarting the enumeration. Neither is an ordinary next page.
A result contract carries:
| Field | Why the buyer needs it |
|---|---|
| Requested scope | Defines which items belong |
| Collection interval | Shows when the inventory was observed |
| Unique item count | Avoids double-counting duplicates |
| Enumeration complete | Separates finished traversal from partial progress |
| Remaining continuation | Allows controlled recovery |
| Exclusions or errors | Identifies known gaps |
Test the uncomfortable pages#
Build a connector fixture where the first page is full, the second page repeats an item, and the final page is empty. Include a continuation on the empty page if the provider allows it. The traversal follows the continuation token and ignores item count.
Add a failure after a page has been received and before the checkpoint is saved. On restart, rereading that page must not duplicate its items. Stable identifiers make this manageable; names do not, because two applications can share a display name.
Set a page, elapsed-time, and response-size budget. An inventory that stops at the budget is still useful if the answer says it is partial, and the user decides whether to extend the collection or narrow the scope. Reporting a budget stop as "no more results" takes that decision away.
Keep summaries separate from enumeration#
Do not pass every raw object through the model to prove that code counted them. Store the complete artifact in a controlled location and give the agent the counts, selected fields, gaps, and references it needs to explain the result.
A sample can be a relevance-ranked page. A count of applications without an owner comes from the completed set, since a semantic search result is the wrong denominator.
The guide to result verification covers the broader distinction between a successful request and finished work. For inventories the decisive evidence is the final continuation exhausted, a stable scope, and known errors attached.
Put the tested traversal and completeness rules in the connector so every inventory consumer uses the same definition of finished. Use connection health to investigate access problems and action evidence to inspect the requests routed through Deixic. The next inventory reuses the tested traversal, and no model has to rediscover pagination from the first page.