Keď som pri verzii 1.63 publikoval release notes k novej generácii AI OS Layer runtime, išlo o jeden z najdôležitejších míľnikov v projekte. V tom bode už systém nebol len zbierkou shell utilít alebo experimentálnym toolkitom. Mal jednotný execution model, capability dispatch, workflow orchestration a event-driven runtime postavený na events.jsonl a state.json.

Odvtedy sa ale nezmenila samotná vízia projektu. Tá bola od začiatku rovnaká. AI OS Layer, ešte v časoch ai-toolkit, vznikal ako prenosná abstračná vrstva nad host prostredím. Cieľom nebolo vlastniť distribúciu, hardware ani konkrétny shell, ale vytvoriť konzistentný execution model, ktorý bude fungovať naprieč prostrediami. Preto som ho od prvých verzií testoval na Linuxe aj v Termuxe a preto boli portable a independent vlastnosti od začiatku základnou podmienkou návrhu, nie neskorším vylepšením.

Medzi verziami 1.64 a 1.104 sa teda nemenil smer. Menila sa najmä vyzretosť implementácie. Novšia verzia neprináša novú filozofiu, ale výrazne spevňuje runtime, observability, payload prácu a testovaciu vrstvu. Inými slovami: to, čo bolo vo verzii 1.64 funkčné a architektonicky správne, je vo verzii 1.104 oveľa pevnejšie, čistejšie a viac pripravené na reálne dlhodobé používanie.

Už verzia 1.64 mala všetko podstatné. Existoval capability systém, planner, scheduler a runner pre workflowy, audio pipeline cez ai mic, tool runtime v modeli „one step = one tool call“ aj rozdelenie CLI na ai, ag, at a aw. Dôležité je to povedať nahlas, pretože novší vývoj nie je príbeh o tom, ako AI OS Layer až neskôr získal svoju identitu. Tá tam už bola. Rozdiel je v tom, že medzi 1.64 a 1.104 sa z tejto identity stala omnoho tvrdšia runtime platforma.

Jedna z najväčších zmien sa týka samotného execution modelu. Vo verzii 1.64 bol reduce model už zavedený a funkčný, ale v novšom stave je jeho logika rozdelená oveľa explicitnejšie podľa domén. Reducery už netvoria jeden väčší kus logiky, ale sú rozdelené na samostatné vrstvy pre common, main, model, runtime, tool, watch a workflow. To nie je kozmetická zmena. Znamená to, že execution runtime je dnes modelovaný presnejšie a prehľadnejšie. Lepšie sa číta, lepšie sa rozširuje a hlavne sa lepšie debuguje. Projekt sa tým posúva ďalej od „veľkého shell skriptu“ a bližšie k tomu, čo má byť jeho skutočná podstata: prenosná execution vrstva s vlastným konzistentným runtime správaním.

Ďalší výrazný posun nastal v tom, čo runtime ukladá. Vo verzii 1.64 bol event log už základom celého systému. Verzia 1.104 k nemu však pridáva ďalší dôležitý rozmer: payload vrstvu. Run dnes neobsahuje len záznam o tom, že sa niečo stalo, ale vie uchovávať aj reálne artefakty execution flow. To zahŕňa textové payloady, JSON payloady, tool stdout a stderr výstupy, workflow outputy aj niektoré chybové payloady. To je veľmi dôležitá zmena, pretože event log samotný je výborný ako source of truth pre priebeh udalostí, ale až payload vrstva z neho robí naozaj silný základ pre audit, replay, debugging a forenznú analýzu behov. Systém tak už nezaznamenáva len priebeh execution, ale aj jeho konkrétny obsah.

S tým úzko súvisí aj dozretie tool runtime vrstvy. V staršej verzii bol model „one step = one tool call“ zavedený a funkčný. V novšom stave je však tool execution omnoho viac observability-first. Runtime pri tool calloch pracuje s bohatšími metadátami, eviduje preview výstupu, line a byte štatistiky, ukladá stdout a stderr payloady a viaže tool execution na konkrétne execution round identifikátory. Tools už teda nie sú len technický detail, ktorý niečo spustí v shelle. Stávajú sa prvotriednou execution entitou s vlastným auditovateľným správaním. A to je pre AI-native shell runtime zásadné. Ak má mať systém pevnú execution identitu, musí vedieť nielen spustiť nástroj, ale aj presne opísať, čo sa vykonalo, čo sa vrátilo a ako tento krok zapadá do celého runu.

