The Rise of CaaS: Context-as-a-Service for Agentic AI

What changes when an agent needs information from the web so it can continue working? Collecting a page is only the beginning. The information must support a conclusion, a decision, or another action.

Omer Primor approaches that problem from Bright Data, where he introduces himself as the leader of product marketing. He reports that Bright Data serves more than 20,000 teams, including more than 70% of the world's biggest AI labs. He also cites well over 50 billion pages or HTML documents daily and more than 20 petabytes of video, audio, and other media, without assigning a time period to the media figure. Those claims establish the commercial vantage point behind the discussion: infrastructure for collecting web data at scale.

Over his three years at Bright Data, Primor watched web access become part of Claude and ChatGPT, after being absent from their earlier versions. That connection changes the purpose of retrieval. A human might search, read, and carry on; an agent needs to incorporate the result into an ongoing workflow. Web data becomes context when it helps the next step happen. The objective is no longer simply to extract information, but to make that information usable for reasoning and downstream applications.

That context has a shelf life. The web is messy, unstructured, and continually changing. Primor describes an internal Bright Data analysis in which social-media content loses relevance in far less than a day, while collected news, finance, and retail data is mostly no longer relevant after 30 days. Here, decay means loss of relevance to the work, not deletion of the page. The practical consequence is continuous collection: a snapshot, or even a monthly refresh, may not keep an agent adequately informed.

Primor traces the transition from Google's roughly two decades of dominance in human search to the changes of the preceding three years. First, search appeared inside chatbots. Then API access let software agents use those capabilities too, directing search intent through channels other than a browser's search box. Exa, Parallel, You.com, and Tavily represent the next step in his account: search products designed around agents as consumers of web information.

Large platform companies are entering the same space. Primor describes Amazon's AgentCore Web Search Tool, backed by its own index, as an announcement from the preceding week. He places Microsoft's Web IQ announcement two weeks before that, describing it as a repackaging of Microsoft's search capabilities for agent development and orchestration. His estimate of Microsoft's earlier search share is 1–2%. These are his recollections of the market's timing and scale; the engineering change is the availability of web retrieval as part of an agent platform.

Search can find the price of a particular pair of sneakers on a particular website this morning. Reconstructing how that price changed over six months, including discounts, is a different job. Likewise, finding Bright Data's current vacancies does not directly produce a history of its openings or headcount. The information existed on the web at earlier points, but a current search does not automatically preserve and organize it into a timeline.

Context-as-a-Service, or CaaS, packages that additional work for agents. An agent connects through MCP, a CLI, or an API and retrieves information it can reason over. The pattern applies across e-commerce, travel, finance, market research, HR, and real estate.

The processing extends beyond discovering pages:

1. Discover, crawl, access, extract, and index relevant web content.
2. Structure the extracted information into entities and relationships in a knowledge graph.
3. Deduplicate entities and enrich them from multiple sources.
4. Expose the combined information for the agent's knowledge work.

This makes a CaaS provider resemble a vertical search engine: its advantage comes from understanding a particular domain deeply enough to organize its information before the agent asks.

The supplier landscape includes finance and market-research services, retail and e-commerce services, and GTM and sales-intelligence products. Primor identifies the companies displayed in this part of the talk as participants in Bright Data's startup program, alongside an offer of up to $20,000 in credits and co-marketing support.

Existing data vendors are adapting too. He presents ZoomInfo's GTM.AI as a secondary brand built for agent-driven work: prospecting, headhunting, and people research from Claude Code, Codex, or another agent. CaaS is therefore an evolution of Data-as-a-Service, but with a different consumer. The product must fit an agent's work process, not merely provide a database that a person can browse.

Once both search and CaaS are available, the design question becomes task-specific. Different teams need different kinds of context, and a combination of services may fit better than giving every agent the same search tool. Primor calls this web context engineering: choosing a retrieval path for a task, or a recurring family of tasks, while considering cost and usefulness together.

To explore that choice, his team built a company-enrichment test covering 25 fields, from name, domain, and headquarters to harder hiring and people information. Primor names Claude Opus 4.8 as the model in the agent harness. A nested loop worked through the fields, searched or retrieved from CaaS, and repeated the process until completion or a guardrail such as the budget intervened. He says the test ran 100 times on the event's sponsors.

This was an exploratory test, not a controlled benchmark. The run description does not specify the full company-by-provider design, field-correctness scoring, or budget settings, so its results are useful for understanding trade-offs rather than selecting a universal winner.

Coverage initially looked similar across the search configurations and one major CaaS provider. The chart includes labels for Unlocker and SERP; Primor explains SERP as using Google and Native as Claude's own search. Two other CaaS providers lagged.

The explanation is a boundary on what each route can know:

If a provider has not collected recent hiring information, asking again cannot make that field appear. Conversely, it may contain useful fields this test never requested. Coverage belongs to a workload, not to a provider in the abstract.

The cost comparison exposed a different distinction. Primor reports that most search, CaaS, and Google configurations clustered at similar total costs for the requested output. Their cost composition differed: CaaS spending was described as the service charge, while search also consumed model tokens to structure retrieved information into usable records.

Claude's native search and an unnamed premium CaaS provider were expensive outliers in the test. CaaS number two was cheap but also among the lower-coverage options. Primor interprets that combination as a possible niche for smaller shops with lighter information needs; the test itself establishes the cost-and-coverage combination, not that market explanation.

The displayed costs were per record, not totals for all 100 runs. That changes how to think about a million records or queries. A million does not mean fitting all the records into one context window. It can mean revisiting the same companies repeatedly: a market researcher or private-equity team checks for news, arrivals, departures, and new hiring as time passes. The workload grows with both the number of entities and the frequency of investigation.

