Across the Putnami and Putnami Cloud repositories in July and August 2026.
Research
Claims should come with evidence.
Putnami is being built through real repositories, release paths, agent workflows, failures, and explicit limits. Research records what the evidence supports—and what remains an open question.
Evidence base · July–August 20262,235merged pull requests ≈6,800paired agent turns 10 / 10release checks passed
High throughput made the coordination problem visible.
These figures describe the work observed, not product value by themselves. Their purpose is to expose where local completion, system convergence, and trustworthy outcomes diverge.
A corpus used to study long-tail work, drift, correction, and program-level completion.
The August rehearsal moved from five blocked checks to a complete GO in 48 hours.
Current research program
Four questions guide the product.
Non-author operability
Can someone who did not build a system safely understand, change, operate, and recover it?
Evidence-bounded autonomy
What evidence must exist before an agent earns authority to act without another approval loop?
Progressive adoption
Which product guarantees remove more coordination and correction work than they introduce?
Terminal outcomes
How should teams measure completion beyond a plausible answer, closed task, or merged pull request?
Working thesis
What should an agent understand before it changes a repository?
A repository can establish structural facts. It cannot establish human intent by itself. The working thesis keeps those forms of authority distinct and asks what checks connect them responsibly.
From research to product
Keep, simplify, or remove each loop based on the result.
SDD, architecture contracts, Intelligence, delivery, review, and operational loops become defaults only when they reduce total time or coordination without weakening security or quality.