Specs Are Becoming Agent Contracts

The strongest July 20 signal came from Digg Tech surfacing ProductSpec.io, a GitHub-native editor and open standard built around human-agent product specs. The important shift is not the tool by itself. It is the operating assumption behind it: when agents participate in planning and delivery, a spec cannot stay as loosely worded prose that means different things to PMs, designers, engineers, and the model. ProductSpec’s framing pushes toward structured goals, constraints, artifacts, and acceptance criteria that can travel directly into implementation. That lines up with Addy Osmani’s recent argument that coding agents work best when they receive concrete context, explicit scope, and crisp definitions of done. The practical synthesis is that the spec is becoming part of the runtime for product development, not just a planning document stored upstream of it.

As more product work is mediated by agents, ambiguity becomes more expensive. A fuzzy spec does not just create discussion overhead; it creates wrong tool calls, wasted tokens, fake progress, and hidden rework. Teams that keep requirements unstructured will see agent output swing wildly by operator and by run. Teams that treat specs as executable contracts will get more reliable planning, implementation, and verification because every step starts from the same structured intent.

Rewrite one recurring product spec into an agent contract. Trigger: a feature request, experiment, migration, or launch task that currently requires repeated clarification between PM, design, engineering, and AI tools. Context: include user problem, target segment, constraints, linked references, non-goals, and the current system state the agent must respect. Tools: pair the spec with issue creation, prototype generation, code execution, and review workflows that read directly from the structured document. Verifier: require explicit acceptance criteria, edge cases, and a proof artifact for each claim, such as screenshots, tests, analytics events, or copy diffs. Budget: cap scope, open questions, and unresolved dependencies before implementation starts. Artifacts: produce the spec itself, linked tasks, implementation receipts, and a completion checklist tied back to the spec sections. Stop condition: work ends only when each acceptance criterion has evidence attached or the spec is formally revised.

Take the next feature brief your team plans to ship and convert it into a contract with these headings: goal, user, constraints, non-goals, acceptance criteria, proof required, and revision rule. If the agent or engineer still has to ask what “done” means, the spec is still descriptive rather than executable.