# The Rise of CaaS: Context-as-a-Service for Agentic AI Omer Primor, Bright Data | AI Engineer World's Fair 2026 | 22:20 Source: https://www.youtube.com/watch?v=Ot4OPrPH4xY Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/the-rise-of-caas-context-as-a-service-for-agentic-ai Published: 2026-08-14 Tags: cost, data-pipelines, search ## TL;DR - The web is context for agentic knowledge work, but its information changes too quickly for one-time extraction to stay useful. - Context-as-a-service vendors can answer quickly for the entities and fields they already cover, while general search can explore beyond its stored knowledge. - For repeated work, building and owning a context pipeline can become cheaper than renting context, with the crossover in Primor's test occurring just above 15,000 queries. ## Summary Omer Primor argues that agents should treat the web as an ongoing source of context rather than a static data store. Social content can become stale in less than a day, while news, finance, and retail data is mostly irrelevant after 30 days. Search and context-as-a-service products make ad hoc research easy, but repeated queries keep costing money even when nothing has changed. Primor describes a small test that enriched 100 event sponsors across 25 fields. The context vendors had lower coverage than some search tools because they could only answer from data they had already collected. He then built a simple scraper pipeline in about a day and priced setup at $5,000. In that example, owning the pipeline crossed over with rented services at just above 15,000 queries. The result depends on the use case, but persistent, repeated knowledge work may justify paying upfront for owned context and making later retrieval effectively free. ## Key ideas ### The web has become context for agents doing knowledge work [01:50](https://www.youtube.com/watch?v=Ot4OPrPH4xY&t=110s) Primor begins with Bright Data's role in extracting web data, then changes the framing for AI agents. An agent can search the web, use the result as context, and continue toward an action or conclusion. The fetched data is only one step in a larger workflow. This matters because agents need information in forms that support decisions and downstream tasks, rather than simply returning a page or a database row. Primor says the web is messy, unstructured, and constantly changing, so systems built around it need to account for those properties from the start. ### Web context decays quickly, so collection cannot be a one-time job [02:41](https://www.youtube.com/watch?v=Ot4OPrPH4xY&t=161s) Primor presents a data-decay analysis from Bright Data. Social media content becomes irrelevant in less than a day. News, finance, and retail data is mostly no longer relevant after 30 days. He uses these examples to reject the idea that a team can capture the web once and keep using the result indefinitely. Context extraction has to continue over time. A monthly refresh may already be too slow for some sources. The useful lifetime depends on the kind of information, but every system needs an ongoing process for updating what agents rely on. ### Search has expanded from Google into agent-specific products [03:37](https://www.youtube.com/watch?v=Ot4OPrPH4xY&t=217s) Primor describes a rapid change in how search reaches users and agents. Google dominated human web search for roughly two decades, then search appeared inside chatbots and large language model products. A newer group of companies, including Exa, Parallel, You.com, and Tavily, indexes the web specifically for agents. He also mentions Amazon building an index for retrieving web context through AgentCore and Microsoft repackaging search through its agent development and orchestration products. This creates more ways to retrieve information, but Primor says search only covers part of what agents may need. ### Search does not naturally answer questions about change over time [05:32](https://www.youtube.com/watch?v=Ot4OPrPH4xY&t=332s) A current search can find the price of sneakers or the open jobs at a company, but it does not automatically explain how the price changed over six months or how the company's headcount evolved. Primor says the relevant information existed on the web at different points, yet ordinary search does not necessarily preserve and connect those historical states. Questions about change require a system that keeps structured records and compares them over time. This gap leads to a different class of products that Primor calls context-as-a-service, or CaaS. ### Context-as-a-service products build structured, domain-specific views of the web [06:33](https://www.youtube.com/watch?v=Ot4OPrPH4xY&t=393s) CaaS products let agents retrieve information through MCP, CLI, or API for knowledge work. Primor names use cases in e-commerce, travel, finance, market research, HR, real estate, and sales intelligence. These products crawl and index sources, then build knowledge graphs that structure entities, remove duplicates, and combine information from multiple places. He compares them to vertical search engines that are very good within a specific area. Their focus is the task and domain they support, rather than general web discovery for human users. ### A small enrichment test found lower coverage from some context vendors [10:01](https://www.youtube.com/watch?v=Ot4OPrPH4xY&t=601s) Primor says his team ran a test rather than a benchmark. They enriched one company across 25 fields, including basic details such as the domain, name, and headquarters, along with harder fields about hiring and people. An agent ran the process 100 times across the event's sponsors, using Opus 4.8 as the harness and applying budget guardrails. Search products generally converged on similar coverage. Primor was surprised that two CaaS solutions placed lower. Their limitation was that they could only answer from information they had already collected. A search system could keep exploring when the required field was missing. ### Query frequency drives the cost of rented context [12:32](https://www.youtube.com/watch?v=Ot4OPrPH4xY&t=752s) Primor separates the cost of one record from the cost of asking about many records or asking repeatedly over time. A market researcher or private equity team may revisit the same companies, checking news, hires, departures, and other changes. Each repeated query costs about the same as the first, even when the answer has not changed. Teams respond by checking weekly rather than daily, skipping questions, or taking 10 or 20 results instead of everything available. Primor calls this renting context, because the team pays again whenever it needs to use it. ### A simple owned pipeline can cross over with rental costs [15:59](https://www.youtube.com/watch?v=Ot4OPrPH4xY&t=959s) To test the alternative, Primor asked an AI engineer to build a basic pipeline in about a day. It used the company name to find relevant URLs, then retrieved information from known sources such as LinkedIn Companies, LinkedIn Jobs, and Crunchbase. The team built two dedicated scrapers, merged the results into entities, and applied simple conflict rules. Primor says the pipeline used no AI tokens and had fairly good coverage, although it was not the best result in the test. He priced a week of setup at $5,000 to illustrate the tradeoff. In this example, owning the pipeline became cheaper just above 15,000 entities or queries, though the actual threshold depends on the use case. ## Notable quotes - "The web is no longer just a source of data. We can actually start looking at it as a source of context." (01:50) - "Frequency is the cost killer when we talk about these and we need to acknowledge that." (14:27) - "Basically, we're renting context. We're not owning the context that we use." (15:41) - "Owned context compounds while rented decays." (21:23) ## Tools & references mentioned - Bright Data - Exa - Parallel - You.com - Tavily - Amazon AgentCore - Microsoft Web byq - ZoomInfo - GTM.ai - Google - Opus 4.8 - LinkedIn Companies - LinkedIn Jobs - Crunchbase - Scraper Studio ## Who should watch - You are building an agent that repeatedly researches companies, markets, jobs, products, or other changing web entities. - Your team uses search or CaaS for recurring workflows and needs to decide when a custom retrieval pipeline is worth the setup cost. - You need to understand why a specialized context vendor may have lower coverage than general search for fields outside its stored data.