Building from a Specification with AI Agents

A practical engineering method for coordinating AI agents and verifying their work against explicit requirements.

Experimental WIP · 8 November 2026. Write the requirement, run the check, keep the result. A working implementation or an agent's success report does not by itself establish correctness. This is a practical technical guide, not a general AI essay, productivity forecast or endorsement by a researcher.

The public WIP kit contains the manual route, copyable task/acceptance/evidence records, portable reference recipes, source reconciliation and current limitations. That repository is the canonical public kit; this page explains the method. No account with our infrastructure is needed. Use the same instructions yourself or with your own coding agent.

Five responsibilities

  • Specification: define behavior, interfaces, constraints and invariants. It is the implementation authority, above an agent's memory or an SDK's behavior.
  • Task graph: define task inputs, outputs, dependencies, scope, completion and integration boundaries. A dependency-aware graph coordinates execution; it does not replace the contract.
  • Agents: investigate, design, implement, test and review bounded work. Report what changed, what it relied on and what remains unknown.
  • Verification: check explicit acceptance criteria at meaningful boundaries and retain evidence, including failures. Another model is not automatically an independent oracle.
  • Humans: set objectives, permissions and risk thresholds, resolve ambiguity and retain consequential decisions. Maximum agent count is not the goal.

Six steps you can follow

1. Pin the contract and checks

Name the specification version, code revision, input/fixture hashes and check versions before implementation. Do not rely on model memory. Separate application requirements, interoperability, security obligations and open empirical questions. Stop on consequential ambiguity rather than inventing rules.

2. Bound each task

Write its purpose and source, input/output, dependencies, allowed files/tools, excluded work, completion check, evidence destination and existing escalation/stop rule. Give each acceptance criterion a falsifiable Must, its Why and what should be challenged if it fights reality. Copy the templates.

3. Execute in dependency order

Parallelize only independent work; avoid conflicting file ownership. Include an integration task for the combined artifact at one final head. Record new dependencies and invalidate affected evidence when inputs move. A graph is not a claim that every task can be solved independently.

4. Check meaningful boundaries

Use applicable unit, integration, conformance, differential, negative and boundary checks, plus specialist review where the task requires it. Freeze expected values independently where possible. A deliberate defect must reach its named assertion; a setup failure is not a successful negative. Reviewers should give separate evidence-based assessments, not negotiate a consensus.

5. Keep the evidence

Retain the artifact, specification/code/check pins, exact executed command and output, exit status, environment and permissions. Distinguish passed, failed, cancelled, skipped, not run and unknown. Preserve failed attempts and human interventions. Integrate on evidence, not a success report. Technical clearance is not permission to merge or deploy.

6. Revise and recheck

Use observed implementation defects, task omissions or specification ambiguities to guide a bounded correction. Record the failing case/inputs, hypothesis and falsifier before a permitted retry. Classify failures before counting existing budgets; do not add retries to hide an exhausted run. Empirical means build, observe, evaluate and refine—not a demonstrated productivity advantage.

What the current WIP does and does not show

The operational playbook is v0.5.3, in testing; active process policy is separately v0.5.2. Prepared v0.5.4 corrections are proposals, not adopted rules. The current producer experiment is unfinished with failed CI; an earlier pre-build 20/20 measurement is not completed producer proof. This website/documentation release does not finish or validate that experiment. See dated results and limitations.

The immediate objective is one complete run meeting its agreed quality bar before moving on. One success would be a demonstration, not a reliability estimate, proof of security or evidence that zero repairs are needed. Incomplete specifications/tests and shared reviewer blind spots can miss behavior; assurance must be proportionate to consequences. This kit has manual instructions and unbuilt/omitted tooling; no automated-framework claim is made. Original private source bodies are omitted where redistribution rights are unresolved, with all sources reconciled.

PCOC example and integration boundary

For PCOC, the normative specification and conformance pack define interoperability. A producer makes the object; a verifier measures it; a service's policy decides admission. Development-workflow guidance changes none of those rules.

For normal integration, prefer a released SDK when it fits and follow the AI integration instructions. The SDK language list does not prove those implementations were independent SPEC-only builds. A SPEC-only experiment needs a separate permitted-input, isolation/provenance and interop evidence packet. Shared conformance vectors do not establish every security or economic property.

The method is usable with other versioned specifications too: explicit requirements, bounded execution, meaningful checks, retained evidence and human decisions. It is not a claim that a particular researcher endorses this workflow or that more computation automatically improves it.

Start here

Experimental public WIP, 8 November 2026. The canonical kit and dated status are in pcoc/devops; no normative specification change. Raw markdown.