The model behind AIR.
AIR — short for AI Resource — turns a chatbot session into a structured, auditable environment, with a teammate's discipline rather than an agent's autonomy. Here is the machinery, from the first question to the final handoff.
Start a session
Every project begins with one question — what are you doing? AIR never guesses the branch. From there a short, deterministic set of questions configures the session before any work starts.
Fix the scope and the agreement
Two questions do the heavy lifting: what you are building — goal, constraints, sources — and how you and AIR will work together. This is where responsibilities get divided — what is yours, what is AIR's — alongside files, diffs, review, and pace.
Layer on capability
A default profile governs by default. On top of it AIR binds reusable capability — a Specialist (a capability profile), a Domain pack (a standards overlay), a Method pack (a procedure with its own gates), and Executors (bounded, callable operations, not agents). Each stays subordinate to the contract and the gates, and nothing binds until it clears the capability gate. Full specs in the repo →
Keep context in orbit
The active task sits at Orbit 0. Supporting and background context orbit around it and inform inward, so focus stays on what is live without losing the surroundings.
Govern with gates
Procedures track their own live state, and gates decide when work advances. When two gates disagree, the stricter one governs.
Continue across sessions
Each session ends with a strict-JSON handoff card. The next session boots from it — so a project survives context limits and resumes exactly where it left off.
Structure, not slop
Vibe coding generates first and cleans up later. AIR binds a contract, surfaces blockers, benchmarks the work, and only delivers when it clears its own state.
See it in a session.
The fastest way to understand AIR is to run it. Grab the boot bundle and start a project.