OS Layer 2.x: pôvodná myšlienka začína byť viditeľná
Keď som začínal s OS Layerom, základná myšlienka bola od začiatku pomerne jasná.
Nechcel som vytvoriť ďalšiu veľkú AI aplikáciu.
Chcel som vrstvu malých, samostatných a skriptovateľných komponentov, ktoré sa dajú používať z terminálu, skladať cez shell, automatizovať a zároveň sprístupniť agentom a modelom.
V princípe veľmi unixový prístup:
small tools
clear interfaces
CLI
stdin / stdout
composition
automation
AI mala byť používateľom tejto vrstvy.
Nie jej jediným dôvodom existencie.
Toto sa nezmenilo.
Čo sa zmenilo, je rozsah.
Dnes má OS Layer 32 samostatných komponentov:
Core 7
Capabilities 19
Apps 2
Agents 3
Platform 1
--
32
Z toho je:
26 public
6 private
A celý strom už prakticky prešiel do generácie 2.x.
Pri pohľade na dnešný systém je preto oveľa lepšie viditeľné, čo som tou pôvodnou architektúrou myslel.
Nie je to nový smer.
Je to pôvodný smer, ktorý začína byť viditeľný v celom rozsahu.
Nie nový smer, ale väčší systém
Niektoré veci, ktoré dnes môžu vyzerať ako nové architektonické rozhodnutia, boli súčasťou OS Layeru prakticky od začiatku.
deploy riešil distribúciu a bootstrap systému.
secrets oddeľoval credential management od jednotlivých aplikácií a capabilities.
board vznikol ako observability a debugging nástroj.
Komponenty mali byť samostatne použiteľné z CLI.
Mali byť skriptovateľné.
Automatizovateľné.
Skladateľné.
A vyššie vrstvy ich mali používať namiesto toho, aby sa všetka funkcionalita zatvárala do jedného veľkého programu.
Nič z toho teda nie je nová filozofia verzie 2.x.
Rozdiel je v tom, že dnes už sa tieto princípy neukazujú na piatich alebo desiatich komponentoch.
Ukazujú sa na tridsiatich dvoch.
A to je úplne iný test architektúry.
AI je jedna capability
Najlepšie to dnes vidno na samotnom zozname capabilities:
Capabilities
├── ai
├── audio
├── bank
├── code
├── crypto
├── debug
├── desktop
├── executor
├── html
├── image
├── mail
├── mobile
├── model
├── remote
├── render
├── rss
├── vision
├── watcher
└── wireguard
ai je jedna z nich.
Nie nadradený program, do ktorého treba natlačiť každú ďalšiu funkciu.
Keď potrebujem speech-to-text alebo text-to-speech, patrí to do audio.
Keď potrebujem pracovať s obrázkami, existuje image a vision.
Keď potrebujem poslať mail, existuje mail.
Keď potrebujem analyzovať source code, existuje code.
Keď potrebujem debugovať proces cez DAP, existuje debug.
Keď potrebujem spustiť proces pod policy kontrolou, existuje executor.
Keď potrebujem vzdialené vykonávanie a diagnostiku, existuje remote.
Každá capability má byť použiteľná samostatne.
Napríklad:
audio ...
mail ...
code ...
remote ...
rss ...
A až potom sa nad nimi dajú stavať ďalšie vrstvy.
Shell skript.
Cron.
Watcher.
Agent.
Codex.
Claude Code.
Alebo čokoľvek ďalšie.
To bol zámer od začiatku.
Dnes je len oveľa lepšie vidieť, kam tento model vedie.
Lokálna AI sa brutálne zrýchlila
Veľký posun sa pritom udial aj vo vnútri samotnej ai capability.
Pribudol nový lokálny backend postavený na llama.cpp.
A tentoraz nejde o pár percent.
Na rovnakom type workloadu sa lokálna inferencia posunula približne z:
~50 tokens/s
na:
100–120 tokens/s
Prakticky dvojnásobok.
Pri jednej krátkej odpovedi je to príjemné.
Pri agentovi, ktorý počas jednej úlohy urobí množstvo inferencií, tool callov, validácií a ďalších krokov, je to zásadný rozdiel.
50 tokens/s a 120 tokens/s nie sú iba dve čísla v benchmarku.
Je to rozdiel medzi tým, či lokálny model pôsobí ako pomalší fallback, alebo ako normálny interaktívny backend.
A potom prišla ďalšia dôležitá optimalizácia:
KV cache.
KV cache mení agentový loop
Pri generovaní model opakovane pracuje s predchádzajúcim kontextom.
A agentový workflow typicky nevyzerá ako jednoduché:
prompt
↓
answer
Skôr:
prompt
↓
reasoning
↓
tool call
↓
tool result
↓
reasoning
↓
ďalší tool
↓
validation
↓
final
Medzi jednotlivými krokmi zostáva veľká časť vstupu rovnaká.
System prompt.
Definície tools.
Policy.
História konverzácie.
Predchádzajúce tool výsledky.
Agent state.
Ak sa toto všetko zakaždým spracuje od nuly, model robí veľké množstvo redundantnej práce.
KV cache umožňuje ponechať už vypočítané attention key/value reprezentácie a znovu ich použiť.
Praktický výsledok je veľmi citeľný.
Nejde iba o vyššie tokens/s.
Znižuje sa hlavne latencia medzi jednotlivými krokmi agenta.
A presne pri agentových workflow je toto podstatné.
Ak jeden krok ušetrí sekundu alebo dve, nie je to nič dramatické.
Ak workflow obsahuje desiatky krokov, výsledok už cítiť brutálne.
Backend je implementačný detail
Aj tu sa ukazuje pôvodná architektúra OS Layeru.
ai nie je synonymum pre:
Ollama
ani:
llama.cpp
ani:
OpenAI
ai je capability.
Backend je vymeniteľný.
┌── llama.cpp
├── Ollama
ai capability ─┼── cloud provider
└── ďalší backend
Shell stále používa ai.
Agent stále používa ai.
Tool stále používa ai.
Ostatné komponenty stále používajú rovnaké rozhranie.
Mení sa iba spôsob, akým sa konkrétna inferencia vykoná.
A práve preto som nechcel naviazať OS Layer na jeden model server alebo jedného providera.
Dnes môže byť najvýhodnejší llama.cpp.
Zajtra môže existovať lepší backend.
Capability contract zostáva.
Unixový princíp vo väčšom meradle
OS Layer sa stále snaží držať jednoduchého pravidla:
Capability má poskytovať schopnosť, nie celý svet okolo nej.
audio nerieši agenta.
mail nerieši AI.
code nerieši orchestráciu.
executor nerieši používateľské workflow.
Jednotlivé komponenty robia svoju časť.
Vyššie vrstvy ich skladajú.
Môžem napríklad úplne bez AI spraviť:
audio record /tmp/input.wav
audio transcribe /tmp/input.wav
Môžem použiť rss.
Môžem použiť remote.
Môžem použiť mail.
Ale rovnakú capability môže dostať agent ako tool.
Z pohľadu capability by ideálne nemalo byť podstatné, či ju zavolal človek zo shellu, shell script alebo model počas agent runu.
A práve tu sa podľa mňa ukazuje sila pôvodného unixového návrhu.
AI sa mení extrémne rýchlo.
Modely sa menia.
Providery sa menia.
Agent frameworky sa menia.
Ale základ:
input → program → output
funguje stále.
Core
Pod capabilities dnes leží sedem Core komponentov:
Core
├── deploy
├── gateway
├── integrations
├── layer
├── mcp_server
├── runtime
└── secrets
Nejde o to, že by základné problémy vznikli až teraz.
Skôr sa ukazuje, čo všetko treba na to, aby rovnaký model fungoval pri väčšom systéme.
Deploy
deploy rieši release, publishing a bootstrap komponentov.
Distribúcia bola súčasť projektu od začiatku.
Dnes však deployuje systém, ktorý už nemá pár skriptov, ale desiatky samostatných komponentov s vlastnými verziami, metadata, dependencies, permissions, testami a release artefaktmi.
Ten istý pôvodný problém má pri dnešnom rozsahu jednoducho oveľa väčšie nároky.
Secrets
secrets je samostatná encrypted secrets vrstva.
Credential nikdy nemal patriť natvrdo do ai, mail, audio alebo inej capability.
Jeden credential môže používať viac komponentov.
OpenAI môže potrebovať AI, audio, image alebo vision.
Mail potrebuje svoje SMTP/IMAP credentials.
Integrácie potrebujú ďalšie providers.
Secret patrí systému.
Nie konkrétnej aplikácii.
To bola pôvodná myšlienka a pri dnešnom počte capabilities je iba oveľa viditeľnejšie, prečo je dôležitá.
Layer
layer rieši service lifecycle, readiness, boot autostart a control-plane supervision.
Pri malom počte programov stačí otázka:
dokážem tento proces spustiť?
Pri väčšom systéme už potrebuješ vedieť:
má bežať?
beží?
je ready?
čo ho spustilo?
čo sa stane po páde?
čo sa stane po reboote?
Stále je to rovnaká filozofia skriptovateľného systému.
Len aplikovaná na väčšie množstvo persistentných služieb.
Runtime
runtime poskytuje univerzálnu persistentnú execution vrstvu.
Capability môže byť malý program.
Operácia, ktorú spustí, ale nemusí byť malá ani krátka.
Runtime poskytuje spoločný model vykonávania bez toho, aby si každá capability musela stavať vlastný mini-runtime.
To je dôležité aj pre agentov.
Agent nemusí celý čas držať proces otvorený a byť execution enginom všetkého, čo spustí.
Prácu môže vykonať Runtime.
Gateway a integrations
Medzi novšie časti systému patria gateway a integrations.
Tie rozširujú rovnaký princíp za hranice lokálneho stroja.
external provider
│
▼
gateway
│
▼
integrations
│
▼
capability / runtime / agent
gateway je vendor-neutral HTTP webhook ingress.
Provider pošle svoj event.
Gateway ho dekóduje, normalizuje a uloží do durable event inboxu.
integrations nad tým rieši provider-neutral account registry, service bindings a routing integračných capabilities.
Opäť ide o oddelenie providera od vnútorného systému.
Provider-specific logika patrí na hranicu.
Vnútro OS Layeru by malo pracovať s čo najstabilnejším kontraktom.
Platform adaptery
Dnes je v Platform vrstve napríklad:
nextcloud
Nextcloud komponent poskytuje adapter pre Talk messaging, Files cez WebDAV a Calendar cez CalDAV.
OS Layer ale nemusí byť interne naviazaný na Nextcloud.
To je podstatný rozdiel.
Konkrétny provider je implementácia služby.
Nie architektúra celého systému.
MCP je ďalšie rozhranie
Podobne vnímam mcp_server.
OS Layer dokáže exportovať agent-callable Component v2 functions cez MCP stdio transport.
Ale interná architektúra systému nestojí na MCP.
┌── CLI
├── MCP
Component ─────┼── Agent
├── automation
└── ďalší klient
MCP je spôsob, ako capability vystaviť.
Nie definícia capability samotnej.
To umožňuje, aby komponent zostal normálnym CLI programom a zároveň bol použiteľný z agentových ekosystémov.
Agents
Agent vrstva dnes obsahuje:
Agents
├── agent
├── claudecode
└── codex
agent je durable multi-agent orchestrator so schedulingom, stavom, signals, memory a verified completion.
codex poskytuje OpenAI Codex integráciu.
claudecode umožňuje používať Claude Code s Anthropic backendom, externými gatewaymi alebo lokálnymi modelmi.
A znovu platí rovnaká hranica:
Agent nie je platforma.
Agent platformu používa.
Agent môže používať:
mail
audio
remote
code
executor
vision
image
html
rss
...
Ale tieto capabilities existujú aj bez neho.
Môže ich používať človek.
Shell.
Automatizácia.
Iný agent.
Alebo aplikácia.
Apps
Apps sú momentálne dve:
Apps
├── board
└── cryptobot
board je read-only observability, correlation a debugging cockpit.
To bola jeho úloha od začiatku.
Rozdiel je v tom, koľko vecí dnes dokáže sledovať a korelovať.
Pri súčasnom OS Layeri sa počas jedného workflow môžu prepojiť:
agent
tool
approval
runtime execution
event
signal
gateway request
integration
remote host
provider
Board stále rieši rovnaký problém.
Len má pred sebou oveľa väčší systém.
A potom je tu cryptobot.
Úplne iný use-case.
Production Rust trading engine s durable order managementom, reconciliation, risk exits, emergency controls a strategy validation.
To je podľa mňa dobrý test celej architektúry.
Ak rovnaký systém dokáže slúžiť AI agentovi, mail capability, remote executorovi a zároveň trading enginu, už to nie je iba framework okolo LLM.
Je to všeobecnejšia execution a automation platforma.
Public a private komponenty
Aktuálne je v OS Layeri:
26 public
6 private
Private sú momentálne napríklad:
deploy
bank
crypto
wireguard
cryptobot
nextcloud
To umožňuje držať všeobecné komponenty oddelené od mojich konkrétnych infraštruktúrnych alebo domain-specific use-case vrstiev.
Pointa je, že súkromná business alebo infrastructure logika nemusí prerásť do verejného core.
Rovnaké kontrakty môžu používať obe strany.
Component v2
Veľká časť súčasnej práce bola prechod komponentov na čistý Component v2 model.
A tu je podľa mňa dôležité povedať, čo 2.x znamená a čo neznamená.
Nie je to nová filozofia OS Layeru.
Unixový prístup, CLI, composability, automatizácia a oddelené komponenty tam boli dávno predtým.
Component v2 skôr dáva týmto pôvodným princípom oveľa presnejšiu a jednotnejšiu formu.
Komponent dnes má jasne definované veci ako:
VERSION
component.meta
package ownership
public/private policy
functions
permissions
approval policy
runtime-owned paths
release-owned paths
certification
A tým sa z pôvodne voľnejšieho stromu komponentov stáva systém s formálnym kontraktom.
Nový komponent už nemá byť len adresár, ktorý náhodou funguje.
Má byť jednotka, ktorú vie OS Layer:
identifikovať
validovať
certifikovať
publikovať
nainštalovať
spustiť
aktualizovať
To je pre mňa podstata generácie 2.x.
Nie nový OS Layer.
Presnejšie definovaný OS Layer.
32 komponentov je test pôvodnej myšlienky
Samotné číslo 32 nie je veľmi zaujímavé.
Mohol by som mať 100 komponentov a celý systém by stále mohol byť jeden veľký chaos.
Zaujímavejšie je, že pôvodný model stále funguje aj pri tomto rozsahu.
Stále môžem vytvoriť malý program.
Dať mu jasný interface.
Spustiť ho zo shellu.
Použiť ho v skripte.
Zavolať ho z iného programu.
Dať ho agentovi ako tool.
Spustiť jeho operáciu cez Runtime.
Sledovať ju cez Board.
Napájať ho na Secrets.
Distribuovať ho cez Deploy.
A nemusím kvôli tomu prerobiť polovicu systému.
To je oveľa dôležitejší míľnik než samotný počet capabilities.
Výkon začína meniť spôsob používania
Popri architektúre sa pritom začína meniť ešte jedna dôležitá vec.
Lokálna inferencia je konečne dostatočne rýchla na to, aby prestala pôsobiť ako kompromis.
Nový llama.cpp backend posunul výkon približne z:
~50 tokens/s
na:
100–120 tokens/s
A KV cache zásadne znížila cenu opakovaného spracovania rovnakého kontextu.
To je pri agentoch mimoriadne dôležité.
Lokálny model už nemusí byť iba:
offline fallback
alebo:
lacnejšia alternatíva ku cloudu
Môže byť normálnou súčasťou interaktívneho workflow, automatizácie a persistentných agentov.
A pre OS Layer je práve toto podstatné.
Cieľom nikdy nebolo postaviť systém, ktorý funguje iba vtedy, keď za ním stojí jeden konkrétny cloud provider.
Lokálny backend musí byť prvotriedny občan.
S llama.cpp a KV cache sa k tomu systém posunul dosť výrazne.
Ako to dnes celé zapadá
Veľmi zjednodušene sa na dnešný OS Layer dá pozerať takto:
external world
│
gateway
│
integrations
│
┌───────────────────────────┐
│ Agents │
│ agent | codex | claude │
└─────────────┬─────────────┘
│
▼
┌───────────────────────────┐
│ Capabilities │
│ ai audio mail code ... │
└─────────────┬─────────────┘
│
▼
┌───────────────────────────┐
│ Core │
│ runtime layer secrets ... │
└─────────────┬─────────────┘
│
▼
Linux
Nie je to úplný dependency diagram.
Skôr mentálny model.
Capability poskytuje schopnosť.
Runtime vykonáva.
Layer dohliada na služby.
Secrets poskytuje credentials.
Gateway prijíma svet zvonku.
Integrations ho prekladá do interných služieb.
Agent skladá jednotlivé capabilities do vyšších workflow.
Board sleduje, čo sa deje.
Deploy dostáva systém na ďalší stroj.
A model backend môže byť cloudový alebo lokálny.
Platforma, ktorú môže používať aj AI
Jedna z pôvodných otázok OS Layeru bola:
Ako dať AI bezpečný a praktický prístup k schopnostiam operačného systému?
Odpoveď nebola postaviť celý operačný systém dovnútra jedného AI programu.
Bola postaviť vrstvu normálnych systémových komponentov, ktoré môže AI používať rovnako ako človek alebo automatizácia.
Dnes je táto myšlienka oveľa lepšie viditeľná:
human
shell script
automation
agent
codex
claude code
│
▼
OS Layer capabilities
│
▼
runtime / services / Linux / external world
AI je jedna z ciest do systému.
Nie celý systém.
A možno práve toto je najzaujímavejšia vec na dnešnom stave OS Layeru.
Nie to, že by sa jeho smer zásadne zmenil.
Ale že pôvodný smer prežil kontakt s realitou.
Pribudli desiatky komponentov.
Persistentné služby.
Agenti.
Externé integrácie.
Audio.
Vision.
Image generation.
Remote execution.
Trading.
Debugging.
MCP.
Webhooks.
Nový llama.cpp backend.
KV cache.
A lokálna inferencia sa z približne 50 dostala na 100–120 tokenov za sekundu.
A stále sa to celé dá skladať z malých samostatných častí.
To bol plán od začiatku.
OS Layer 2.x je moment, keď ho už začína byť vidieť celý.
