Omer Primor on CaaS: where renting context stops making sense (#AI)
For an agent, context comes with some uncomfortable economics. When a question is a one-off, AI search looks like an ordinary API: ask, get an answer, move on. But if you check the same companies, vacancies, and prices every day, the meter starts again—even when nothing has changed. At some point, we are no longer renting an answer. We are renting the system's ability to remember.
That is the boundary Omer Primor of Bright Data examines in “The Rise of CaaS: Context-as-a-Service for Agentic AI,” a talk from AI Engineer World's Fair 2026. The name sounds like one more “-aaS,” but the question inside is a serious one: when is it enough for an agent to buy context, and when should you collect, update, and store it yourself? The topic already appeared in my review of Hands-On RAG for Production, where retrieval gradually grew from a single pattern into a platform layer. Primor adds economics to the architecture: who pays to update knowledge, and who retains the accumulated asset?
His starting point is that the web is not a snapshot. According to the Bright Data analysis shown in the talk, social-media data can become stale in less than a day, while news, financial, and retail information generally does so within 30 days. This is the company's internal analysis, not a universal law. But the underlying problem is clear: finding a page once is not enough when an agent needs to know how a price, vacancies, or a company's makeup has changed.
In Primor's description, CaaS resembles vertical search combined with a data platform. Such a service collects sources in advance, normalizes and deduplicates entities, links them in a graph, and gives an agent context through an API, CLI, or MCP. The advantage is structure and a quick start. The limitation is built into the same model: if a required field is absent from the service's data model, an agent cannot conjure it into existence with a query.
Then query frequency produces a very large bill.
With per-query pricing, a repeat request costs as much as the first one even when nothing has changed. Primor observes that, at scale, teams quietly begin cutting not costs but value: checking a company weekly rather than daily, taking ten results instead of the full set, or avoiding an expensive question altogether. Price becomes a constraint on freshness—and nobody has called that an architectural decision yet.
To demonstrate the mechanics, the Bright Data team ran a small test. It checked a record with 25 fields for 100 conference sponsor companies and compared AI search, several CaaS offerings, and direct collection from known sources. Primor explicitly calls this a test, not a benchmark. Coverage was similar, but some CaaS products lost to search on the chosen fields: a service knows only what it decided to collect. He also notes that those platforms may have other data and advantages that the test did not measure. For its own option, the team used existing Bright Data sources and two purpose-built scrapers. According to Primor, the demo pipeline took about a day. He then estimated a full setup at one week and $5 000; with those assumptions, the crossover came slightly above 15 000 entities or queries.
It is an attractive number, but I would not copy it into a procurement spreadsheet. Primor immediately allows for 10 000, 30 000, or 100 000 instead: everything depends on the use case. He also represents Bright Data, while the “build it yourself” path uses that same company's tools. Scraper maintenance, full entity resolution, quality control, legal constraints, observability, and on-call work all sit outside the calculation. A self-built pipeline looks especially cheap on a slide. In real life, the source site's first redesign quickly adds people and coffee to the formula :)
So I would choose based not on the magic 15 000 threshold but on five questions: — How often does the query repeat? — How quickly does the data become stale? — How stable are the entities and the schema? — What is the cost of incorrect or stale context? — What does owning the entire pipeline cost?
My default option here is a hybrid. One-off questions and sources that cannot be known in advance remain with AI search or CaaS. Frequent queries over well-understood entities and fields are better served by in-house collection, normalized storage, and incremental updates. External search remains a fallback for gaps rather than a mandatory step in every agent run. This is the same “rent—adapt—own” boundary I described in the longread on the AI stack. What matters here is not the price of one query, but the cost of an accepted result at the required freshness.
The practical next step is simple: take one recurring use case and calculate its frequency, freshness requirements, cost of error, and full TCO. Then answer the more interesting question: at what point does your agent stop searching and start operating its own data product?
#AI #Agents #Architecture #Data #PlatformEngineering #FinOps