Skip to main content
Browser Loop gives your agent browser tools. You pick the tools, it supplies the declarations each model provider accepts, executes every action against a Kernel browser, and returns plain objects your existing agent loop can use. It’s open source (kernel/browser-loop, MIT) and published as @onkernel/browser-loop. Reach for it when you’re building an agent and don’t want to write the translation layer between “the model asked to click at (420, 280)” and an actual browser action. If you’re driving the browser yourself from a script, use Playwright execution or computer controls directly.

What it handles

Frontier models expose browser and computer control differently: native computer-use declarations, predefined browser action sets, ordinary function tools, different coordinate systems, different screenshot and result contracts. Every one of them still expects you to run a real browser, translate each action into an SDK call, and capture the right feedback so the model can verify the action landed. Browser Loop does that and stops there. It doesn’t supply an agent class, a session format, or a UI — your framework already has those.
  • Framework-neutral tool catalog. Tool identities (kloop.*.v1) and model-facing names are byte-identical across bindings, so transcripts and evals stay comparable.
  • Kernel-browser execution. Canonical actions run through Kernel’s computer API or a raw-CDP executor against a session with your profile and proxy.
  • Per-model compatibility. Provider transforms compose only the declarations and request fields the tools you selected require.
  • A pi binding and extension, with Eve and AI SDK bindings next.

Install

Build an agent

attach() binds a browser once; compile() turns a (model, tools) pair into plain agent objects.
The compiled model and agentTools have to reach the agent together: selecting a provider-native browser or computer surface can change the transport the model needs, and that’s derived from the tools you chose.

Check which tools a model accepts

Not every model accepts every tool, and two providers’ native surfaces can’t coexist. Ask instead of guessing — and rebuild the menu after each change rather than caching a per-tool verdict:

Try it from a terminal first

The pi extension contributes the same tools to a pi session, so you can find out which tools and which model actually work for your use case before deploying anything. Same catalog, same tool identities, same model knowledge as the SDK path:

Repository and architecture docs

Harness variant, swapping tools on a running session, and tool contexts.