Did your agent check the whole table—or just the first page?
Make scope, cursor completion, and current field values inspectable before accepting a table-wide conclusion.
An agent can deliver a convincing account review using entirely real records and still miss most of the table. The first response contains enough material to summarize; nothing in a fluent summary proves the remaining pages were read.
A complete read needs a defined scope, an explicit stopping condition, and evidence another person can inspect. In Busabase, that means choosing the Base and record lifecycle, following the returned cursor to its end, and reading business values from the current record payload.
Define the population before counting it
Records belong to a Base. Pass baseId explicitly: omitting it lists across the Space. Choose active records or archived records deliberately. A review of current customer data and a review of the trash are different populations.
Record the filters, required fields, start time, and archive policy with the task. A conclusion about one selected status should name that status, rather than claiming coverage of all business records.
Structural illustration · designed workflow
Follow the server's stopping condition
The live OpenAPI caps records.list limit at 100. Its response contains records and nextCursor. Pass each returned cursor unchanged into the next request, until nextCursor is null. Do not decode it or substitute a short page for the explicit completion condition.
Keep a page ledger with row counts, read times, and whether another page remains. Check record IDs for duplicates. If a request fails, preserve the completed pages and next cursor; resume the same scope. An unread page makes the result partial, even when the agent has enough examples to write a report.
Read the current business fields
Current field values live in records[].headCommit.payload, keyed by field slug. The surrounding Base, creator, and commit objects are metadata. An absent slug is an empty field; another object with a similar name is not a substitute.
summary=true replaces values larger than 4 KB with omission markers. Use it to locate records, then fetch the full selected record with records.get before judging long text. Keep headCommitId so a later reader can identify the version inspected.
Structural illustration · designed workflow
Check filter and sorting semantics
records.list filters return a best-effort superset. Narrow those results again on the client; do not assume a limited response contains only exact matches. For supported exact comparisons, use valueFilters with a Base. Unsupported comparisons should be handled as errors rather than silently broadened searches.
Authoritative field sorting is limited to number and date fields. Do not infer a reliable priority or alphabetical order from another field type. Consult the contract for the particular endpoint being used: a grid view and a list request need not apply identical semantics.
Ask for evidence of coverage
Give the connected agent an instruction such as:
Read active records from this Base only. Follow unchanged cursors until nextCursor is null. Keep page counts, record IDs, and headCommitIds. Read values from headCommit.payload and fetch omitted long fields separately. Report duplicate IDs, empty fields, failed pages, and start/end times. Call an unfinished read partial.
The deliverable should state scope, pages, returned rows, unique IDs, failures, and completion evidence. A count is a useful cross-check. It does not establish that requests made while other people edit the table all describe one instant: cursor traversal alone is not a snapshot-isolation guarantee. Reread consequential records before proposing a decision based on them.
Structural illustration · designed workflow
Keep coverage separate from permission
Reading every page does not authorize a bulk edit or an external action. Assess proposed changes against the inspected evidence and submit only the authorized changes through ChangeRequests.
Start with one real question and an explicitly scoped Base using the REST API guide. Save the coverage ledger with the conclusion. A successor should be able to distinguish what was checked, what remained unread, and what changed afterwards.