Test management for AI coding agents: the shared quality layer

Verification is the new bottleneck

AI coding agents write code and tests faster than anyone can review them. They don't know what "safe to ship" means for your product: what's covered, which requirements exist, what failed before, and what standards your team holds. Each agent works to its own defaults, in its own session, with no memory of the others.

Classic test management grew up around handoffs: work passed between roles, with plans, gates, and sign-offs to coordinate it. Agents collapse those handoffs. What's left is the part that always mattered: deciding what "good" means and verifying it.

An agent can generate a test case. It can't know whether the feature is already covered, whether the case duplicates five others, or which requirement it maps to. Qase is not another coding agent. It is the shared quality layer agents work through to access project context and verify their work under consistent controls.

AI made generating code and tests cheap. Verifying them is now the bottleneck. Qase gives every agent the same quality context and a governed way to verify work against it. MCP connects the agents, the harness (the rules QA owns) governs them, verification loops put your context to work, and the quality graph is where this is heading.

The cost of fragmented verification

Running several AI tools without a shared verification layer creates three problems:

• Inconsistent standards. Each agent writes cases to a different standard: vague steps, missing assertions, missing requirement links. The same suite ends up uneven.
• Coverage that only looks real. Duplicate and shallow cases raise the count while leaving real gaps. The gaps show up later as escaped defects.
• Late checks. Checks that happen only in code review or CI come after the agent has moved on, when fixes cost more.

This build-up of unverified, AI-generated cases is verification debt: cases enter your suites faster than anyone can validate them.

When change volume outruns verification, a team has three options: slow the agents down, lower the bar, or scale verification. The first two give up the point of agents; Qase exists to make the third one cheap.

Agents already work through Qase

Qase connects through one integration, the official Qase MCP (Model Context Protocol) Server. Any MCP-compatible agent talks to your Qase project the same way. One setup covers the tools your developers already use and extends to new ones as they appear. It works today with clients such as Claude Code and Cursor, and the same server can also receive results from CI pipelines.

Most calls are writes: agents creating and updating cases, not just reading them.

Inside the quality layer

The quality layer has two parts. The core is context: your suites, cases, runs, results, defects, requirements, and history. Around it sit the rules: permissions, quality gates, skills, and hooks that govern what's allowed. Agents act through the rules; their work is checked and reviewed before it reaches the product.

Why the agent stays thin

A concrete example: the same request, "draft cases for this feature", can come from Claude Code today and Cursor tomorrow. The agent's only job is to translate that intent into Qase actions. Everything that has to stay consistent (the rules, the data, the approvals) lives in Qase, so swapping one agent for another changes nothing about quality. That's the split:

Qase MCP Server

The toolset agents use to talk to Qase. From a natural-language prompt, without leaving the editor, an agent can read suites, cases, runs, results, and defects. It can create and update cases inside your structure, record run results from CI or an engineer's machine, search with Qase Query Language (QQL), and file defects. All actions inherit the project's permissions and approvals. The toolset itself is built for agents: task-oriented tools (the first version had a tool per endpoint) and a single call that loads the whole project context.

You define the bar; Qase holds it

Qase doesn't decide what a good test case is. Your team does. What Qase adds is a place where that decision lives in machine-readable form, so every agent is held to it. For most teams the hard part isn't the tooling; it's writing the bar down at all, because today it lives in review comments and heads. Required fields define what a complete case contains; guideline files describe how cases should read; a saved QQL query turns a rule into a runnable check ("cases with no requirement link"); the approval workflow names who accepts the result. Anything smarter than these rules (duplicate detection, judging assertion quality) is logic you compose from the same pieces today.

Test cases are spec-driven development in natural language

Agents work from your real test cases, not a generic template: the suites, fields, statuses, and requirement links your team already uses. New cases match how the project is organized, which keeps them readable and easy to review.

A test case is a natural-language spec: steps and expected results describe how the product should behave, independent of how it's implemented. Spec-driven development is arriving in coding agents; QA teams have practiced it for years. As AI makes structure cheap to produce, the industry's attention is shifting to behavior, and behavior is what a test suite describes. In an agentic workflow the suite becomes the living spec agents verify against and translate into executable checks where automation exists.

