---
title: "QA architecture for an agent-driven software factory"
description: "Design a software factory QA loop with explicit acceptance criteria, stable test fixtures, a dedicated execution runtime and reviewable release evidence."
canonical_url: "https://vostride.com/agent-library/software-factory/qa-architecture-for-a-software-factory.md"
md_url: "https://vostride.com/agent-library/software-factory/qa-architecture-for-a-software-factory.md"
content_kind: "guide"
topic: "software-factory"
---

# QA architecture for an agent-driven software factory

A useful software factory QA loop starts with the behavior a change must preserve. The coding agent implements that change; a test runtime exercises the resulting application; a reviewer or release policy decides whether the evidence meets the acceptance criteria. agent-qa can supply the natural-language end-to-end execution part of this design.

## Define the verification contract

Record the application revision, target environment, test-owned identities, relevant feature flags and expected outcomes before running a test. For an invitation change, “the page loads” is weaker than “the invited identity can enter the intended workspace, while a different identity cannot accept the same invitation.” Select a recipe from the [membership topic](/agent-library/organization-membership.md) and adapt that distinction to the product's rules.

Keep fast checks for pure logic and service behavior alongside real-interface tests. Choose the layer that can observe the requirement directly. A screenshot can show a confirmation state; an application-specific hook may be needed to establish that exactly one membership record exists.

## Connect the stages

1. Start the application and its dependencies with a known fixture revision.
2. Ask the coding agent to inspect the approved contract and existing tests.
3. Author or reuse an agent-qa test with a configured target and explicit assertions.
4. Validate its configuration, execute it, and retain the run identifier.
5. Inspect the completed steps and supporting artifacts, then compare the observed outcome with the contract.
6. Repair a failed implementation or faulty test only with evidence, and preserve both the original failure and rerun result.

The [coding-agent workflow](/docs/agent-qa/guides/coding-agent-workflow.md) documents the CLI and local MCP paths. The public documentation MCP retrieves content; it does not run the application.

## Decide what persists

Review tests and shared configuration with the code. Keep relevant application memory under the team's review process, and retain execution artifacts according to the project's needs. Do not treat a separate runtime as automatic independence: an agent allowed to edit both code and assertions can still weaken the verification contract.

## Next steps

- [Turn a recipe into a test](/agent-library/software-factory/turn-a-recipe-into-an-agent-qa-test.md)
- [Choose the testing layer](/agent-library/software-factory/choose-the-testing-layer.md)
- [agent-qa setup](/docs/agent-qa/agent-quickstart.md)