Print fully tested, functional agents from spec to any framework

No. Build generates the agent itself from the signed spec on your existing framework and tool set. It composes tools that are already defined and registered, it does not mint new skills or custom tools. Creating skills is a separate product area.

A completion tool suggests plausible next code and stops there. Build writes tests against the spec, iterates until they pass green, then runs a Verifier that traces the built agent against the spec to confirm every requested capability is actually present. Code can compile and pass unit tests while missing a requirement, and the faithfulness gate is what catches that.

The Verifier reads the signed spec and traces the built agent against it, enumerating each requested capability and confirming it is implemented with trace evidence. It produces a report listing every capability, a confidence score, and any unimplemented requirements, catching architecture mismatches, missing fallbacks, and wrong-parameter tool calls that tests alone cannot catch.

It creates a regression dataset during the build and writes tests that validate both output schema and semantics, not just that a response looks correct. When docs change or providers push updates, behavior drift shows up as a test failure instead of silent semantic rot in production.

No. Its structural plus semantic test coverage catches most regressions, but silent semantic drift across very long workflows and model-reasoning changes invisible to a schema still slip through. Catching those in production is the job of the Evaluate and Diagnose stages, not Build.

It does not audit code-quality or style metrics like cyclomatic complexity or test-coverage percent, so code can pass every spec test and still violate your style standards. It does not choose or configure your observability backend, it wires the traces and you integrate them into your stack. It does not continuously optimize a running agent, that is the Improve stage, and it does not compose across multiple models, that is an Architect-stage decision. It needs a clear, signed spec: if the spec is incomplete or ambiguous, the Verifier will not catch that.

After Spec and before Evaluate. The observability and eval wiring Build lays down is the substrate the rest of the lifecycle runs on: Evaluate scores against it, Diagnose reads its traces, and the Improve inner loop returns to Build to apply validated fixes.

Mid-to-late-stage teams already running agents in production with observability. Early-stage teams building greenfield agents tend to get more immediate value from Spec clarity and Evaluate's feedback loop first.