Build Loops with Hypothesis, MVP, Validation, and Feedback
Use this four-part design loop before you automate: state the hypothesis, run the smallest useful version, collect validation evidence, then decide what to change before the next pass.
Why it matters
Agent workflows become risky when teams try to design the perfect system before seeing a real run. A small loop makes the risk visible early: the discovery source may be weak, the checker may be vague, or the stop rule may be too soft. That is useful information, not failure.
The four-part design loop
| Part | Question | Good answer |
|---|---|---|
| Hypothesis | What are we trying to learn? | This small loop can safely fix one reproducible CI failure |
| MVP | What is the smallest useful run? | One pass on the latest failed job |
| Validation | What evidence proves it worked? | Same failure passes, full checks pass, no shortcuts |
| Feedback | What changes next time? | Tighten boundaries, improve checker, or stop |
Before you run
- 01Can the hypothesis be false?If not, rewrite it
- 02Can the first run stay small?If not, narrow the source
- 03Can validation be observed?If not, add evidence
- 04Can feedback change the next run?If not, it is not a loop yet
Practical checklist
- Write one testable hypothesis before the loop runs
- Choose the smallest useful run that could prove or disprove it
- Name the evidence that counts as validation
- Record actual evidence after the run
- Decide whether to stop, adjust, or schedule the next pass
- Do not expand scope during the validation run
Example
Hypothesis: a CI loop can fix one failing test safely. MVP: run it once against the newest failed job. Validation: failing test passes, full suite is green, no tests are deleted. Feedback: if the loop touched unrelated files, tighten the boundaries before another run.
Common failure modes
Related templates
FAQ
It is related. Here it is adapted for agent loops: build the smallest useful loop, measure the evidence, learn what to change before the agent repeats.