When should I use the fast profile?

Best move: reach for fast when you are triaging volume and can escalate the hits, not when you need the AI-readiness verdict.

Why it works: fast reads only the two deterministic layers, tech stack and infrastructure, so it returns in one to three seconds with no key and no model variance. You spend on depth only for the domains that earn it.

Key takeaways

• Fast returns two layers: tech stack and infrastructure. AI-readiness and firmographics belong to standard; security grade and Wayback history belong to deep.
• Fast is deterministic and keyless at roughly one to three seconds per domain, so the same domain returns the same dossier on every call.
• Fast is a static read. It does not render JavaScript, so client-only and proxied components stay hidden until you escalate.
• The pattern is triage-then-escalate: run fast across a list, promote the survivors to standard or deep.
• Fast gives you a coarse icp_signal from tech and infrastructure, but the AI-readiness verdict, the differentiator, needs standard.

What does the fast profile return?

Two deterministic layers, correlated in one call. The tech-stack layer lists frameworks, CMS, analytics, widgets, payments, and ecommerce, each detection carrying a category, version, confidence, how_detected, and evidence. The infrastructure layer resolves IP, ASN, hosting org, CDN, nameservers, MX records, email provider, and DNS TXT vendors, plus the email-auth booleans (SPF, DKIM, DMARC) and the TLS certificate (issuer, SANs, expiry, days_remaining).

At the top, fast fuses those into primary_stack and a coarse icp_signal you can filter on. What it leaves out is deliberate. Deep AI-stack fingerprinting and firmographics are standard. The security header grade (A to F) and Wayback first-seen history are deep. So fast tells you the shape of the stack and where it runs, not whether the company ships AI or who its contacts are.

That boundary is the point. Every field fast returns comes from a signal you can read without rendering a page, calling a model, or firing a follow-on probe. Determinism is what buys you the one-to-three-second latency and the keyless call. If a field would need inference or a second round trip, it lives in a heavier profile, and fast tells you it did not attempt it.

When should you escalate from fast to standard?

Escalate the moment the answer you need is not “what runs here” but “does this company ship AI, and who are they.” Fast reports the stack and the infrastructure. Standard adds the AI-readiness layer (model providers, AI SDKs, orchestration, vector stores, LLM observability, MCP endpoints, classified llms.txt) and the firmographics layer (company name, vertical, contacts, social profiles). Those are the fields that turn a raw stack read into a qualification decision.

A clean rule: filter with fast, qualify with standard. If you are cutting a list of ten thousand domains down to the few hundred worth a human look, fast is the right tool and standard would waste latency and quota on domains you will discard. Once a domain clears the filter, standard earns its cost, because the AI-readiness verdict (shipping, experimenting, none) and the contacts are what a rep or an agent acts on.

Go straight to standard when the list is already short and every domain matters, or when the icp_signal you want depends on the AI axis. A company can look cold on tech and infrastructure alone and read hot the moment standard surfaces an Anthropic SDK and a Pinecone client. Fast cannot see that, and it does not pretend to.

How does fast fit a bulk enrichment loop?

Fast is built for the wide top of the funnel. Point an agent at a list, call sniff_domain with the fast profile, and get a deterministic tech-plus-infrastructure dossier back in one to three seconds each, keyless and rate-limited. Because every call is stateless and read-only, the calls are self-contained and fan out in parallel. No call depends on the one before it, so there is no cursor to manage and no session to warm.

The loop has two stages. Stage one runs fast across the whole list and filters on cheap signals: a primary_stack that matches your ICP, a CDN or email provider that correlates with your segment, an expiring TLS certificate, a missing DMARC record. Stage two promotes the survivors to standard or deep, where you pay for AI-stack fingerprinting, firmographics, and (at deep) the security grade and Wayback first-seen date.

The economics follow from that split. You run the cheap deterministic pass over everything and the expensive layers over the few percent that clear the filter. Latency stays predictable because fast never renders or probes. And because fast is deterministic, you can cache its output by domain and re-run it later to diff, catching a re-platform or a new CDN without re-paying for the deep layers.

What does fast miss, and how do you know?

Fast is a static crawl with no JavaScript render and no follow-on probes, and it is honest about the blind spots that creates. Anything that only initializes in the browser, a chat widget mounted client-side, an analytics tag injected after load, a vector-store client that never touches server-rendered HTML, can stay invisible at this profile. Fully server-side or proxied components are the other gap: if a call happens backend-to-backend, a static read of the front end will not see it.

Two categories of field are absent by design, not by failure. Fast does not attempt the AI-stack layer or firmographics, so their absence in a fast dossier means “not measured here,” not “not present.” Reading a fast result as a null AI-readiness verdict is the mistake to avoid.

You know what fast missed because the dossier tells you. Each detection carries how_detected and evidence, so you can see whether a signal came from a header, a DNS record, or a static script tag. Where a static pass cannot reach a component, the result flags the gap rather than guessing. When those gaps sit on a domain you care about, that is your cue to escalate: standard renders when the signals call for it, and deep adds the follow-on probes.

Why does determinism matter for an agent?

An agent runs in a loop, and loops punish variance. Fast returns the same dossier for the same domain on every call because it reads fixed signals (HTTP responses, DNS records, the TLS certificate, static markup) with no model in the path. Three properties follow. Deterministic output is cacheable, so you can key on the domain and skip the re-fetch. It is diffable, so you can compare today against last month and detect a re-platform, a CDN switch, or a certificate about to lapse. And it is safe to re-run inside a retry or a fan-out without worrying that the answer drifted.

Determinism also keeps the cost model legible. Because fast never calls a model or fires a second probe, its latency and its quota consumption stay flat and predictable across the whole run. You can reason about a run of ten thousand fast calls in a way you cannot reason about ten thousand render-and-infer calls.

Standard and deep trade some of that determinism for depth, and that is the right trade once a domain matters. Fast is the layer you lean on when you need the same answer, cheaply, every time.

Bassethound perspective

A profile knob is not a paywall. Fast exists because most enrichment is triage, and triage should be deterministic and keyless. The competitors who sell tech-stack detection want you to think depth is the only axis worth paying for, so they meter the single layer they own. We think the first pass over a list should cost you nothing and return the same answer twice, and that the depth should kick in only for the domains that clear the filter.

Here is the conviction a tech-stack vendor would dispute: even the fast tier is fusion, not fan-out. Fast is two correlated layers in one call, tech stack and infrastructure resolved together, not a BuiltWith lookup you then stitch to a separate WHOIS pull and a separate DNS query. An agent cannot cheaply reconstruct that correlation from three keyless MCPs, and it cannot get it at all without keys from most of them. Keyless works here because we own the crawl. Fast is the proof that the cheap, deterministic floor can still be one coherent dossier, and that the honest move is to tell you exactly what it did not reach.

Sources

• MDN Web Docs, HTTP headers: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers
• Mozilla SSL Configuration Generator: https://ssl-config.mozilla.org
• IETF RFC 7489 (DMARC): https://datatracker.ietf.org/doc/html/rfc7489
• Model Context Protocol: https://modelcontextprotocol.io