Where AIR earns its overhead.
AIR is most useful when the work needs to survive the conversation: multiple steps, consequential decisions, changing sources, evidence requirements, review boundaries, or a clean continuation point. The domain can change; the need for explicit project state does not.
One runtime, different kinds of project.
The same operating discipline can support very different outputs because AIR binds the current work rather than pretending every task needs the same specialist role.
Development
Research, design, implement, debug, test, and review against an explicit task contract instead of letting the code outrun the intent.
- specification before consequential implementation
- verification and evidence kept visible
- changes remain bound to one active task
Research & analysis
Gather and synthesize sources without letting plausible inference quietly become sourced fact or allowing the question to drift during a long investigation.
- bounded research question
- sources and uncertainty separated
- recommendations reconciled to evidence
Writing & documentation
Carry a brief, voice, structure, source truth, review criteria, and unresolved decisions across drafts or sessions without re-briefing from scratch.
- persistent brief and constraints
- section-level execution
- source fidelity and review state
Brand & marketing
Keep positioning, voice, claims, design constraints, assets, and campaign decisions coherent while different tasks require different capabilities.
- one source of truth
- claim boundaries stay explicit
- creative work survives session changes
Strategy & decisions
Separate fact, estimate, judgment, assumptions, counter-cases, and reversal triggers so a recommendation remains reviewable after the discussion moves on.
- assumptions remain inspectable
- counter-case retained
- human decision authority stays explicit
Projects that cross lanes
Move from research to policy, code, documentation, positioning, assets, and rollout decisions while keeping one project contract and continuity record.
- capability changes with the step
- project state stays continuous
- authority does not drift with capability
Useful when the project state is the difficult part.
Some of AIR's clearest uses are not defined by a profession at all.
Project rescue & archaeology
Take over work with conflicting notes, partial outputs, abandoned decisions, or no trustworthy current state. Reconstruct what is still active before generating more.
- current versus stale state
- renewed task center
- unknowns kept visible
Cross-model continuation
Move recorded project state between compatible sessions or hosts without treating the old transcript itself as the project.
- explicit Handoff state
- receiver validation
- rebind before material continuation
Incident reconstruction
Keep observations, evidence, hypotheses, unknowns, corrective actions, and approval boundaries distinct when a plausible story would otherwise harden too quickly.
- evidence separated from inference
- unknowns preserved
- corrective action remains scoped
Decision stress-testing
Build the strongest counter-case, identify assumptions carrying the recommendation, and state what evidence should make the decision change.
- strongest counter-case
- reversal triggers
- fact, estimate, judgment separated
From knowledge to execution
Carry requirements from standards, research, documentation, or policy into bounded implementation work without pretending retrieval proves correct application.
- source constraints preserved
- verification remains explicit
- application still needs evidence
Long projects with fragile sessions
Use explicit state and Handoff when context limits, host changes, or ordinary session failure would otherwise force a project back into reconstruction.
- continuation point recorded
- settled decisions carried forward
- recovery remains evidence-bounded
Not every task needs AIR.
The framework should earn the structure it introduces.
Use AIR when the work is sustained, multi-step, consequential, evidence-sensitive, likely to cross sessions, or difficult enough that reconstructing decisions later would cost more than keeping them explicit now.
A one-off factual question, tiny disposable script, casual brainstorm, or low-cost exploratory task often moves faster in ordinary chat. AIR becomes useful when project discipline is cheaper than drift and reconstruction.
Have a project, not just a prompt?
Start with the short boot path, or understand the operating model first.