# agentic-qe's Windows install succeeds whether or not the search index works

> The 60-agent quality engineering fleet is the headline, but the most useful thing in this README is a warning about a failed native build that does not fail the install. On Windows, if the HNSW native module cannot compile, AQE quietly falls back to a JavaScript path that is correct and degrades to linear scan, and the only way to find out which one you have is a health command.

**proffesor-for-testing/agentic-qe** — Agentic QE Fleet is an open-source AI-powered QA/QE platform designed for use with Coding Agents (works best with Claude Code) featuring specialized agents and skills to support testing activities for a product at any stage of the SDLC. Free to use, fork, build, and contribute. Based on the Agentic QE Framework created by Dragan Spiridonov.

- Repository: https://github.com/proffesor-for-testing/agentic-qe
- Website: https://agentic-qe.dev/
- Stars: 493 · Forks: 97
- Language: TypeScript
- License: MIT
- Published: 2026-09-15 · Updated: 2026-09-15 · Language: en
- Canonical page: https://hysenlabs.com/projects/proffesor-for-testing-agentic-qe

## The Windows fallback is correct and quietly quadratic

The single most valuable paragraph in this README is a caveat about a fallback. Several performance-oriented native dependencies ship as optional modules, and one of them, the native HNSW search library, has no prebuilt binaries and compiles from source through a native build tool. If it does not build on Windows, AQE does not fail; it falls back to a JavaScript path at runtime. The README then spells out what that fallback is: correct, but degrading to linear-time brute-force search when neither of the two native options is available. Fine for small projects, explicitly unsuitable for large indexes, described as tens of thousands of vectors and up. That is the entire risk profile in one sentence. Nothing about it is unsafe or incorrect, and nothing about it announces itself at runtime either, which is why it is worth knowing before you point the tool at a large codebase rather than after you wonder why coverage analysis stopped scaling.

## A failed native build still looks like a successful install

The install behaviour is what makes the previous point dangerous. The native modules are declared optional, and the install command does not fail when they cannot build. If the build fails you get a warning during install, with a build toolchain error as the example, and then the install carries on to completion. So the failure signal a user is looking for, a non-zero exit, never arrives. The mitigation offered is a health command rather than an install-time check:

```bash
aqe health
# Look for "HNSW backend: native" or "HNSW backend: js"
```

That output string is the contract to test in your own setup, because it is the difference between logarithmic search and a linear scan, and it is the difference between a tool that scales with your repository and one that quietly becomes slower every time the repository grows. Linux and macOS users are told there is no extra setup required and the native binary compiles out of the box, which means this entire class of problem is a Windows-specific tax and worth budgeting for separately. The pattern store and graph dependencies have the same optional-module treatment, so on Windows it is worth reading the whole health output rather than only the one line. The design choice underneath is defensible even though the failure is awkward to detect. An optional dependency is the right declaration when a feature degrades gracefully, because a hard install failure on a machine that only wanted test generation would be worse than a slow one. So the install is allowed to succeed and the fallback is genuinely correct, and what is left to do is documentation. That documentation is unusually thorough about the failure mode, which is the part that makes this acceptable rather than merely defensible.

## Visual Studio 2026 detection needs an npm that Node does not ship

The Windows prerequisites section has a detail that will cost an afternoon if you hit it. To get the native module to compile you need Python on the path and a C++ desktop development workload, from either Visual Studio 2022 Build Tools or Visual Studio 2026. The 2022 route works with any version of the native build wrapper and is the low-risk choice. The 2026 route needs more: detection requires a recent npm and a recent build wrapper version, and those are not what Node 22 LTS installs by default, because Node 22 LTS still bundles an older npm line that cannot detect Visual Studio 2026 at all. So the documented workarounds are to upgrade npm globally or to use the 2022 build tools instead. The pattern is the thing worth internalising rather than the version numbers. The toolchain that compiles a native module is itself versioned, and the version that compiles it may not be the version your runtime detected as your compiler, which means a working compiler and a failing install are entirely compatible.

## Two install routes with very different scope

The project offers a full initialisation and a slimmer plugin, and the comparison table between them is the decision. Setup is one slash command for the plugin against a full project initialisation for the other. Scope is eleven agents and nine skills against sixty agents and eighty-six skills. The persistent learning database differs in a way that matters: the plugin has none of its own and uses the one belonging to the MCP server, while the full setup writes a database inside the project directory, which means the learning survives independently of any session. Cross-platform support is Claude Code only against eleven platforms including Cursor, Copilot and Cline. And the stated use case is a quick start on a single Claude Code project against a production team setup with the full fleet. The two can be run together, and they share the same underlying package, so the plugin is a scoped front end rather than a separate product. Choose on whether you want the learning to be a property of your repository or a property of your agent session.

## The plugin ships no untested skills, by policy

Nine skills ship in the plugin and there is a rule behind them. Every one is at trust tier two or three, described as validated or verified, and tier-one untested skills are excluded per policy. That is an unusual thing for a plugin to say about itself, because it means the count is deliberately lower than it could be. Eleven agents, nine slash commands, nine skills and one MCP server is what you install, and the MCP server registers itself through a one-off package invocation rather than requiring a separate configuration step, which removes the most common reason a plugin appears to install and then do nothing. The agent names also tell you what the scope is: test architecture, coverage, flaky test hunting, chaos engineering, a fleet commander, a quality gate, security scanning, performance testing, regression analysis, a TDD specialist and a requirements validator. The slash commands map onto the same ground with status, cost and benchmark reporting included, which suggests the tool expects to be asked how it is doing as well as what it should do.

## Agents are routed by model tier, and the routing is an export

