Limits and exhaustive retrieval best practices

Agents execute multi-step workflows that may query, transform, and write data across many systems. Each execution is subject to guardrails that control cost, latency, and reliability. Understanding these limits helps you design agents that retrieve the data you need without running into truncation or budget constraints.

Tool-call budget

Each agent run has a maximum number of tool calls it can make. This budget covers every action the agent invokes — searches, reads, writes, and orchestration steps all count toward the same limit.

When an agent needs to paginate or iterate across many records, design the workflow so each step does meaningful work. For example, batch records by date range or status rather than fetching one record at a time.

tip

If your agent is running out of tool calls before it finishes, break the work into fewer, broader queries rather than many narrow ones.

Response payload size

Each action response is subject to a size cap. When a search or query returns many large records, the response may be truncated even though the underlying system has more matches.

Several actions — including Search Jira with JQL and Search Salesforce with SOQL — provide a downloadable result link so you can retrieve the full dataset outside of the in-chat response. Look for a download link in the intermediate step output when working with large result sets.

Use native datasource actions for large datasets

Agents have two broad ways to retrieve data: company search and native datasource actions. Choosing the right one depends on whether you need ranked relevance or exhaustive enumeration.

Company search

Use company search when you want:

• Ranked, permission-aware retrieval across one or more data sources.
• Relevance-ordered results based on the query.
• A broad sweep without needing every matching record.

Company search is ideal for questions like "find the most relevant Confluence pages about deployment procedures" or "show me recent Slack messages about the Q3 launch."

Native datasource actions

Use native datasource actions — such as Search Jira with JQL, Search Salesforce with SOQL, or Search Databricks with SQL — when you need:

• Exhaustive enumeration — for example, listing every open ticket in a project or every opportunity closing this quarter.
• Precise field-based filtering that the Glean index doesn't expose — for example, filtering by a custom Jira field or a Salesforce formula field.
• Aggregations or sorting that company search doesn't support — for example, counting tickets by priority or summing opportunity amounts by stage.

When to combine both

A common pattern is to use a native action for exhaustive enumeration, then pass the structured output to a respond step or an analyze data step for summarization. For example:

1. Use Search Jira with JQL to retrieve all P1 tickets from the past month.
2. Pass the results to an analyze data step to generate a summary table grouped by assignee.
3. Use a respond step to present the analysis to the user.

Choosing result counts for company search

Company search steps let you configure how many results to retrieve per search. Higher numbers broaden recall but use more of the agent's working memory and can degrade response quality when the model must reason over many conflicting or irrelevant results.

Start with a lower result count and increase it only when your agent's answers are missing relevant context. If you need every matching record rather than the top results, use a native datasource action instead.

Pagination and batching for large result sets

When a project, account, or ticket queue contains more records than a single action call can return, use field-based batching to retrieve results in manageable chunks:

• Time-based batching — split queries by date range. For example, query one month at a time using JQL like project = ABC AND created >= "2025-01-01" AND created < "2025-02-01".
• Field-based batching — split queries by a categorical field such as status, priority, or assignee.

Agents can iterate across batches using looping steps and aggregate the results into a spreadsheet output or a consolidated response. For a worked example using JQL, see Pagination and batching on the Search Jira with JQL page.