After the spec: the comparison.

runward, Spec Kit, BMAD, Kiro, OpenSpec and Spec Kitty all shape how an AI agent builds; they split on two axes: how far each reaches in the lifecycle, and how it verifies the result.

This page maps what each actually does, described from their own documentation (sources at the end), and where runward's ground is different. One distinction clears up most of the confusion first.

Harness vs scaffold

A harness is the thing that runs your agent: Claude Code, Cursor, Codex, GitHub Copilot. It reads your files, calls tools, and edits your code in a loop, with an AI model doing the reasoning. That's the engine.

A scaffold is the method placed on top of the harness so the agent builds like an engineer instead of improvising: a set of instructions, rules and skills that tell it how to work, and — for some — a check on the result. Spec Kit, BMAD, Kiro, OpenSpec, Spec Kitty and runward are all scaffolds. The loop belongs to the harness and the reasoning to the model; the scaffold shapes how the agent builds.

Every one of these helps an agent write code, runward included. So the useful question when choosing isn't "does it build?" — they all do. It's what each does besides generate code, because that's where they split.

One line each

• GitHub Spec Kit turns a written spec into code through a fixed flow (/constitution → /specify → /plan → /tasks → /implement). Best-in-class at nailing the intent before the agent builds. GitHub-native, huge reach.
• BMAD runs a simulated agile team of AI personas (analyst, PM, architect, dev, QA) that carry a project from brief to code. Fun, great to watch, a big and active community.
• AWS Kiro is an AI IDE built around specs (requirements → design → tasks), with steering files and event hooks. Deep AWS integration; lives inside the editor.
• OpenSpec is a light spec loop (propose → apply → archive) that plugs into a lot of agents.
• Spec Kitty is a "delivery control plane" — a spec loop with a Kanban dashboard, work-package lanes, deterministic gates and a persisted evidence log. The closest thing to runward's ground.
• runward puts a deterministic, zero-LLM gate on the load-bearing decisions behind your agent's delivery — evidence verified and sealed, hand-over gated — and the trail exports as a standardized OSCAL pack an auditor reads. Made for delivery with stakes, regulated ones included.

How each verifies the result

This is the sharpest single difference, and it's checkable in each tool's own docs. When a scaffold issues its verdict on the delivery — was the work acceptable, is it done — most of them let the AI itself be the judge, and the verdict is advisory — nothing blocks:

• Spec Kit — /analyze is a "non-destructive cross-artifact consistency and quality analysis" that outputs a Markdown report; /checklist writes "unit tests for requirements", i.e. it checks the spec, not the code. [1]
• BMAD — the QA persona issues a "Quality Gate Decision: PASS / CONCERNS / FAIL" that the docs call, verbatim, "advisory … provides recommendations, not blocks." [2]
• OpenSpec — /opsx:verify asks the model to validate "completeness, correctness, and coherence" and "does not block archive"; the deterministic openspec validate checks spec structure only. [4]
• Kiro — the partial exception: it generates property-based tests from EARS requirements and runs them against the implementation, but running them is optional and the outcome is human-interpreted, with no enforced gate. [3]
• Spec Kitty — the real outlier: it does wrap deterministic gates (an e2e "hard pass/fail gate", pytest non-zero-exit ⇒ FAIL) and it does gate the hand-over — but its acceptance verdict is still an AI review, and its evidence is bespoke YAML, not a standardized format. [5]

runward's check is plain, deterministic code with no model in the gate path: the same input gives the same verdict, and no prompt can talk it into passing (ADR-0001). A rule the agent was told to follow but quietly skipped still fails. Its verdict is deliberately narrower and harder: it proves the load-bearing decisions were made, traced, and backed by evidence that resolves — including the tests that do exercise the code — and it never judges code quality itself, and says so. A hard guarantee can't be built out of a soft judge.

Scaffold	The verdict is made by	Gates the hand-over	Machine-readable audit
Spec Kit	the AI (/analyze, advisory Markdown) [1]	no [1]	no [1]
BMAD	an AI persona ("advisory … not blocks") [2]	convention only [2]	bespoke YAML [2]
Kiro	AI-generated tests, optional + human-read [3]	no (human confirm) [3]	no [3]
OpenSpec	the AI (/opsx:verify, non-blocking) [4]	no [4]	structural JSON only [4]
Spec Kitty	an AI review wrapped in deterministic gates [5]	yes, deterministic [5]	bespoke YAML [5]
runward	plain deterministic code, no LLM in the gate	yes, gated	yes — standardized OSCAL

What runward pairs that no other does

Four grounds, and a code-level check (July 2026) confirms no other scaffold pairs them. Each exists somewhere on its own; the combination is what's distinct — and each is a written, dated decision, not a slogan:

1. It checks the evidence, not just the claim. When a rule is marked "applied", runward verifies the pointer resolves to real, non-empty content (ADR-0019); a rule can declare the shape its evidence must contain, so citing a guard that was never shipped turns the check red (ADR-0020). See evidence and integrity.

2. Sealed evidence. runward check --freeze hashes every evidence file (SHA-256) into evidence-lock.json; if a sealed file silently changes later, the gate reddens until re-verified (ADR-0021). Not "a box was ticked" — "the thing the box points at is really there," and it stays there.

3. Gated hand-over. The hand-over is a gated phase, not a folder to drop: "the succession is proven by a real task the receiving team redoes without you" passes or fails like any other gate (ADR-0026). Nobody else carries the mission past tested code — except Spec Kitty, which is why the frontier below draws the line exactly.

4. Machine-readable proof, in a published format. runward compliance emits an OSCAL evidence pack — built from the traced decisions and the gate's actual status — that a compliance tool (Vanta, Drata) or an auditor can read, and the decision → ADR → manifest → OSCAL mapping is published as a versioned, citable spec (ADR-0025). It feeds an ISO 42001 or EU AI Act file — see compliance evidence — and it never claims you're "compliant"; no tool can.

