> ## Documentation Index > Fetch the complete documentation index at: https://docs.brightdata.com/llms.txt > Use this file to discover all available pages before exploring further. # Business Search for AI agents > Wire Business Search into an agent. Route structured input to Ludicrous, free text to Instant or Smart, and name all 3 modes in the schema. Expose Business Search to an agent as one tool per category, with the mode chosen from the shape of the agent's input. ## Which mode should an agent use? * Use `ludicrous` when the agent can construct valid field conditions, for example when an upstream step has already parsed a form or a database row. * Use `instant` when the input is a natural-language description and the agent will filter a broad candidate set itself. * Use `smart` when the input is a natural-language description and the agent needs a short, ranked list it can use without further filtering. Keep the category, source and field names explicit in your Business Search tool schema. An agent that guesses a field name sends rejected requests. See [Business Search query syntax](/products/business-search/query-syntax) for the field names each category accepts. ## How should an agent run a discovery loop? Search broadly, filter with the context the agent holds and enrich only the records it keeps. This loop spends the most on the few records that matter: 1. Search in Ludicrous or Instant with a `summary` view or a short field list. 2. Filter the candidates against the context Business Search cannot see, such as the user's exclusion list or records already in the CRM. 3. Refine the query and search again when the set is off target. Each refinement is a new billable search, so keep `limit` at a block boundary. See [Business Search pricing](/products/business-search/pricing). 4. Enrich only the shortlisted records, for example with [Scraper API](/products/scrapers/overview). Use Smart in place of steps 1 and 2 when the user's description alone defines a good result. When the request mixes people and company conditions, such as CEOs of funded companies, run a company search first and a people search second. See [How to run a multi-step search](/products/business-search/examples#how-to-run-a-multi-step-search). ## How should a Business Search tool schema be shaped? Give the model one tool per endpoint rather than one tool with a category switch, and enumerate the values it must choose between: * `mode` as an enum of `ludicrous`, `instant` and `smart` * `source` with the default named in the description, `linkedin_company` or `linkedin_people` * `view` as an explicit field list, so the agent never falls back to `id_only` by accident * `limit` capped at a value your context budget can absorb ## What should the agent do with the results? Four rules keep a multi-step agent honest: * Store record identifiers with their source. `bright_id` is unique within a source, not across sources. * Request only the fields the next step needs. A `full` view spends context on fields no downstream step reads. * Preserve the order of `documents`. Business Search returns no score field. When the agent applies its own ranking, base it on its own signals, such as CRM matches or the user's criteria. * Review relevance before using a returned record for a consequential action such as sending an email or writing to a CRM. ## How should the agent distinguish failure states? Distinguish execution errors, empty results, missing field values and incomplete coverage in downstream logic. They call for different behavior: | State | Signal | Agent behavior | | - | - | - | | Execution error | Non-200 status | Fix the request or stop. Do not retry an HTTP 400 | | Empty result | HTTP 200, `documents` is empty | Report no matches. Do not report that the entity does not exist | | Missing field | Field absent from a returned record | Continue with the record. Do not treat absence as a negative fact | | Partial coverage | `meta.coverage_percent` below 100 | Say the result set is partial when reporting to the user | An agent that collapses these four into one retry branch will loop on unfixable errors and will state absences as facts. Bright Data MCP exposes Bright Data products to agents over the Model Context Protocol. See [Bright Data MCP](/products/mcp-server/overview) for the tools available today.