How the agents work

Each ticket is worked by a team of agents — PM, Architect, Test Author, Developer, QA, DevOps — inside an isolated workspace. It's easy to treat that as a black box, but the workflow is built around a few guarantees that make the output reviewable and hard to quietly derail. Each one leaves a trace you can read in a record's Artifacts section (PRD, design, QA report), so you can verify them rather than take them on faith.

The whole ticket is read — comments included

A ticket's real intent often lives in its comment thread, not the original description — "actually, do X instead", "scope dropped Y". The planning phase weighs the full discussion, and when description and thread disagree, the discussion's outcome wins. The PRD lists every direction adjustment it took from the comments, each citing the comment that drove it — so you can check the agent's reading of the thread against your own.

Scope is locked after planning

Once requirements and acceptance criteria are set in the PRD, downstream phases build on them but can't redefine them. This prevents the classic failure where scope quietly mutates between planning and implementation: if the work genuinely needs different scope, that shows up as a visible flag, never a silent drift.

Tests come before code

Tests mapping to the acceptance criteria are written — and confirmed failing — before implementation starts. The implementation then has to make those pre-existing tests pass. So "the tests pass" means "the acceptance criteria are met", not "the agent wrote tests that happen to agree with whatever it built".

Every requirement is traceable

Each acceptance criterion gets an ID (e.g. AC-1234.1) that threads through the whole run: the tests reference it, and the QA review verifies each criterion by ID. You can follow any single requirement from the PRD → its test → its QA check, instead of trusting a vague "looks good".

Uncertainty is flagged, not papered over

The agents surface what they're unsure about instead of guessing silently. In the PRD you'll see:

• [ASSUMPTION] — a decision made on your behalf that's worth confirming.
• [INFERRED] — a requirement deduced from context that the ticket didn't state outright.
• [CONFLICT] — an unresolved contradiction (often from the comment thread) deliberately left for you to decide.

Treat these as the agents' review checklist for you. A PRD with a [CONFLICT] is the system telling you it needs a human decision before the work should be trusted.