The plugin splits its eleven agents across two models rather than running them all on one. Six are routed to the heavier reasoning model and five to the faster execution model, on the stated split of heavy reasoning against focused execution. That is a cost decision made at the design level rather than as a configuration option, and it pairs with the broader claim that the full fleet routes tasks to the right model tier, fast and cheap for simple work and powerful for complex work. The package manifest shows how seriously that is taken, since model routing is not buried in the main entry point: alongside the package root there are separate exported entry points for the routing subtrees, a free-tier router and a value-score module, plus dedicated entry points for the search kernel, an adapter for it, shared code, a shared large-model layer, the command line, the vector store wrappers, sync, governance and an adversarial verification path. Coverage analysis is described in the package description as sublinear, and a dedicated kernel export with its own adapter is the shape you would expect if the search layer is meant to be replaceable.

## The container runs as a non-root user with a real health check

The container image is unremarkable in the way a mature project's should be, and one detail in particular is worth reading. The build is multi-stage on a current Node Alpine base, production dependencies only in the final stage, and the running image creates a dedicated non-root user and switches to it before starting the process. It copies the configuration in, creates its data and log directories, and fixes ownership and permissions explicitly rather than relying on what the base image happened to set. It exposes one port and defines a health check that polls an HTTP health endpoint on a thirty second interval with a three second timeout, a five second start period and three retries, exiting on whether the status code is two hundred. That health check is what a container orchestrator will use, so it is doing real work rather than being decorative. The start command runs the command line entry in daemon mode. Given the fallback behaviour described earlier, it is worth noting what this health endpoint does not cover: a passing health check says the process is up, not that the optional native modules loaded.

## The config file expects four backing services behind one flag

The example environment file is the best inventory of what the tool actually needs at runtime, and it is longer than the feature list suggests. On the model side there are two primary provider keys and three commented-out alternates, with a provider selector that accepts an automatic mode plus several named providers, and a mode selector offering a hybrid router, cloud-only or local-only. Underneath that sits a self-learning layer: an enabled flag, a service URL for its HTTP interface, and a full PostgreSQL connection block for its vector storage, which means the learning feature is not local-only. Then a pattern store with four separate switches, including a dual-write switch and a path pointing at a single file on disk, plus automatic sync. Then code intelligence: a local model server URL for embeddings and a PostgreSQL connection for the knowledge graph, with a note that it can share the vector store's database. That is four services you may need to run. If you only want test generation, most of this file is inert, which is the practical way to read it. One setting is worth calling out because it is the mechanism behind the learning claim: the pattern store carries a dual-write switch and an automatic sync switch, so learned patterns are written both to the local file and to the vector store, and reconciled automatically. That is what lets the README say remembered patterns are reused across sessions and projects rather than only within one run, and it is also why the vector store is on the critical path for that feature even though nothing else needs it. The top level of the repository matches the configuration: a per-project state directory, agent configuration directories for several runtimes, a harness directory, benchmarks, a schemas directory, verification assets, fixtures, examples, reports and a development container definition.

## Conclusion

Use it if your test suite is large enough that writing coverage by hand is the bottleneck, because the parts that are genuinely hard to do manually are the coverage gap prioritisation, the flaky test root cause analysis and the pattern learning that persists across sessions. Two things to check before you adopt it. Which search backend you actually got, because on Windows a native module that will not compile produces a node-gyp warning, a successful install and a linear fallback, and the health command is the only way to tell. And which install route you want, since the Claude Code plugin is a scoped eleven-agent subset while the full initialisation gives you sixty agents and its own persistent learning database, and they are not the same product. Also read the model routing before you enable it at scale, since the cost saving depends on the tiers behaving the way you assume.

## FAQ

### what is agentic qe

An open source quality engineering fleet of AI agents built for coding agents, generated by installing the package globally and running an automatic project initialisation. It generates tests across several styles and output frameworks, finds and prioritises coverage gaps, detects flaky tests with root cause analysis, learns codebase patterns across sessions, and coordinates sixty specialised agents under a central coordinator.

### How do I install Agentic QE Fleet?

Install the package globally, change into your project and run the automatic initialisation, which detects your tech stack and configures the MCP server. On Claude Code the tools are then available immediately; other clients use the separate MCP entry point. A slimmer Claude Code plugin can alternatively be installed from a local checkout or from the plugin marketplace.

### Why does Agentic QE work differently on Windows?

Its performance-oriented native dependencies ship as optional modules, and the HNSW search module in particular has no prebuilt binaries and compiles from source. If it fails to build the install still completes and the tool falls back to a JavaScript implementation that is correct but degrades to linear-time search on large indexes. Linux and macOS compile out of the box.

### How do I tell which search backend Agentic QE is using?

Run the health command and read the backend line. It reports the native backend or the JavaScript one, and the latter is the one that degrades to brute-force search. This matters because a failed native build produces a build warning during install but does not fail the install, so the health output is the only reliable signal.

### What is the difference between the Claude Code plugin and the full init?

The plugin is a scoped subset: eleven agents, nine slash commands and nine skills, no persistent learning database of its own, and Claude Code only. The full initialisation gives sixty agents, eighty-six skills, its own persistent learning database inside the project, and support for eleven coding agent platforms. Both can be run together since they use the same package.

## Sources

- [License: MIT](https://github.com/proffesor-for-testing/agentic-qe/blob/main/LICENSE)
- [proffesor-for-testing/agentic-qe on GitHub](https://github.com/proffesor-for-testing/agentic-qe)
- [Project website](https://agentic-qe.dev/)
- [README](https://github.com/proffesor-for-testing/agentic-qe/blob/main/README.md)
- [Releases](https://github.com/proffesor-for-testing/agentic-qe/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/proffesor-for-testing-agentic-qe