Which profile should I use for bulk enrichment?

Best move: run fast across the entire list to triage, then standard on the ICP subset, and save deep for the finalists.

Why it works: most domains in a raw list are not your ICP. Fast is deterministic and keyless, so you segment the whole list cheaply and spend the expensive profiles only where the fast pass flagged a fit.

Key takeaways

• Fast is the bulk default: deterministic, keyless, one to three seconds per call, returning tech stack and infrastructure, no AI stack or firmographics.
• Standard adds the deep AI-stack fingerprint and firmographics. That is the reason to reach past fast, because it produces the ai_readiness score and verdict.
• Deep adds follow-on probes, the security header grade (A to F), and Wayback first-seen history. Reserve it for finalists.
• The winning pattern is a funnel: fast across the whole list, standard on the ICP subset, deep on the finalists.
• Every call is stateless and self-contained, so you own caching and can parallelize. The free tier has a daily limit, and paid plans are the path to volume.

What does each profile cost you in time and depth?

Fast is the deterministic tier. It resolves DNS, reads the served HTML, and checks the TLS certificate, then returns the tech stack and the infrastructure layer. Latency is one to three seconds, and you need no key. It does not run the AI-stack fingerprint or pull firmographics, so you get primary_stack and infrastructure, not the ai_readiness verdict.

Standard is the default. It keeps everything fast returns and adds the two layers that take real work: the deep AI-stack fingerprint (model providers, SDKs, orchestration, vector stores, observability, MCP endpoints) and firmographics (company, vertical, contacts, social profiles). This is the tier that produces the ai_readiness score and verdict.

Deep is the finalist tier. On top of standard it runs follow-on probes, grades the security headers A to F, and pulls the Wayback first-seen date so you can see how long the stack has been live. It is the slowest and the most thorough.

Read the three as a cost curve. Fast is cheap and shallow, standard sits in the middle, and deep buys completeness at the cost of speed. Match the profile to how far down the funnel a domain already sits, and you never pay for depth you were going to discard.

When is fast enough on its own?

Fast covers any job the deterministic layers can answer: deduping and normalizing a domain list, segmenting by CDN or hosting org or ASN, targeting by CMS or ecommerce platform, flagging TLS certificates about to expire across a portfolio, or dropping parked domains and dead infrastructure before a heavier profile touches them. Tech stack plus infrastructure is the whole answer for these, and fast returns it keyless in one to three seconds.

Fast is also the right call when volume is the constraint. Every call is self-contained and deterministic, so you parallelize the batch and cache each result without drift between runs. Re-run the same domain on fast and you get the same dossier.

Fast will not tell you whether the company ships AI. The AI-stack fingerprint lives in standard, and the security grade lives in deep. If your scoring model leans on the ai_readiness verdict (the signal that separates Bassethound from a tech-stack lookup), fast is the triage pass, not the final answer. Use it to cut the list down, then let standard do the qualifying work on what survives.

When do you need to step up to standard or deep?

Step up to standard the moment your enrichment depends on the AI-readiness signal. That is the reason to reach for Bassethound over a BuiltWith-style lookup. Standard runs the backend fingerprint (model providers, AI SDKs, orchestration frameworks, vector stores, LLM observability, MCP endpoints, .well-known AI files) and returns the ai_readiness score out of six with a verdict of shipping, experimenting, or none. It also adds firmographics, so the company, vertical, and contacts land in the same dossier. If you are scoring inbound leads or building an AI-adoption segment, standard is your default, not fast.

Step up to deep only for finalists. Deep adds follow-on probes, the security header grade (A to F across HSTS, CSP, X-Content-Type-Options, and the rest), and the Wayback first-seen history that tells you how long a stack has been live. That last one separates a company that shipped AI last week from one running it in production for a year. Deep is the slowest tier, so you do not run it across thousands of domains. You run it on the short list standard already qualified, where the extra depth changes a decision you are about to make.

How do you structure a two-pass enrichment funnel?

Treat enrichment as a funnel, not one heavy pass over the whole list.

Pass one: run fast on every domain. You get tech stack and infrastructure for each, keyless, in one to three seconds. Use it to drop parked domains, dedup, and segment by infrastructure and stack. Keep the icp_signal and primary_stack from the summary as your first filter.

Pass two: run standard on the domains that survived. This is where the ai_readiness verdict and firmographics come in, and where most of your scoring value sits. You already cut the list, so you spend the heavier profile on a fraction of the original volume.

Pass three (optional): run deep on the finalists. Security grade and Wayback history sharpen the last decision, and the set is small enough that latency does not matter.

The funnel works because most domains in a raw list are not your ICP, and the fast pass is cheap enough to touch all of them. You spend depth where the earlier pass found a fit. One heavy pass over the full list wastes the expensive layers on domains you were going to discard. Nothing carries between calls, so you own the intermediate results and decide what to re-enrich.

How do you stay inside the rate limits at volume?

The free tier has a daily limit. It suits interactive use and light batches, not a ten-thousand-domain run. Push it too hard and you get HTTP 429 responses (Too Many Requests, RFC 6585). Two things keep you inside the envelope.

First, keep calls on the lightest profile the job allows. Fast does less work per call than standard or deep, so more of your budget goes to throughput. Reserve the heavier profiles for the smaller subsets the funnel hands you.

Second, move to the paid tier for real volume. The paid tier authenticates over OAuth and raises both depth and volume limits. Because Bassethound owns the crawl, you never bring your own key for any upstream provider. One OAuth token covers the whole five-layer dossier, so you are not juggling a BuiltWith key, a WhoisXML key, and an Apollo key across five vendors.

Statelessness helps here too. Every call is self-contained, so you parallelize across workers and back off per 429 without coordinating shared state. Cache each dossier on your side, keyed by domain and profile. Re-run only when the underlying site changes, not on every batch.

Bassethound perspective

Pick the profile, not the vendor stack. The reason to size profiles at all is that one call returns five correlated layers, so stepping from fast to standard buys you the AI-stack fingerprint joined to the same infrastructure and firmographics you already have. Fan-out cannot give you that cheaply. Run BuiltWith for tech, WhoisXML for infra, and Apollo for firmographics across a bulk list and you pay three keys, reconcile three schemas, and still miss the correlation, which is where the lead score lives. An agent cannot join five separate MCPs at bulk scale without paying for the join in latency and glue code. Keyless matters for the same reason. Because we own the crawl, the free tier needs no upstream key, and the paid tier is one OAuth token for the whole dossier, not five. Be honest about the limit: a static crawl plus optional JS render can miss fully server-side or proxied components, and the dossier tells you where it could not reach. That is a smaller gap than running five shallow tools and hoping they line up.

Sources

• Model Context Protocol documentation: https://modelcontextprotocol.io
• MDN, HTTP 429 Too Many Requests: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429
• RFC 6585, Additional HTTP Status Codes: https://datatracker.ietf.org/doc/html/rfc6585
• llms.txt specification: https://llmstxt.org