Begin with a moment, not a feature request
A customer says, "I submit a request and then I cannot tell whether anyone saw it." A weak handoff turns that into "add a status filter." A stronger loop keeps the original moment visible while the product owner and team ask what the customer actually needs: confirmation, confidence, a way to correct missing information, or a reliable expectation about what happens next. The work item should carry that interpretation forward so the agent does not optimize a shorthand that has already lost the point.
In ScrumDo, evidence can arrive through an intake form that creates a card, an anonymous story invitation that remains a signal until a team promotes it, or an invited customer account that lets the customer create and track only their own cards. The path changes visibility and follow-up, but the principle stays the same: preserve the story and its interpretation before translating it into work.
The seven recorded states of the loop
| State | Primary actor | What becomes inspectable |
|---|---|---|
| 1. Evidence | Customer, team member, or product owner | Story, signifiers, source, consent, and visibility |
| 2. Proposed spec | Drafting agent | Draft language and the accepted sources used |
| 3. Accepted spec | Accountable human | Version, revisions, decisions, and unresolved questions |
| 4. Proposed plan | Execution agent | Steps, tools, connector calls, budget, and expected proof |
| 5. Approved run | Authorized human | Approval, exception, scope, and the exact plan approved |
| 6. QA and proof | QA agent plus human reviewer | Tests, findings, limitations, changed files, and risk decisions |
| 7. Pull request and outcome | Developer or code owner | Commit, pull request, review, merge status, and later customer outcome |
Draft the specification from stories and sensemaking
The agent can draft from the card, customer stories, storyteller interpretation, product-owner notes, team judgment, approved repository context, and other allowed evidence. The draft remains a proposal. The reviewer can comment, request revisions, compare versions, and accept a specific version. Later execution must target that accepted version, not whatever text happens to be visible after another edit.
Approve the plan before execution
The execution agent turns the accepted specification into a proposed plan. The reviewer sees the intended steps, repository or connector targets, tools, estimated usage, and required proof. If the target changes, the specification changes, or a required approval becomes stale, the run should stop and return for review rather than silently continue under an obsolete decision.
Run, verify, and return proof to the card
Execution occurs in an isolated environment using the approved context and tools. A QA agent evaluates the result against the accepted specification and proof profile. It records what passed, what failed, and what it could not verify. A person then decides whether to accept, request revision, accept a disclosed risk, or stop. For code work, the agent output can be committed and opened as a GitHub pull request so normal repository review and branch protections still apply.
Close the learning loop
A merged pull request is not the end of the work. The team returns to the customer or process signal and asks whether the experience changed. If confidence improved but another failure appeared, that evidence begins the next loop. This is why the architecture is a loop of loops: definition, execution, verification, and learning interact rather than forming one irreversible pipeline.
Key terms
- Accepted specification
- A specific, versioned statement of intended behavior approved by an accountable human.
- Proof profile
- The tests, artifacts, reviews, and limitations required before a result may be accepted.
- Loop of loops
- Connected definition, execution, verification, and learning loops that can return to one another as evidence changes.
Sources and standards context
- GitHub documentation on pull request reviewsGitHub documents comment, approval, request-changes, required-review, and traceable discussion patterns for proposed code changes.