today
introducing config registry: recommended browser and proxy settings for sites
config registry tells your agent which browser and proxy settings grant access to a target website. developers and agents save time and tokens because reaching the page stops being a per-site engineering project. in our pre-launch testing, recommendations from config registry made 96% of previously inaccessible sites reachable in pre-launch testing.
legitimate agents get blocked
agents today need to work across hundreds of idiosyncratic websites, but the internet wasn’t built for them.
sites have no way to tell your agent's intent. at the tls handshake, the fingerprint, and the request pattern, a legitimate agent doing a customer's work and a bot accessing a catalog look the same. and today, developers building these legitimate agents start from scratch on every site: which proxy class, which stealth setting, and which navigation approach actually loads the page. this trial and error takes days and burns tokens. and breaks again when the site changes its own bot policy.
as we laid out in building for the internet’s trillionth user, our vision is for agents to take on work on our behalf. the excitement around and rapid adoption of ai assistants, like instinct and muse, have shown how crucial agent browser-use is and how dynamic it has to be to complete tasks.
what config registry is
config registry provides recommended browser and proxy configurations that have been tested against websites, with evidence included on success rate, number of trials, and when it was last tested.
in our pre-launch testing, we took hundreds of sites where customer agents in production were getting blocked. using configs recommended by config registry, agents were able to successfully reach 96.1% of previously inaccessible sites. we expect this number to increase as more sites get analyzed and added to the cache.
coframe has saved hundreds of hours of engineering time with config registry as their agents work across customer sites.
“Every customer site is protected differently. about three in four agent sessions on those sites used to hit a bot wall until we found the right browser settings, and finding them by hand took someone 30 minutes to a couple of hours, usually after an agent had already stalled. Now KERNEL tests the options against the real site, within the countries each customer allows, and tells us what works. We reuse that every time an agent starts on that customer. Nobody, human or agent, spends time on browser configuration anymore, and agents finish the actual task faster.”
aleksey korshuk, head of machine learning | coframe
how it works
config registry is two things:
a cache. recommended configurations keyed by url, matched from most specific to least: exact path first, then hostname, then domain. that granularity matters because a site's login page usually runs stricter protection than its marketing homepage.
an llm-backed decision engine. when we don't have a recommendation for a url, we run the search live: candidate browser configs are loaded against the real page in parallel sessions, each render is classified as served or blocked, and the winner is re-run to confirm its pass rate before you get it.
add config registry to your agent workflow
look up what we already know. lookup returns from the registry's current knowledge base. it doesn't visit the site, start work, or make changes.
const result = await kernel.configRegistry.lookup({
url: 'https://www.kernel.sh/docs',
});
if (result.recommendation?.type === 'recommendation') {
console.log(result.recommendation.browser, result.recommendation.proxy);
}
run an analysis when we don't have a recommendation. resolve starts an analysis, or joins one already running for the same url. most finish in under four minutes, so you can pass the returned analysis id to the sdk waiter rather than blocking the call.
const started = await kernel.configRegistry.resolve({
url: 'https://www.kernel.sh/docs',
});
const result = await kernel.configRegistry.analyses.waitForResult(started.analysis!.id);
an analysis tries the url under different permutations of browser and proxy settings. when one loads the site, we run it again to confirm it works consistently. evidence aggregates across every run we've done for that target, and the top choice comes back as recommendation. when several configurations have equally strong evidence, working_configurations lists them in preference order, with ties favoring your requested proxy country.
tailor it to your workload. allowed_proxy_countries limits where the proxy exits if your workload has to run from specific regions. intent describes what you actually plan to do on the site. loading the first page doesn't prove a configuration supports the rest of a workflow, so the analysis attempts the described workflow and reports whether it finished, needed authentication or payment, was blocked, or stopped early.
const started = await kernel.configRegistry.resolve({
url: 'https://www.kernel.sh/docs',
intent: 'search the docs for proxies and open the first result',
allowed_proxy_countries: ['US', 'GB'],
});
an analysis can also return short natural-language guidance based on what it observed while navigating. guidance is useful even when nothing worked, because it names what got in the way. use it as a starting point for your agent's instructions.
apply it yourself. recommendation.browser can be passed as-is when you create a browser. the proxy recipe is a one-time create whose id you store and reuse when creating new browsers.
const proxy = await kernel.proxies.create({
...recommendation.proxy.create,
name: 'config-registry-kernel-docs',
});
const browser = await kernel.browsers.create({
...recommendation.browser,
proxy: { id: proxy.id },
});
recommendations are advisory because the internet is dynamic and each browser session is unique. we don't create a browser or a proxy, nor do we change anything about your sessions until you ask.
try config registry today
config registry is now available in all paid plans.
the fastest way to get started is with our docs: https://www.kernel.sh/docs/config-registry
where this is going
config registry is the first primitive of something larger: we want KERNEL to compound the capabilities of every agent working on the web, and config registry is one way that we’re sharing per-site operating knowledge and investing in ways to make browser tasks faster and more reliable.