From Morphic to AIR

AIR did not arrive fully formed. It is the current result of an idea that moved through several names and architectures, including at least one direction I would not build the same way today. This page is the design lineage — not a substitute for the current AIR specification.

Morphic

The earliest version was Morphic. The idea was to stop asking a model to wear one permanent expert costume. Instead, the system would look at the current task, bring forward the capability appropriate to that task, complete the step, then change posture when the task changed. The useful part of that idea survived: capability should follow the work.

The Maugos / VM4AI phase

For a while the project had two imagined front doors. Maugos — Morphic Augmentation Operating System — was meant to be the marketing face, while vm4ai.com was the technical home. That split was eventually abandoned and VM4AI remained as the project/company identity.

The environment optimizer

vm4ai.com then became a working prompt-overlay tool. Users selected a model, a reasoning posture, and optional modules, and the site generated an overlay to paste into chat. It was useful, but the language around it sometimes outran what the mechanism could prove. Concepts such as truth mapping or bias stripping sounded architectural without corresponding evidence. AIR inherits an important lesson from that period: impressive wording is not a control surface.

The digital-teammate experiment

The next iteration tried to ground AI capability in real occupational profiles. Instead of a generic “act as an expert” prompt, it drew from human job-role descriptions such as ESCO or O*NET and attached those profiles to the work. That was more disciplined than roleplay, but it exposed another problem: occupational profiles are written for humans, so they carry traits, contexts, and competencies that may be irrelevant to the task a model is actually performing.

The shift that led to AIR

The important design move was to stop treating a human job description as the natural unit of AI capability. The system began moving toward task-relevant capability, explicit scope, project state, evidence, approval boundaries, and continuity instead.

Historical terminology note: earlier versions described this shift using language such as “vector-first” or “task vectors.” That language belongs to AIR's design history. Current AIR's operative public model is the one defined by the current runtime and governance sources: bound artifacts, Orbit state, capability layers, evidence and approval boundaries, verification, and Handoff continuity.

What survived

Two instincts survived every rename. First: structure should come from the work, not from a character the model is told to perform. Second: the session should not be the project. Morphic's task-dependent role switching evolved into bounded capability applied to a current task; the older migration/passport idea evolved into AIR's explicit Handoff record.

What changed

The biggest change was not branding. It was claim discipline. Current AIR makes a sharper distinction between what a prompt-based runtime can govern, what a host model can perform, what an AIR record can declare, and what still needs external evidence. The framework became more useful by becoming less willing to pretend.

For the current system, read How AIR works or inspect the public AIR Kit. To see how this history connects to VM4AI today, visit About.