We Built an Agent That Explores a Web App Before Anyone Writes a Test

The Exploration Agent Records Every Page, Control and Flow It Can Reach

A normal Kane CLI run follows one path, such as login or checkout, because someone asked for that path. The exploration agent has no path to follow, so it starts at the URL you give it and keeps moving through every page, junction and flow it can reach.

For each page it visits, the exploration agent records the following:

• Controls - the interactive elements on the page, such as buttons, links, forms, menus and input fields.
• Flows - the journeys that lead into the page and out of it, so the map shows how pages connect.
• Screen states - the different versions of the same screen, such as a form in its empty state and again after a validation error.

Exploring a large app can take hours, so we run exploration as a long-running cloud job instead of a terminal session you have to babysit. The Kane CLI 0.10.0 release notes cap a run at up to 20 cloud browsers at once, and you can open any single browser session while the job runs to watch what the agent is doing on that page.

The exploration map doesn't start over on every run. Each new run adds its screens, flows and findings to the same map, compares every screen and flow with earlier runs, tags what is new or changed, and re-verifies the changed flows on the next run.

Every flow on the map carries a status, such as verified, changed, broken or not yet verified, so the map doubles as a health check of the app's journeys. At the end of each run, the exploration agent also writes a skill file that records what it learned about the app, such as the sign-in method, the business areas it grouped screens into and the places it should stop, and the next run starts from that skill file instead of from zero.

The results live on an Exploration page in TestMu AI Test Manager, with a graph of the app that collapses screens into business areas when you zoom out, plus tabs for screens, flows, findings and run history. You can set up an exploration there or start one from the terminal, and the Exploration page copies the matching kane-cli command for any exploration you set up in the browser:

npm install -g @testmuai/kane-cli
kane-cli login
kane-cli explore run --url https://yourapp.com

You Decide How Far the Exploration Agent Is Allowed to Go

An agent that clicks every button on a live app needs limits, so most of the setup for an exploration is about what the agent may touch. The table below lists each setting and what it controls.

The terminal exposes the same limits as flags on kane-cli explore run: --policy read_only or mutating, --allow-domain for the hosts the run may walk, and --deny for a control name the agent never acts on under any policy.

The Exploration Agent Flags Problems Without Being Told What to Look For

The exploration agent has no test cases to pass or fail, so instead it reports anything on a page that looks wrong to a user. The findings fall into the kinds below.

Every finding comes with an Evidence Pack holding a clip, the network log, the console log and the exact HTML element behind the problem, plus a short record of what the agent saw, what it expected and what actually happened. Findings carry a High, Medium or Info severity, and a team can triage each one as bug, duplicate, expected, flaky, test environment or won't fix.

The real bugs can be raised from the finding itself, with the title, severity, steps to reproduce and chosen evidence already filled in.

One of our test explorations ran against Automation Exercise, a public practice site for test automation. After six runs, the exploration map held 15 screens grouped into 4 business areas and 21 flows, 14 of them verified, and the same runs raised 64 findings: 20 High, 35 Medium and 9 Info. We treat findings as leads for a person to review, because an agent with no spec can't always tell a bug from a deliberate design choice.

The Exploration Map Becomes the Context for Test Generation

The map is the part of exploration we care about most, because it gives the rest of Kane CLI something to work from. Kane CLI's test generation normally starts from requirements and turns them into use cases and acceptance criteria, as the PRD to evidence walkthrough shows, and when there are no requirements the exploration map takes their place.

The full loop on an undocumented app runs like this:

• The exploration agent walks the app and saves a map of its pages, controls and flows, along with its findings.
• Kane CLI reads the map as context and writes use cases and acceptance criteria for the flows it found. With the "Use exploration as Assurance context" option on, those use cases and tests stay in sync with the map after every run.
• Kane CLI runs the resulting tests and saves an Evidence Pack for each run, with the screenshot, network data and page state behind every step.
• A person reviews the generated tests, keeps the ones that match intended behaviour and fixes the ones that encoded a bug.
• The kept tests go into CI and run on every future pull request.

The human review in step four matters more than it looks. A test written from observed behaviour will happily assert that a bug is correct, so the review is where someone who knows the product decides what the app is supposed to do.

Kane CLI sits alongside the Playwright, Selenium or Cypress suites a team already runs. The tests that come out of exploration cover the parts of the app those suites never reached, which is also where human exploratory testing usually has the least time to go.

Engineering Choices That Shaped How Exploration Runs

We made three decisions early that changed how exploration behaves in practice.

• Cloud execution - an exploration that keeps up to 20 browsers open for hours would tie up a developer machine, so each job runs on cloud VMs on HyperExecute and keeps going after you close the terminal.
• A separate concurrency pool - exploration sessions draw from a different pool than regular Kane CLI test runs, so a long exploration never takes browser capacity away from the tests a team runs in CI. Each KaneAI Max licence can run three explorations at the same time.
• Tenant isolation in the database - the exploration store lives in its own Postgres database, uses the pgvector extension, and applies row-level security per organisation as the tenant boundary.

The PostgreSQL row security documentation notes that superusers and roles with the BYPASSRLS attribute always bypass row security. The database user that the exploration service writes with has neither, so one organisation's app map stays out of reach of every other organisation's queries.

Exploration Covers Web Apps Today, and There Is Plenty Left to Build

We would rather list the gaps here than have you find them in the first hour:

• Exploration works on web apps only for now, while the rest of Kane CLI already tests both web and mobile apps.
• The exploration agent stops at a sign-in wall until you give it credentials, and in Read-only mode it can't reach screens that sit behind a submitted form.
• The exploration agent reports what looks wrong, but without a spec it can mistake an intentional design choice for a bug, which is why its findings go to a person for review.
• Exploration is part of the KaneAI Max plan, and each licence can run three explorations at the same time.

If you maintain an app that nobody fully documented, point Kane CLI Exploration at it and see what the map shows you. The Kane CLI getting started guide covers the install, and we will be in the comments to answer questions about how exploration works.