Why Agents Need Indexes, Not Applications

There are currently two ways to give an AI agent access to business data. The first: make it control a browser so that it uses your applications like a human — clicking, scrolling, reading pages. The second: give it access to a structured index that it queries directly. The first approach fascinates, because it promises to automate everything without changing anything. Our conviction, after having measured it, is that it does not compare — and that the difference is not marginal, it is two orders of magnitude.

The cost: reading pixels is structural waste

When an agent “browses,” each page viewed must be captured, converted to text or image, and then ingested by the model. A job site results page easily represents 30,000 to 50,000 tokens when serialized, the overwhelming majority of which is noise: menus, banners, scripts, layouts. The useful data — ten offers with their title, company and location — would fit into 1,500 JSON tokens.

On the scale of a real sourcing task (let's say 200 pages consulted), the difference is significant: several million tokens ingested on the navigation side, compared to a few tens of thousands on the index side. The inference cost ratio is on the order of 50 to 100 to 1, even before counting the headless browser infrastructure to maintain.

Latency: minutes versus seconds

A navigation interaction — load the page, wait for rendering, let the model interpret, decide on the next click — rarely takes less than 5 to 10 seconds. Real tasks are dozens of them, in series, because each step depends on the previous one. A multi-criteria search that crosses three sites can therefore last 10 to 15 minutes.

The same intent expressed against a structured index is a single query with filters, which responds in a few hundred milliseconds. It's not only more comfortable: it changes the nature of possible uses. Real-time CRM enrichment, monitoring that runs every hour on 1.4 million offers, a conversational agent that responds while the user reads their question — none of these uses exist at 10 minutes per request.

Reliability: the real breaking point

Cost and latency are negotiated; reliability, no. An agent who browses is exposed to everything that makes the web fragile: interface redesigns that silently break journeys, dynamically loaded content, CAPTCHAs and connection walls, A/B tests that mean that a page is never the same twice. The completion rates observed on multi-step web tasks peak, according to public benchmarks, well below what a business process requires — and above all, failure is often silent: the agent believes it has read the correct value.

An index exposes a contract: a versioned schema, typed fields, explicit error codes. When something fails, the failure is detectable and treatable. When something responds, the provenance and freshness of the data are known. For a recruitment or sales process, this difference separates the production tool from the demonstration prototype.

Navigation still useful — upstream, not downstream

Let’s be precise: having agents read the web makes sense. This is even how an index is built and maintained — collection agents who browse partner sources, detect changes and continuously populate the database. But this work must be done once, industrially, upstream, then shared. Doing it again with each request, with each client, in each conversation, amounts to having the program recompiled each time it is executed. Navigation is a means of producing the index; it is a very bad mode of consumption.

Conclusion

The question is therefore not whether agents will replace users in applications, but where to place the border: the disorder of the web on one side, a clean data contract on the other. This is precisely the function of sourcing.sh — to take on the complexity of collecting on companies, profiles, schools and offers, and expose to agents what they really need: not pages to decipher, but an index to query, via API or MCP, for a fixed price and without a meter.