Under all four sit two invariants. The gate is a port with harness adapters, so no agent is privileged and runward never installs a hook or wires itself (ADR-0012). And the gate is deterministic and zero-LLM (ADR-0001): the model lives in your coding harness, upstream; the gate never calls one — see the deterministic gate.

The frontier: runward vs Spec Kitty

Of the five, only Spec Kitty gets close: it gates the hand-over deterministically and emits a machine-readable audit trail. The gap is narrow, and worth drawing exactly.

Two things separate them. First, the acceptance verdict: Spec Kitty's "did it satisfy the acceptance criteria" is an AI review wrapped by deterministic gates [5]; runward's rule-conformance verdict is plain code with no model in the path (ADR-0001). Second, the audit artifact: Spec Kitty's evidence is bespoke per-mission YAML [5]; runward's is standardized OSCAL a GRC tool ingests, with a published, citable mapping (ADR-0025). Same shape of ambition — runward's evidence is interoperable, and its verdict has no soft judge inside it.

Why "deterministic" matters right now

Two 2026 signals make the plain-code stance more than a preference. The US federal FedRAMP program (RFC-0024) drew a hard line: probabilistic, AI-generated outputs must not be used as factual compliance evidence. And the Delve affair — a startup expelled from Y Combinator over AI-prefilled SOC 2 audits — showed the market why. Evidence a model produced is evidence you can't trust. A gate that is deterministic and holds no model in its path is the answer both point at.

What's the same for everyone

Two things that get mistaken for a difference, and aren't:

• Framing the agent. Every scaffold does it. That's the category, not an edge for anyone.
• Skills. The SKILL.md "Agent Skills" format is now a shared standard, and Spec Kit, BMAD, OpenSpec and runward all ship them. Skills are table stakes. What sets runward apart is the plain-code check underneath the skills, the one thing none of the others have.

When to pick which

• Spec Kit if you want the sharpest "spec → code" loop and the GitHub ecosystem.
• BMAD if you like the "AI agile team" feel and a lively community.
• Kiro if you live in an AWS-native editor.
• OpenSpec if you want a light spec loop across many agents.
• Spec Kitty if you want a delivery dashboard with deterministic gates and a per-mission evidence log.
• runward if you want the agent to build a real system that survives prod — and you want to defend how it was built, hand it off cleanly, and show an auditor a standardized evidence pack. You don't trade shipping for control; you get both.

And the orchestrators? (LangGraph, CrewAI, OpenAI Agents SDK)

A different question entirely, so not a competitor. Those frameworks solve execution: how the agent runs, its memory, its tools, its graph of steps. runward solves delivery: how the project gets framed, decided, built and handed off. Two things worth saying, because they cut the other way from the scaffolds:

• runward doesn't need one. Its doctrine names ecosystem standards as versioned port contracts rather than implementing them (ADR-0011): you keep a clean, modular architecture — each capability behind a stable port, swappable without touching the rest — with no abstraction layer forced on you: more maintainable, more legible, less lock-in.
• runward composes with one. If a real trigger justifies an orchestrator, it enters as an optional adapter behind a port, and runward governs its delivery like everything else. runward even ships inert adapters into competing scaffolds (ADR-0027): it runs inside them as a complement, never privileged.

So runward stands alone, and works with them if you want. It never depends on them.

The double void

The same finding reads from the other shore — the research on harnesses. The field survey "Code as Agent Harness" (arXiv 2605.18747; listed affiliations: Meta, Stanford, UIUC), which maps code as the medium agents act through, mentions neither Spec Kit, nor OpenSpec, nor BMAD, nor any delivery methodology: zero occurrences in its sources, checked in July 2026. It even treats developer intent as "latent state" — something the agent must infer, never the input of a delivery method. So the void is double: the spec-driven world frames intent and stops before the run; the harness world runs the agent and says nothing about delivery. A survey describes a landscape, it doesn't arbitrate between tools; what it shows here is a square nobody occupies. runward holds that intersection: the spec as an input, the deterministic gate as the verdict, the delivery as the object.

In one line

runward is the engineering that makes an agentic system hold: every load-bearing decision made, traced and proven before prod, verified by code, audit-ready.

The agent builds the real system, inside guardrails; runward requires and checks the decisions that keep it standing: 64 engineering rules, six gates crossed on evidence, every decision dated and justified, a deterministic check no prompt can talk into passing, evidence verified and sealed rather than merely cited, a hand-over gated on a task the team redoes without you, and an audit trail ready for Vanta, Drata or an auditor — in a published, citable format. It's the Forward Deployed Engineer method, packaged from a 60-page doctrine (Designing and Running Agentic Systems, CC BY-ND 4.0), made executable.

Try it in one command — npx runward init --example drops a complete, working reference to read and re-run. To get started: npx runward init, or runward.dev.

Sources

Competitor descriptions are taken from each tool's own documentation, as of July 2026 — not from third-party summaries.

• [1] Spec Kit — github.com/github/spec-kit (README, templates/commands/analyze.md, checklist.md, spec-driven.md).
• [2] BMAD-METHOD — github.com/bmad-code-org/BMAD-METHOD (docs/user-guide.md, bmad-core/templates/qa-gate-tmpl.yaml).
• [3] AWS Kiro — kiro.dev/docs (specs, specs/correctness, quick-plan, pricing).
• [4] OpenSpec — github.com/Fission-AI/OpenSpec (docs/concepts.md, commands.md, cli.md).
• [5] Spec Kitty — github.com/Priivacy-ai/spec-kitty (ADRs e2e-hard-gate, retrospective-gate, review guidelines.md, retrospective.yaml).