> ## Documentation Index > Fetch the complete documentation index at: https://docs.stackone.com/llms.txt > Use this file to discover all available pages before exploring further. # Deep Query > Search, filter, and aggregate synced records without calling the provider API. Deep Query searches, filters, and aggregates the records [Data Sync](/optimize/data-sync) has stored, without calling the provider. Because it runs against StackOne's index rather than a third-party API, it's faster, consumes none of the provider's rate limit, and answers questions most provider APIs can't express at all. Deep Query covers any action that has a sync. Turn sync on for the action first, then everything below applies to it. ## Why query instead of calling the provider | | Live action call | Deep Query | | -------------------- | ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | Where it reads from | The provider, on every call | StackOne's index | | Provider rate limits | Every call counts against them | No provider request, so nothing counts | | Filtering | Only the query parameters that provider happens to expose | `term`, `terms`, `range`, `wildcard`, `match`, `match_phrase`, `exists`, and `bool` over any synced field | | Full-text search | Rarely offered | Free-text across every text field, ranked by relevance | | Aggregation | Not offered. Page through every record and count in your own code | One `aggs` query returns the numbers | | Field selection | Whatever the provider chooses to return | `source` returns only the fields you name | A query is billed like an action call. Listing queryable fields is not. ### Smaller responses, fewer tokens The last two rows are where an agent gains the most. Asking for three fields instead of forty shrinks the response the model has to read by the same proportion. Asking for a headcount by department returns a dozen numbers from one aggregation, where a live call means paging through every employee record and tallying them inside the context window. Deep Query and [Advanced Tool Search](/optimize/advanced-tool-search) work on the same budget from opposite ends: one shrinks what tool responses cost, the other shrinks what tool definitions cost. ## Query from an agent Once a sync has records, each synced action gains a companion tool named `{action}_s1query` - `bamboohr_list_employees_s1query` alongside `bamboohr_list_employees`. A `list_s1query_queryable_fields` tool tells the agent which fields it can filter and sort on. Both tools stay available, so the agent chooses: the Deep Query tool to search or aggregate across everything cheaply, the live tool when it needs the provider's current state. Records come back in the provider's own shape, with the provider's field names and nesting, not the normalized shape a regular action call returns. ## Try a query without code Open **Actions Request Tester** from the account page and pick the `(S1Query)` entry for the action. ## When to use it Use Deep Query when the same data is read repeatedly and tolerates being minutes to hours old, or when an agent needs to search or aggregate across the whole record set rather than page through it. For data that has to reflect the provider right now, call the [action](/gateway/concepts/actions) directly - both tools stay available to the agent. To be told when something changes rather than querying for it, use [webhook events](/connect/webhooks). Turn on the sync that Deep Query reads from, and set how often it refreshes. For developers querying the index from their own backend, with filters and aggregations.