# e2e and KERNEL: watch every agent test, and run them all at once > Run your e2e tests in KERNEL cloud browsers. Watch agent steps live, keep an MP4 replay of every failure, and run your agent tests in parallel. By Kacper KapuĊ›ciak. Published 2026-11-10. Canonical URL: https://e2e.com/blog/e2e-and-kernel A test failed in CI last night. The report says the agent step "find the section that explains how to create a browser session" failed. So what did the agent actually do? Did it open the wrong page? Did a cookie banner cover the link? Did the site send it somewhere else? With a deterministic step you only get the information that something has failed. With an agent test, the agent made its own reasoning and the log can't show you what it saw. You need the browser itself. KERNEL runs Chromium in the cloud, each browser in its own virtual machine, and every browser comes with a live view you can watch and a recording you can download as an MP4. With [`@e2e-dev/kernel`](https://e2e.com/docs/integrations/kernel), every [e2e test](https://e2e.com/) runs in one of those sandboxed browsers. [Video: e2e test running on a cloud KERNEL browser](https://e2e.com/blog/videos/e2e-and-kernel-demo.mp4) _e2e test running on a cloud KERNEL browser._ ## Mixing agentic and deterministic tests Here's a test from the example: ```ts test("finds the browser session documentation", async ({ app, agent, screen }) => { await app.open("/docs/api-reference/browsers/create-a-browser-session"); await agent.act("find the section that explains how to create a browser session"); await agent.assert("the page explains how to create a browser session"); await expect(screen.getByRole("heading", { name: "Create a browser session" })).toBeVisible(); }); ``` `app.open` goes straight to the API reference page, with no model involved. Then `agent.act` gets a goal written the way a person would say it. The test doesn't tell the agent where the section is or what the link is called. `agent.assert` hands the question to [a separate judge model](https://e2e.com/docs/agent-steps#what-the-model-sees), which looks at the page and decides whether it really explains how to create a browser session. The last line doesn't need a model at all. It checks that a heading with that exact name is on the page. The second test in the file is fully deterministic and doesn't use the agent. It reads the date of the newest changelog entry with `browser.evaluate` and fails if that entry is more than eight days old. You can [mix both kinds of tests in one suite](https://e2e.com/docs/core-concepts) and decide per step whether to describe a goal or script it. ## A browser that records its failures ```ts export default { targets: [ { name: "docs", engine: web({ viewport: null, browser: kernel({ stealth: true, viewport: { width: 1920, height: 1080 }, }), }), app: { url: process.env.DOCS_URL ?? "https://www.kernel.sh" }, video: "retain-on-failure", }, ], } satisfies E2EConfig; ``` Here's a sample KERNEL config. This recommendation is most likely to be successful in gaining access and sets a 1920 by 1080 screen. The web engine's `viewport: null` lets the page fill that window, so the live view shows the page the way a user sees it. `video: 'retain-on-failure'` records every test and keeps the recording only when the test fails. That's the file you want the morning after a red build. ## Watch a test while it runs For every browser it starts, the reporter prints a line like this: ```txt browser , watch at ``` Open the link and you can see the agent working in the browser as it happens. KERNEL built the live view for humans in the loop, so it's interactive unless you open it as read-only. When e2e starts a hosted browser on KERNEL, it adds labels, called **tags**, to that browser. You see it as `e2e_run`, `e2e_target` and `e2e_slot` so you can easily tell the browsers apart in the KERNEL dashboard. ## Replay the failure When a test records video, e2e saves KERNEL's replay as `video/replay.mp4` next to the test's other results. It shows the whole window, with the tabs and the address bar, so you see the redirect, the banner, or the wrong page that the agent opened. KERNEL browsers run headful by default, with a real display, which is what makes the replay possible. Replays run at 10 frames per second by default, but you can raise it up to 60 frames per second (may require GPU). If you switch a browser to headless, e2e records its own screencast of the page instead. ## Agentic tests need parallel browsers more A scripted click takes milliseconds. An agent step waits for a model, so it takes seconds. Run 40 agent tests one after another and the pull request waits for every one of those model calls in a row. e2e removes most of them. After an agent step passes, e2e records what the agent did and [replays it on the next run without a model call](https://e2e.com/docs/cache). What's left is the first run of a new test and the runs after someone changes the UI, and those are exactly the runs where parallel browsers pay off. You can adjust the amount of KERNEL browsers your test suite runs at once with `workers` in your e2e config. KERNEL creates a browser in under 30 milliseconds, so starting ten of them won't slow your suite down in a noticeable way. By default, each worker uses one browser for the whole run. Each test gets a fresh browser context, so cookies and storage don't leak between tests. If you want a new browser for every test, including retries, set `scope: 'attempt'`. ## No leftover browsers When the run ends, e2e deletes every browser it started for that run, including the browser of a worker that crashed. If the whole runner dies first, KERNEL deletes each browser after 60 seconds of idle time, or after the `timeout_seconds` you set. ## Try KERNEL today Install the provider and the KERNEL SDK: ```bash npm install --save-dev @e2e-dev/kernel @onkernel/sdk ``` Set `KERNEL_API_KEY` in your environment or as a CI secret, point your target's `browser` at `kernel()`, and run the suite: ```bash npx e2e run ``` The fastest way to see it working is KERNEL's cookbook. Clone it, add your keys, and run `npm test`. To test your own site, change `DOCS_URL` and the paths in the test file. - KERNEL's cookbook: [github.com/kernel/cookbooks/tree/main/integrations/e2e-kernel](https://github.com/kernel/cookbooks/tree/main/integrations/e2e-kernel) - KERNEL: [kernel.sh](https://www.kernel.sh) - e2e on KERNEL: [e2e.com/docs/integrations/kernel](https://e2e.com/docs/integrations/kernel) If you like where this is going, a star on [GitHub](https://github.com/tester-army/e2e) helps more people find e2e.