Skills and plugins

Skills package a workflow so an agent runs it the same way every time. Each one installs once and is invoked as a command on a branch. A plugin bundles skills with the Qase connection, so one install hands the team the whole job. Skills guide; hooks enforce. A hook is a deterministic checkpoint that fires at a fixed moment (before a risky write, before a merge) whether or not the agent thinks to run it. That makes approval gates dependable, not optional.

Coding agents are getting verification loops of their own: repo-local checks encoded as skills that run on every change. That's the right direction, and it stays local. Qase skills plug those same loops into the project's quality bar (requirements, cases, history) and record what they find where the whole team can see it.

One packaged example is Quality Supervisor, a plugin. Its impact-analysis skill serves the engineer and shows the approach working end to end: run /impact-analysis on a branch and it reads the ticket requirements, the existing test cases, and the diff, then reports back what the change affected and what to check before review.

The plugin's other workflows serve the QA lead: coverage gap analysis, failure triage, flakiness scoring, and release readiness. Every finding shows the QQL query behind it, so it can be verified rather than trusted. Qase stays the system of record; the plugin analyzes and drafts, and bulk writes wait for a person.

In practice: verifying a feature

A common flow shows where each piece fits and where the responsibility stays with people.

1. The engineer gets manual steps. When an engineer finishes a feature, the agent in their coding tool suggests the manual steps to verify it: the actions to walk through and the results to expect. The steps anchor to the ticket requirements and existing cases, not to the diff alone: the diff says where to look, never what correct looks like.
2. Steps become cases in your structure. The same coding agent files the steps into Qase over MCP as proper test cases, following your conventions: the right suite, step format, fields, statuses, and requirement links. They arrive as reviewable cases.
3. The engineer verifies the feature. The engineer runs the cases before handing off, so basic problems are caught before code review.
4. QA decides what to keep. The cases land in Qase, where QA decides what each one is worth: keep it as a manual case, drop a duplicate, merge or refine it, or mark it for automation. Agents can open these reviews through the API; approving and merging stay with a person in the UI.

QA then acts as the quality architect: deciding what stays manual, what gets automated, which corner cases don't deserve an end-to-end test at all, and how the suite is structured. Engineers verify faster, and QA gets reviewable drafts without the suite losing its shape.

Going further: run the test, not just suggest it

Where a team already has automated tests or a framework in the repo, an agent can use them as a reference to generate a runnable spec, execute it, and report back. The engineer sees whether the feature works without walking the steps by hand. What returns to Qase is a draft case plus an execution result linked to the branch or PR: a candidate for QA to review, not an automatic addition to the suite. What's not shipped yet: a packaged skill for this flow, scheduled autorun, and self-healing that fixes a spec when the product changes.

The harness around the loop

Teams increasingly run agents in loops: instead of a human babysitting each turn, an agent repeats cycles of work (triage, migrations, dependency bumps, generating or fixing tests) until it hits a stop condition. The hard part is deciding what to check, when the work is done, and who owns the result. If nobody checks the loop's output, its mistakes ship too. Tell an agent to make the tests pass, and it may just weaken the tests until they do. So verification stays the job.

The more you can verify cheaply, the more autonomy you can safely hand off. Autonomy is a dial you set per task, not a single on/off switch. Raising it takes a standing contract: scope, a stop condition, evidence, an escalation path, a budget. That contract is the harness at work; it lives in your rules, not in someone's approval queue. The parts below are how Qase supplies it.

• Risk focus: what to check. The workflow ranks the areas a change may put at risk so the loop can focus there. The question shifts from "did every test run" to "did the right tests run". The impact-analysis skill is an early version.
• Routing: who fixes it. Planned. Not every defect goes to an agent. The workflow estimates effort and risk before assigning work; changes that touch architecture, security, or multiple systems go to a developer.
• A verifier and stop condition: when it's done. Today, teams compose pass/fail logic from Qase's checks and gates. A second agent's review is another roll of the same dice; a gate has to be deterministic to be a gate. Planned two-stage verification and confidence thresholds will turn that pass/fail into a standard machine-readable stop condition for agent loops. Review capacity is a stop condition too: if approvals can't keep pace, the harness should slow the loop until they catch up, instead of letting verification debt pile up.
• Ownership and audit: who stands behind it. An audit trail records what the loop did, so a person still owns the result rather than rubber-stamping it.

