I let a multi-agent team build something for five days. It refused to call the result finished

I gave a multi-agent workflow an idea asked it to turn the idea into a validated, installable demo. I used oh-my-subagents, an open-source agent runtime I built to make orchestrating a persistent team much easier and feel closer to working with ordinary subagents. The team included customer and market researchers, a skeptical critic, a product strategist, UX and architecture owners, implementers, reviewers and a final verifier. Over nearly five days, it recorded 273 activity events and ran 64 managed build and test commands. The discovery stage finished quickly. The implementation stage did not. Reviewers repeatedly found issues that sent work back for repair. Some failures came from the environment and toolchain; others were real product defects. The team eventually produced build 9 and reached final verification, where the packaged application reproducibly crashed while saving a Smart Collection. A source-level repair was implemented and reviewed, but the replacement package was never accepted. Instead of converting partial progress into a success message, the workflow ended blocked. The launch and pitch agents never started. That was frustrating, but it was also the most useful result of the experiment. The interesting question was not whether multiple agents could generate a large amount of code. It was whether the system could preserve work, survive interruptions, expose repeated failures, and refuse to claim completion without product-level evidence. My biggest lesson: persistent multi-agent workflows can do substantial long-running work, but supervision does not eliminate failure. It makes failure visible—and recoverable.