In this series
- 1. Port
- 2. Limits
- 3. Server
- 4. IP Address
- 5. Proxy
- 6. Encryption
- 7. API Key
- 8. Container / VM
- 9. Skill / Plugin
- 10. Policy
- 11. Audit Log
“Google returns unlimited results.”
That was the first time I ever heard that said out loud. For the common user, you enter what you're looking for and you scroll until you find what you want. But in the back of users' minds, they could scroll to page 100 if they felt like it. Apps like TikTok and Shopee have given the illusion that you can scroll endlessly through content, so people kinda just expect that from any system.
It came up in a debate with a user who was building a search site. You type what you want in natural language, and it finds matching results. Behind it sat a vector database, which lets you search by language similarity rather than exact keywords. Such systems usually define a limit like k=50, meaning a search returns at most 50 results. Their question, reasonably, was: why? Google doesn't stop at 50.
Fun fact before we continue: Google doesn't return unlimited results either. Try clicking through to the end sometime. It quietly stops after a few hundred, out of the “millions of results” it claims at the top of the page. Nobody notices, because nobody gets that far.
Why more results means worse results
The counterintuitive part is that the limit isn't there to save effort. It's there because returning more actually makes the answer worse. Three reasons:
1. Similarity search always finds something
A vector search doesn't return “everything that matches.” It returns the k nearest things, whether or not they're actually near. Result #3 is usually a great match. Result #300 is just whatever happened to be the 300th-least-unrelated thing in the database. Relevance falls off a cliff after the top handful, so a big k mostly pads your results with noise that looks like an answer.
2. Whatever reads the results has a budget too
In most modern search systems the results aren't shown to you directly. They get handed to an AI model that reads them and writes an answer. Models have a finite context window, and they demonstrably pay less attention to things buried in the middle of a large pile. Feed a model 50 focused results and it reasons well. Feed it 500 and the good stuff drowns in the mediocre stuff. More context, less relevance.
3. Every result costs time and money
Each extra result has to be scored, ranked, fetched from storage, and shipped over the network. That's latency you feel and compute someone pays for. Spending it on results 51 through 5,000, which nobody will ever read, is pure waste. The engineering discipline is to spend the budget making the top 10 excellent instead.
Limits are the norm, not the exception
The bigger realization from that debate: “limits” in general don't seem to be a well-understood concept. You don't have unlimited storage. You don't have unlimited memory. You don't get instantaneous response times. Every system you've ever used has hard limits everywhere, and it takes clever engineering to make it seem like they aren't there. The endless feed on TikTok isn't endless. It's a small batch of results, fetched again and again, just before you reach the bottom. The magic trick is in hiding the seams.
An analogy to round off the topic: say you're boiling water on a stovetop. The more water in the pot, the longer it takes to boil. It's exactly the same with computers and code. The more database rows, the longer it takes to find what you want. A result limit is just the engineer deciding how much water goes in the pot, so it boils before you lose patience.
What this has to do with OpenClaw
OpenClaw agents run on top of exactly this kind of search. Every time your agent “remembers” something, it's doing a similarity search over its memory and pulling back the top k matches, not its entire history. Every time it searches the web or your files, a limit decides what makes it into its context window and what doesn't.
So when you see an agent configured to retrieve 50 results instead of 5,000, that's not the system being lazy. That's the system protecting the quality of its own reasoning. The agents that feel smartest are the ones fed the least, best-chosen context.
Tropic tunes these limits for you.
Every OpenClaw instance on Tropic ships with memory and retrieval limits already tuned for quality, so your agent gets the most relevant context without you touching a config file.