In the paid-retrieval model Primor describes, another query incurs another charge even when the answer has not changed. Search also retains a volume-dependent token cost for processing results. The recurring bill therefore reflects attempts to learn whether something changed, not just the discovery of genuinely new information.

That pressure can change the work itself. Daily checks become weekly or monthly checks. Teams skip questions or request only 10 or 20 results. The system has the capability to do the research, but its users ration that capability to control spending. Primor calls this renting context: paying repeatedly to obtain information without building a reusable context asset under the team's control.

The alternative is to collect the data and retain it. Primor initially poses this as putting web data into a vector database, but the concrete experiment he describes is a direct-source enrichment pipeline; he does not establish which storage system it used. His engineer spent roughly a day on the experiment, enough to investigate a narrow task rather than build a complete production operation.

The pipeline begins with only a company name:

1. Use Google to discover the company's relevant URLs on information-bearing sites.
2. Once the sources are known, collect from those sources directly.
3. Use Bright Data's pay-as-you-go scrapers for LinkedIn companies, LinkedIn jobs, and Crunchbase, alongside two dedicated scrapers.

Search is useful at the discovery stage because the agent does not yet know the URLs. For repeated company enrichment, however, the source families become predictable. Going directly to them avoids rediscovering the same information through a general search workflow each time.

The dedicated scrapers were built with Scraper Studio. Primor describes AI-assisted scraper creation in under five minutes and self-healing when a website changes. Creation and repair are separate from running an already-built scraper; current self-healing workflows can require an explicit trigger, so this is not a guarantee of unattended recovery from every site change.

After collection, basic heuristics merge source records into one company entity. Conflicts are resolved through precedence rules: choose one source's value over another's. That removes the need to ask a model to interpret every conflict when the intended rule is already known.

For example, a fixed precedence rule can fill missing fields from a secondary source while preserving the preferred source's values:

type Company = {
  name: string;
  domain: string | null;
  headquarters: string | null;
};

function mergeCompany(
  preferred: Company,
  secondary: Company,
): Company {
  return {
    name: preferred.name,
    domain: preferred.domain ?? secondary.domain,
    headquarters:
      preferred.headquarters ?? secondary.headquarters,
  };
}

// Both records have already been matched to the same company.
const preferred: Company = {
  name: "Example Company",
  domain: "example.com",
  headquarters: null,
};

const secondary: Company = {
  name: "Example Company",
  domain: "example.org",
  headquarters: "London",
};

const company = mergeCompany(preferred, secondary);
// { name: "Example Company", domain: "example.com",
//   headquarters: "London" }

The rule preserves example.com despite a conflicting domain and fills headquarters from the secondary record. Entity matching must precede this merge; field precedence alone does not determine whether two records describe the same company.

Primor reports a resulting dataset of 100 companies with zero AI/token cost and fairly good, though not best, coverage. The useful distinction is the absence of model-token processing in the described extraction and merge path, not the absence of AI in scraper setup. The accounting boundary for AI-assisted creation and repair is unspecified. This was also a restricted enrichment task: its sources and required fields were sufficiently predictable for simple collection and merge rules to work.

Part of the direct pipeline's advantage comes from structure that already exists at the source. LinkedIn has company, person, and job entities, with relationships between them. In this relatively simple scenario, the pipeline can reuse part of that ontology instead of reconstructing every relationship from unstructured text. Low collection cost is easier to achieve when the source has already done some of the organizational work.

An out-of-the-box API still has an advantage: it needs less setup. To include that difference, Primor assigns the custom pipeline a hypothetical week of setup costing $5,000, distinct from the roughly one-day experiment. Under that allowance, his illustration places break-even just above 15,000 entities or queries. He offers 10,000, 30,000, and 100,000 as possible thresholds for other use cases, not additional measured results.

The corresponding simplified cost model is:

Here, S is setup cost, N is cumulative enrichment work, and the two unit costs describe renting and operating the owned path. A positive break-even requires the rented unit cost to exceed the owned unit cost. The talk's threshold cannot be reconstructed from the supplied figures because the underlying per-record prices and ongoing operating assumptions are not specified. The useful question is nevertheless concrete: how much recurring work pays back the setup investment?

Search and CaaS provide convenient, plug-and-play access. An owned pipeline becomes more attractive when the knowledge work is persistent, consistent, and growing. Its collection and preparation work can be paid for before agents retrieve the resulting records. Primor initially calls subsequent retrieval free, then immediately qualifies that description: the benefit is avoiding another external collection charge for every reuse, not eliminating storage, local retrieval, or operating costs.

That difference gives agents more room to work. Asking the same question repeatedly need not trigger repeated purchases of the same external context. The team can also apply custom business logic and connect collected records with internal data. At a large cumulative query volume, those capabilities can matter as much as the initial price difference.

Ownership does not stop decay. The web continues to change, and a retained company record still needs refreshing. The long-term design must separate reusing what is already known from collecting what has changed. Otherwise, a cheap local answer can simply become a stale one.

The choice follows the workload:

• Ad hoc or changing questions: Search and CaaS can get an agent far without a dedicated collection system.
• Different task families: Mix retrieval providers, and consider lighter models where they can do the necessary processing.
• Persistent, repeated research: Evaluate an owned pipeline against cumulative frequency, because the setup investment may pay back sooner than expected.

Primor closes with “Owned context compounds while rented decays.” A one-time question may be served perfectly well by search. Repeated work creates a different opportunity: retain useful context, keep it current, and let successive questions benefit from the collection and organization already performed.