10M, 15M, 30M, 40M+. Which tier resolves your agent's actual traffic?

Domain count is not the same as traffic coverage

Internet traffic, including agent navigation traffic, is heavily concentrated. A relatively small number of domains accounts for a large share of all requests, and the tail of rarely visited domains is extremely long. This is why coverage does not scale linearly with domain count.

The practical consequence is that the jump from 10M to 15M domains closes a meaningfully larger coverage gap, for most workloads, than the jump from 30M to 40M+ does in absolute traffic terms — because the additional 5M domains at the low end are still reasonably well-linked and commonly encountered, while the additional domains beyond 30M are increasingly obscure, low-traffic, or narrowly regional. This is not a reason to under-buy; it is a reason to size the tier to your workload's actual domain diversity rather than assuming bigger is proportionally better for every use case.

It helps to think of the four tiers as four points along a curve of diminishing marginal coverage per additional million domains, rather than as four equal-sized slices of the internet. Early tiers pick up the domains an agent is statistically most likely to visit: major SaaS vendors, well-known e-commerce platforms, established media and documentation sites. Later tiers pick up domains that are individually far less likely to be visited by any given agent, but collectively still matter for workloads with genuinely broad or unpredictable discovery patterns. Neither end of the curve is "wrong" to buy; the right point on it depends entirely on where your own workload sits.

Sizing a procurement-research agent's tier

A composite, illustrative scenario, not a specific customer, showing the method in practice.

The same method applied to a broader discovery workload, such as the ones described on manual curation vs. the database, would more often land on the 30M tier instead, because open-ended vendor discovery reaches further into the long tail than a scoped procurement category does.

Notice what the worked example does not do: it does not start from "how much can we afford" or "what does the biggest competitor buy." It starts from the agent's actual job, moves to the domain set that job realistically touches, and only then asks which tier resolves that domain set at an acceptable rate. Sizing decisions made in the opposite order — picking a tier first and hoping the workload fits it — are exactly how teams end up either overpaying for breadth they never use or under-provisioning coverage for a workload that quietly outgrew its original scope.

Buying the largest tier "just in case"

The instinct to buy 40M+ coverage regardless of workload is understandable but usually not the efficient choice, for two concrete reasons.

First, cost scales with tier, and the 40M+ tier is priced custom specifically because it is aimed at OEM and redistribution use cases with a fundamentally different economics than a single agent deployment. Paying for that breadth when a 10M or 15M tier would resolve the overwhelming majority of a scoped workload's actual traffic is not caution; it is an unnecessary line item that a traffic-log-based sizing exercise, like the worked example above, would have avoided. The same reasoning applies in reverse: a team that genuinely needs OEM-scale breadth but under-buys to save on the sticker price ends up paying for a partial re-license later once the gap becomes obvious in production, which usually costs more than sizing correctly the first time.

Second, larger is not automatically safer in a way that changes the security posture. The layers described on agent guardrails — the host list, the egress rules, and default-deny — already cover domains outside whatever tier is licensed. A domain the database has not classified falls to default-deny rather than being silently allowed, so under-provisioning the tier does not create a silent security gap the way an incomplete hand-list does; it simply means slightly more domains fall to the pattern-based egress rules or default-deny instead of a direct page-type lookup. Sizing the tier correctly is a cost-efficiency decision layered on top of a security posture that holds regardless of tier.

There is a related mistake worth naming separately: assuming that a larger tier substitutes for the other three enforcement layers rather than sitting alongside them. Even at the 40M+ tier, approaching 99.99% of active internet traffic, the database only ever answers "what page type is this URL," never "should this specific agent, for this specific task, be allowed here right now." That second question is what egress rules, host-list denial, and default-deny exist to answer for cases the page-type data alone cannot resolve, and no coverage tier changes that division of responsibility.

A useful gut check before signing off on a tier: pull a week of actual outbound agent traffic, or a representative sample if a week is not available yet, and check what fraction of distinct domains would have resolved against the 10M tier alone. Teams are often surprised in both directions — a narrowly scoped internal research agent frequently clears 99% on the smallest tier, while a broad web-shopping agent touching long-tail merchant sites can need the 30M tier just to keep default-deny fallbacks to a manageable minority of requests. Run that check before the purchase, not after the first production incident report.