Agent Assurance for
your AI Deployment

Yes. It does not pin the execution path, which is what makes conventional tests flaky against agents. It grades criteria against evidence instead, and reports flakiness as its own category, separate from regression, because the two call for opposite responses.

It invokes your agent the way a user would, so the agent's writes are real and cannot be rolled back. In an attended terminal it tells you how many write tools the agent declares and asks once, and grants are per target. Headless runs have nobody to ask, so they refuse unless you authorise the exact rule up front in your CI configuration or your coding-agent session: rehearse a run locally, then carry the rule you reviewed into the pipeline. Judges are instructed to verify without changing anything. Point it at staging.

Agents that act: coding agents, workflow agents, back-office agents, and anything else that calls tools, writes files, or hits APIs. If your agent talks to a human instead, through chat, voice, phone, or image, that is the job of conversational agent testing, which grades the reply rather than the effect. It is framework-agnostic, so it works the same way across the common LLM agent frameworks.

Yes. Agent Assurance invokes whatever you can point it at, and an n8n agent is normally reachable over an HTTP webhook, so you add it as an HTTP invoke profile and confirm the fields it parsed. An n8n agent is a good fit for the autonomous case, because it acts through tool and API nodes: the run is graded on what those nodes actually did to your data, rather than on the workflow's own summary of the execution.

Yes, and there are published recipes for GitHub Actions, Jenkins, and Argo CD. Run the headless subcommands and read the JSON report in two steps: first confirm the run finished and covered the scenarios you selected, then read the per-criterion verdicts. A finished run exits 0 whether its scenarios passed or failed, so the exit code never tells you what the agent did; exit 1 just means the command itself failed. Still treat a non-zero exit as a failed step. How strict the gate is beyond that remains your call. The shipped platform recipes are deliberately strict and block on missing evidence as well as on failures; what the product never does is quietly relabel something it could not verify as a failure of your agent.

No. Models run in the TestMu AI controller, so no provider keys sit on your laptop or your CI runner. What a run produces is written into your project as plain files you can commit, and a normal run also publishes to the hosted timeline so your team can open the same result; a test run is the documented way to keep an experiment local. Credentials are kept outside the project, so a stray git add cannot sweep them into a commit.

A TestMu AI account for credits, and whatever your agent itself needs to run. The CLI is public: install it with brew install lambdatest/rook/rook, the checksum-verifying shell installer, or npm install -g @testmuai/rook. The Homebrew and shell packages carry their own Node runtime, so only the npm route needs Node on your machine, and that route needs Node 22 or newer. It runs on macOS and Linux, on arm64 and x64, and on 64-bit Windows through npm or WSL. You do not need Docker, a cluster, or the rook source. Full detail is in the install guide.

Yes, and for most people that is now the shortest path in. The Rook skill teaches a coding assistant the whole workflow, so instead of learning the commands you describe the testing goal in your own words and approve what it proposes. npx @testmuai/rook-skill installs it for Claude Code, Codex CLI, and Gemini CLI in one go, and it needs Node 22 or newer. GitHub Copilot CLI, Cursor CLI, OpenCode, Windsurf, VS Code, and Antigravity each have their own setup page. The skill is not the CLI and not an MCP server, so install the CLI separately, and keep approving the real actions and the credit spend yourself. See using Rook with coding agents.

Both. A local viewer serves the run straight off disk in your browser with no sign-in and no upload, which is what you want while you are still working. A hosted view holds the history your team shares, with versions, scenario filters, trends, and insights across runs. Both are read-only, so opening either one never invokes your agent or publishes anything you have not published yourself.

Same evidence philosophy, different subject. Kane CLI is a browser agent that proves your application's UI works, and KaneAI authors tests for applications in natural language. Agent Assurance proves the agent itself works.

You do not have to wait to try it. The CLI is pre-alpha, which means the commands and the stored file formats can still move, but the builds are published and the install is public: install it, sign in, and run a suite today. Follow the quickstart, which walks the whole thing through against a sample agent so nothing real is at stake on your first run. Join the waitlist from any section on this page if you would rather we got in touch and worked through your agent with you. For chat, voice, and phone agents, agent testing is the separate product, and pricing covers the wider platform.