Agentic QE Fleet: a 60-agent QA platform that plugs into your coding agent

What Agentic QE Fleet is for, and who ends up using it

The project targets a specific gap: a coding agent can write a test file, but it has no standing view of which untested paths matter, which tests fail intermittently, or what patterns the codebase has already established. Agentic QE Fleet supplies that view as a set of MCP tools. The README frames the product as "AI-powered quality engineering agents that generate tests, find coverage gaps, detect flaky tests, and learn your codebase patterns across 11 coding agent platforms."

The intended user is an engineer or QA lead who already drives an agent from a terminal or editor. The README says it works best with Claude Code and lists 11 supported coding agent platforms. Framework coverage is broad on paper: the README names Jest, Vitest, Playwright, Cypress, pytest, JUnit, Go, Rust, Swift and Flutter as output targets. That list is about what the agents can emit, not about which runners the project itself ships.

The honest boundary is that this is not a test runner. Nothing in the README describes replacing Jest or Playwright. It sits one layer above them, deciding what to generate and what to look at first, then handing files back to the runner you already have.

How the fleet works: coordinator, bounded contexts and a learning store

The package description in package.json is unusually explicit about architecture: "Domain-Driven Design Architecture with 13 Bounded Contexts, O(log n) coverage analysis, ReasoningBank learning, 60 specialized QE agents, mathematical Coherence verification, deep Claude Flow integration." That is the design claim, and the repository layout backs part of it: there is a src/ tree, a packages/ directory, a schemas/ directory, and a .ruvector/ directory at the top level.

Task flow is coordinator-first. The README states that 60 specialized QE agents are "orchestrated by a central coordinator," and that a routing layer "automatically routes tasks to the right model tier (fast/cheap for simple tasks, powerful for complex ones)." The exported entry points in package.json mirror that split: there are separate subpath exports for ./kernel, ./kernel/hnsw-adapter, ./routing/free-tier, ./routing/value-score, ./governance, ./sync and ./verification/adversarial-verify. Those names tell you the routing and verification concerns are not buried inside the agent prompts; they are modules with their own type definitions.

The learning half is the part most teams will care about. The README says remembered patterns "are reused across sessions and projects, improving with every interaction." Backing that is a pattern store configured through environment variables. The .env.example file declares AQE_PATTERN_STORE_ENABLED, AQE_PATTERN_DUAL_WRITE, AQE_PATTERN_STORE_PATH (defaulting to ./data/qe-patterns.ruvector) and AQE_PATTERN_AUTO_SYNC, alongside AQE_RUVECTOR_ENABLED and a RuVector service URL at http://localhost:8080. So the learning is not implicit in the model; it is a store on disk plus an optional HTTP service.

One caveat about that store: the README's comparison table lists the persistent learning DB as "No" for the plugin path. Learning is a property of the full aqe init setup, not of the slim plugin.

Installing agentic-qe and running a first real task

The README gives a three-step quick start. Install globally, initialise inside your project, then drive the tools from your coding agent. The init step is the one that does work on your behalf: the README says it auto-detects the tech stack and configures MCP.

npm install -g agentic-qe
cd your-project && aqe init --auto

After that, the README states that MCP tools are available immediately in Claude Code, and that other clients should be pointed at the aqe-mcp command. There is nothing else to wire up for the Claude Code path.

The first task is a plain-language request to your agent rather than a CLI invocation. The README gives these as example prompts:

"Generate tests for src/services/UserService.ts with 90% coverage target"
"Find coverage gaps in src/ and prioritize by risk"
"Run security scan on the authentication module"
"Analyze why tests in auth/ are flaky and suggest fixes"

If you would rather not run the full init, the README documents a plugin path. From a local checkout, clone the repository and point Claude Code at the plugin directory:

git clone https://github.com/proffesor-for-testing/agentic-qe.git
claude --plugin-dir ./agentic-qe/plugins/agentic-qe-fleet

Or install it from the marketplace inside a session with /plugin marketplace add proffesor-for-testing/agentic-qe followed by /plugin install agentic-qe-fleet. The README says the plugin bundles 11 agents, 9 slash commands, 9 skills and auto-registers the MCP server through npx -y agentic-qe@latest mcp, so no separate claude mcp add is needed. Slash commands listed in the README include /aqe-fleet-status, /aqe-generate and /aqe-analyze.

On Windows, do not skip the toolchain. The README warns that hnswlib-node has no prebuilt binaries and compiles from source via node-gyp, and that npm install does not fail when optional native modules cannot build. The suggested prerequisites are Python 3 on PATH plus Visual Studio 2022 Build Tools with the Desktop development with C++ workload, or Visual Studio 2026 with the same workload and an npm upgrade to at least 11.6.3. The README notes that Node 22 LTS still ships npm 10.x, which cannot detect VS 2026.

