Azure DevOps is where generated test cases have to land, and it is also the system where an unreviewed write does the most damage. The integration is shaped around that: a read path that runs freely, a write path that cannot execute without a human approving a rendered diff, and a credential the execution sandbox never sees.
This is a deployment playbook for connecting an agentic system to Azure DevOps as the system of record for verification work. It covers the tool split, the authentication path, the approval gate, and the two operations that need special handling.
From the standard
“Verification and validation (V&V) processes are used to determine whether the development products of a given activity conform to the requirements of that activity and whether the product satisfies its intended use and user needs.”
Split the tools by consequence, not by resource
The instinct is to model the connector on the API surface: one tool per endpoint. The useful split is by what happens if the call is wrong.
| Class | Operations | Gate |
|---|---|---|
| read | Query work items · fetch test plan or suite · list fields and states | Policy check only |
| write | Create work item · update work item · link requirement to test | Policy and human gate. Blast-radius diff shown before commit. |
| trigger | Run pipeline | Policy and human gate, marked non-idempotent. |
Reads are the overwhelming majority of calls and gating them would make the system unusable without reducing risk — a read inside the acting user's existing permissions is not the thing the gate exists for. Writes and pipeline triggers are rare and consequential, which is exactly the shape that tolerates a human in the path.
Authentication: the token stays outside the sandbox
OAuth 2.0 client credentials, scoped to the project and the work item types the agent is permitted to touch. Scope it narrowly — a token that can edit any work item in the organisation gives the blast-radius calculation nothing to bound.
The credential is never placed inside the execution sandbox. The outbound request leaves the sandbox and the token is attached after it does. This matters more here than in a typical integration: agent-generated code is code nobody reviewed before it ran, so anything readable from inside that sandbox should be treated as already disclosed.
The review queue is the product
Generated cases do not go to Azure DevOps. They go to a queue, where each one is displayed beside the source requirement it came from and the signals it was matched against. A reviewer approves, edits, or rejects. Only an approved case is written.
Filter before the queue, not after
A grounding check runs ahead of the reviewer and rejects any generated case referencing a signal absent from the index. This is not redundant with human review — it protects it. A reviewer shown mostly-correct output learns to skim, and every ungrounded item that reaches the queue degrades the quality of review applied to everything else in it. Reviewer attention is the scarce resource in the whole system.
Two operations that need special handling
Pipeline triggers are not idempotent
Most connector operations can be retried safely after a timeout. Triggering a build cannot. A retry that assumes the first call failed, when it actually succeeded and the response was lost, runs the pipeline twice — and in a verification context a duplicate run against a shared environment is not a harmless duplicate.
Mark the operation non-idempotent in the manifest. The retry guard then blocks rather than retries: a read that times out is retried, a non-idempotent write that times out is surfaced to a human. Where the API accepts one, generate an idempotency key at approval time so a genuine retry is safe.
Production projects need their own gate
The same connector pointed at a sandbox project and a production project should not behave the same way. An environment-level override tightens the policy for production regardless of what the tool-level rules say, so relaxing a rule during development cannot silently relax it everywhere.
Approvals expire against a changing work item
An approval is granted against a specific state. Between approval and execution, someone else may edit the work item, a field definition may change, or the test plan may be restructured. Pin the approval to a version token and to the schema it was granted against; if either moves, refuse the write rather than applying it to a state nobody reviewed.
Refused, not silently retried against the new state. Azure DevOps work items are edited by many people, which makes this failure ordinary rather than exotic.
What this shape gives up
Throughput. A human sits in the path of every write, and that is a ceiling no amount of model improvement raises. In a regulated verification context it is the right ceiling: the count of unreviewed writes into the test plan is zero by construction rather than by policy, because the capability does not exist.
Where the work items are low-stakes and volume matters more than reversibility, this is over-built and a narrower blast radius with unattended execution is the better trade. The question to settle first is not how much you trust the generation step. It is what the worst single write could do before anyone noticed.
Axionalytics
Production agentic AI for enterprise engineering, data, and revenue teams.