Where AIR fits.
Spec-driven development, coding agents, autonomous agent runtimes, and governed AI work solve overlapping problems at different layers. AIR is not trying to collapse them into one category.
Similar words. Different jobs.
These are architectural categories, not a feature scoreboard. Individual products can span more than one row.
Governed execution without requiring autonomous agency.
AIR can structure work performed by a capable host model without turning capability layers into independent agents.
Define what must be true
For software, behavior and verification are specified before material implementation where the task requires it. Other domains use the verification abstraction that fits the work.
Keep one execution center
The bound Orbit 0 artifact is the sole positive execution authority. Specialists, methods and executors do not inherit project authority merely because they are available.
Keep claims proportional
AIR distinguishes declared prompt-layer state from source, tool, operator and backend evidence. Passing a conversational checkpoint is not treated as proof of an external event.
Carry governed state forward
Handoff serializes explicit project state for validation and rebinding in another compatible session instead of relying on hidden memory or transcript reconstruction.
SDD is a native fit — not AIR's whole category.
For behavior-bearing development work, AIR's sequence is specification-first: resolve intent, define observable behavior and planned verification, test specification adequacy, generate under the active contract, execute verification, and reconcile the result back to the original intent. AIR applies the same discipline beyond code using domain-appropriate evidence and verification.
AIR for software: spec-driven development. AIR as a system: specification-driven governed execution for sustained professional AI work.
Three views of the software story.
The category, the verification mechanism, and the practical workflow are separated so each can be read without turning the overview pages into documentation dumps.
Spec-driven development with AIR
Why AIR qualifies as SDD for software work, how the sequence operates, and why SDD is not AIR's whole category.
Read the SDD page →Specification-First Verification
Behavior specification, verification specification, specification adequacy, execution, evidence, and reconciliation back to intent.
Read the SFV page →AIR for software development
How a software project moves through AIR in practice, including responsibility split, active-task binding, testing, approvals, and Handoff.
See the development workflow →Products can overlap these layers.
The examples below are useful reference points, not claims that the products are interchangeable or directly benchmark-comparable.
GitHub Spec Kit
A specification-driven software-development harness built around structured development artifacts and coding-agent execution.
Primary source →Kiro
An agentic engineering environment that turns specifications into requirements, design, tasks and implementation.
Primary source →FrontierAgent
A stateful agent runtime with coordinator, task-board, sandbox, approvals, recovery and bounded sub-agent execution.
Primary source →AIR
A prompt-based project runtime centered on one bound active task, explicit governance records, evidence boundaries and portable Handoff state.
Inspect AIR →Category descriptions are intentionally conservative. They describe publicly documented architecture and positioning, not independent performance rankings.
Use the layer you actually need.
If the problem is sustained AI work that must stay scoped, reviewable and portable, AIR supplies the governing project layer without requiring a new chat workspace or autonomous-agent stack.