The loop provides speed; Qase provides the context, controls, and auditability to hand off more of it safely. The more of the loop you hand off (the trigger, the stop condition, the prompt itself), the more its decision criteria must live in rules QA owns.

A recurring QA triage agent. Some quality work doesn't need a person in the loop; it needs a loop. Today, teams can compose one as a scheduled prompt against the Qase MCP Server. It sweeps the project for signals QQL can surface: tests already flagged as flaky, repeated run failures, stale cases, cases with missing requirement links. Based on the configured workflow, it files or updates the relevant cases and defects; composite MCP tools do this in one action. Caps and deduplication keep it from flooding the team. No bot infrastructure required.

Roles: QA owns the harness

The quality system is a harness: the standards agents follow, the checks cases must pass, the policies and approvals that govern what ships. QA owns and evolves that harness. Engineers and agents operate inside it. The value of a harness is not what it adds on top of the model, but what it doesn't get in the way of.

Engineers and agents run the inner loop of building and checking; QA owns the outer loop of deciding what counts and carrying the consequences. Hooks tie the two loops together: the inner loop pulls context in at the start and writes evidence out at the end, so the outer loop has something real to judge. Planned confidence thresholds will move more routine decisions into that system.

None of this is new doctrine. Quality was never something you could inspect into a product at the end, and the shift from Quality Assurance to Quality Engineering has been underway for years. Agents raised the price of that discipline: the cheaper a plausible case is to generate, the more valuable the system that decides whether it counts.

What this means for your team

• Earlier verification. Agents draft and check against your context while the code is fresh, so more is caught before review instead of piling up as debt. The number of tests matters less than how fast the team reaches confidence.
• One standard across tools. Whichever MCP-compatible agent a developer uses, it works against one project and one set of rules.
• Governance by design. Role-based access, audit trails, and approval workflows apply to agent-driven changes, so QA governs through rules and reviews, not by hand-checking every case. An agent acts on behalf of a specific person with that person's permissions, not as a shared "AI" account, so every action has a real owner.
• Measurable agent behavior. Qase already records agent-driven changes in its audit trail. Planned agent traces will add what data a run read, which tools it called, what it cost, and which policies fired. Traces can then be checked against a fixed set of golden tasks, the way regression tests protect an API.

Where this is going: the quality graph

Planned. Everything above is the near term. The bigger bet takes longer: Qase already has the building blocks, but today they're optimized for humans. The roadmap has four parts:

• Agent-readable context. Structured output, errors an agent can act on, stable references for every entity, and a single investigation bundle per failure instead of dozens of calls. The project-context call already does this for project structure; failures and project conventions are next.
• Trusted evidence. Every entity carries provenance: agent-drafted or human-verified. Results carry execution evidence such as CI build IDs, logs, and artifacts. Text in cases and defects is treated as data, never as instruction. A "passed" written by the agent that made the fix remains a claim until evidence verifies it.
• Risk-aware verification. A risk register links criticality, failure cost, and lifecycle stage to suites and components. That turns "what did the change touch" into "what would a failure here cost". Event-driven checks and confidence thresholds use it to trigger verification and route low-risk approvals.
• A learning system. Every keep, merge, or drop decision QA makes is labeled data. That data calibrates the checks to what your team considers good and backtests them against escaped defects. Using it is explicit and opt-in.

Qase already holds the core of the quality graph: the relationships between cases, executions, defects, requirements, history, and artifacts. That graph lets an agent reason about quality rather than just read a result. Because the record lives in Qase, teams can swap coding agents without losing it. And the record itself isn't captive: everything in it is reachable over the same API the agents use.

AI didn't replace the systems of record in observability; it learned to operate on top of them. Quality is heading the same way: a shared graph that connects the tools teams already use and carries evidence, decisions, and ownership across them.

Getting started

Qase connects to the AI tools your developers already use; the setup guides show how. From the first prompt, agents work against your existing quality context.