Veľmi dobre je tento posun viditeľný aj vo workflow orchestration. Workflow engine existoval už v 1.64, ale vo verzii 1.104 pracuje s bohatšou meta vrstvou. Workflow uzly nesú viac údajov o trvaní vykonania, výstupných payloadových artefaktoch a detailoch zlyhania. Workflow runtime sa tak neposúva len v tom, že vie niečo spustiť, ale aj v tom, že vie oveľa lepšie vysvetliť, čo sa stalo. Z pohľadu architektúry je to dôležité, pretože workflows v AI OS Layer nie sú len používateľská skratka. Sú jedným z hlavných spôsobov, ako systém organizuje execution logiku. Čím sú preto merateľnejšie a auditovateľnejšie, tým pevnejší je celý runtime model.

V tomto smere je dôležitá aj ďalšia vrstva, ktorá medzi 1.64 a 1.104 citeľne narástla: performance a stats. V novšom stave už runtime nesleduje len to, či sa niečo vykonalo správne, ale aj to, ako dlho to trvalo a aké má execution správanie. Entry pointy ako ai, ag, at a aw majú explicitnejšiu timing logiku, pribudla perf vrstva a stats helpery. To je prirodzený znak toho, že projekt dozrieva. Keď sa systém mení z toolkitu na execution platformu, nestačí mu len fungovať. Musí byť aj merateľný, pretože bez toho sa ťažko hľadajú výkonnostné regresie, slepé miesta a rastúca runtime zložitosť.

Podobne zaujímavý posun je viditeľný vo watch vrstve. aw už nepôsobí ako samostatnejšia bočná utilita so svojím vlastným svetom, ale je omnoho viac previazaný so spoločným run modelom a log adresárovou štruktúrou. To je dôležité nielen technicky, ale aj koncepčne. Watch mechanizmy totiž nemajú stáť mimo execution modelu. Majú byť jeho súčasťou. A práve v novšej verzii je tento smer oveľa zreteľnejší.

Veľkou kapitolou je testovacia vrstva. Rozdiel medzi 1.64 a 1.104 nie je len v tom, že testov je viac. Dôležitejšie je, že sú lepšie rozložené podľa domén systému. Namiesto jedného väčšieho runtime balíka sú testy čistejšie organizované cez oblasti ako ai, ag, aw, runtime, workflow a perf. To je veľmi zdravý signál, pretože test suite začína viac zrkadliť architektúru projektu. Zároveň je vidieť, že novšie testy idú oveľa viac po kontraktoch a hraničných stavoch. Nevalidujú len to, že workflow prešiel, ale aj to, že reduce pipeline zostáva konzistentná, že payload handling funguje správne, že tool kontrakty sú korektné, že stderr sa správa očakávane, že runtime zvláda invalidné vstupy a že replay ostáva deterministický. To je presne typ testovania, ktorý potrebuje systém, ak sa má správať ako platforma a nie ako voľne rastúca zbierka utilít.

Zároveň je dôležité povedať aj to, čo sa nezmenilo. Hoci sa implementácia výrazne posunula, základná filozofia projektu ostáva rovnaká. AI OS Layer je stále shell-first, portable a host-independent vrstva. Neviaže sa na konkrétny hardware, distribúciu ani jedno prostredie. Host OS zostáva substrate, nie identita systému. To je vlastne najdôležitejší dôkaz kontinuity celého projektu. Medzi 1.64 a 1.104 nevznikol nový smer. Skôr sa ukázalo, že pôvodný smer bol správny a že sa ho podarilo technicky dotiahnuť ďalej.

Ak by som mal celý rozdiel zhrnúť jednou vetou, povedal by som to takto: verzia 1.64 zaviedla použiteľný unified runtime, zatiaľ čo verzia 1.104 z neho robí výrazne viac auditovateľný, payload-aware, kontraktovo testovaný a observability-first execution systém.

To je podľa mňa najpresnejší opis toho, čo sa medzi týmito verziami stalo. Nie revolúcia vo vízii, ale veľmi výrazný posun vo vyzretosti. A práve tento typ posunu má dlhodobý zmysel. Nejde o nahadzovanie náhodných feature. Ide o spevňovanie execution vrstvy tak, aby vedela niesť čoraz komplexnejšie workflowy, náročnejšie debugging scenáre a robustnejší runtime bez toho, aby sa stratila pôvodná prenosnosť a nezávislosť, na ktorých bol projekt postavený od začiatku.

AI OS Layer tak vo verzii 1.104 nepôsobí ako iný projekt než v 1.64. Pôsobí ako ten istý projekt, ale v omnoho tvrdšej a dospelejšej forme. A to je pri tomto type systému presne ten správny smer vývoja.