To confirm which code path you ended up on, the README points at one command:

aqe health
# Look for "HNSW backend: native" (hnswlib-node) or "HNSW backend: js"

The distinction matters, and the next section explains why.

The HNSW fallback is the sharpest limitation in the project

Most AI tooling degrades gracefully and quietly. This one degrades with a documented performance cliff. The README states that the pure-JavaScript HNSW fallback, ProgressiveHnswBackend, "is correct but degrades to O(N) brute-force search when neither hnswlib-node nor @ruvector/gnn is available," and then says plainly that this is "unsuitable for large indexes (tens of thousands of vectors and up)."

That is a real failure mode, not a theoretical one. The install succeeds, aqe health reports a working system, and search quality is unchanged. Only latency changes, and it changes with the size of your index. A small service will never notice. A monorepo with tens of thousands of embedded vectors will notice immediately, and the symptom will look like the agent being slow rather than like a missing native module.

The other constraint is the LLM dependency. The .env.example file expects an ANTHROPIC_API_KEY or an OPENROUTER_API_KEY, with optional keys for Groq, OpenAI and Google. LLM_PROVIDER defaults to auto and LLM_MODE to hybrid, and there is a ruvllm provider option listed in the comments. There is no documented mode where the agents run usefully with no provider configured at all.

Two more gaps are worth naming. The README does not document rollback or uninstall for aqe init, so the cleanup path after initialising a project is not described. And the README's own comparison table is truncated mid-cell in the persistent learning DB row for the plugin, so the plugin's storage behaviour beyond "No" is not spelled out.

Agentic QE Fleet versus a plain test-generation prompt

The obvious alternative is doing nothing: ask your coding agent to write tests, one file at a time. The difference is state. A bare prompt starts from zero every session. Agentic QE Fleet keeps a pattern store on disk and a routing layer that decides which model tier handles which task, and the README claims this reduces AI costs by sending simple work to cheaper models. Whether the routing saves more than the coordination costs is not something the README quantifies.

A second alternative is a conventional coverage tool. Istanbul or JaCoCo will tell you which lines are unexecuted, deterministically and for free. The difference in approach is ranking. The README describes coverage work as "risk-weighted analysis" that "identifies the most impactful untested code paths," which is a judgement call a line-counter cannot make. If you only need the raw percentage for a CI gate, the conventional tool is the better fit and has no API key requirement.

A third comparison is internal to the project: the plugin versus aqe init. The README's table puts the plugin at 11 agents and 9 skills against 60 agents and 86 skills for the full setup, with the plugin skipping the persistent learning database. The plugin installs with one slash command and skips project setup entirely. If you want the fleet, you want the full init; the plugin is a scoped subset, not a lighter version of the same thing.

Licence, releases and what upgrades cost you

The project is MIT licensed, per both the repository metadata and the README badge. For a tool that writes files into your repository and reads your source tree, MIT is about as unobstructed as it gets: fork it, vendor it, ship it inside a commercial product. That is a statement about the licence text, not advice about your situation; the usual review applies if your organisation treats third-party code as a compliance surface.

Maintenance looks current rather than dormant. The last push to main was on 2026-09-13, and the most recent release, v3.14.2, was published the same day, with v3.14.1 on 2026-09-07 and v3.14.0 on 2026-08-31. Three releases in roughly two weeks is a fast cadence, and fast cadences have a cost: the CHANGELOG.md and docs/releases/README.md are the files to read before upgrading, not after.

The upgrade surface is wider than a typical CLI. The package exposes subpath exports for the kernel, the HNSW adapter, shared LLM code, sync, governance, routing and adversarial verification, so anything importing those paths is coupled to internal module shapes rather than to a stable public API. There is also a Dockerfile that builds on node:24-alpine, runs as a non-root user, exposes port 3000 and starts with node dist/cli/index.js start --daemon, with a healthcheck hitting http://localhost:3000/health. If you deploy that way, the image tag is your version pin.

Editorial conclusion

Adopt it if your team already works inside Claude Code or another MCP-capable coding agent and wants test generation, coverage-gap ranking and flaky-test triage driven from the same session. Do not adopt it if you need a GUI test runner, if you cannot supply an LLM API key, or if you plan to index a large codebase on Windows without a C++ build toolchain. Verify three things first: the output of aqe health on your machine, whether the HNSW backend reads native or js, and which of the two install paths (aqe init or the agentic-qe-fleet plugin) matches the number of agents you actually need.

Frequently asked questions

Official sources

1. License: MIT
2. proffesor-for-testing/agentic-qe on GitHub
3. Project website
4. README
5. Releases