Inteligencia nie je len LLM. Je to aj software okolo neho.

Dlho som mal z praxe pocit, že pri AI agentoch sa príliš veľa pozornosti venuje samotnému modelu.

Koľko má parametrov. Aký má benchmark. Koľko tokenov zvládne. Či je o pár percent lepší než minulá verzia.

Lenže pri reálnom používaní som postupne dochádzal k inému záveru:

Schopnosť agenta nie je iba vlastnosť LLM. Veľká časť jeho praktickej inteligencie vzniká v softvéri okolo neho.

Model potrebuje dostať správny kontext, správne knowledge, správne nástroje a primitíva na správnej úrovni abstrakcie. A zároveň musí existovať vrstva, ktorá kontroluje, čo sa z jeho rozhodnutí naozaj vykoná.

Presne na tomto princípe vzniká OS Layer.

Jeho úloha nie je robiť LLM „múdrejším“ ďalším kilometrovým system promptom.

Jeho úloha je vytvoriť prostredie, v ktorom model nemusí byť múdry tam, kde to vie deterministicky vyriešiť software.

LLM
│
├─ Context → čo má model vedieť
├─ Skills → procedural knowledge
├─ Tools → čo môže model požadovať
├─ Runtime → čo sa skutočne smie vykonať
├─ Policy → permissions / approvals
└─ Components → deterministická implementácia

Jeden malý experiment

Chcel som, aby lokálny GPT-OSS 20B iba overil, či sa Rust komponent capabilities/ai skompiluje.

Prompt bol jednoduchý:

Skontroluj, či capabilities/ai kompiluje.
Použi knowledge a model-facing development tools dostupné
v tomto projekte.
Vráť mi presné compiler diagnostics a nič neopravuj.

Model mal k dispozícii nový high-level primitive:

rust_check

Prvý pokus dopadol katastrofálne.

Model okamžite správne zavolal:

{
"path": "capabilities/ai"
}

Lenže tool contract požadoval absolútnu cestu.

Výsledok:

15 tool calls
15 rounds
105.8 sekundy

Model začal hľadať projekt, skúšal relatívne cesty, /home/pihi/.local, dokonca /, kde search dvakrát timeoutol.

Na prvý pohľad by sa dalo povedať:

Model je hlúpy.

Lenže to by bola nesprávna diagnóza.

Jeho úplne prvé rozhodnutie bolo správne.

Chybný bol software okolo neho.

Opravili sme prostredie, nie model

OS Layer dostal jednoduchý execution-context kontrakt.

Caller pošle Runtime svoj workspace:

/home/pihi/os_layer

Runtime stále spúšťa Component vo vlastnom izolovanom adresári, ale zároveň mu poskytne:

OS_RUNTIME_CALLER_CWD=/home/pihi/os_layer

Takže:

capabilities/ai

sa deterministicky vyrieši ako:

/home/pihi/os_layer/capabilities/ai

Model sa nezmenil.

Prompt sa nezmenil.

Rust compiler sa nezmenil.

Zmenil sa iba software okolo LLM.

Výsledok

Ten istý benchmark som následne pustil päťkrát.

Výsledok bol zakaždým:

1 round
1 tool call

rust_check {
"path": "capabilities/ai"
}

exit_code: 0
diagnostics: []

Časy:

4.664 s
3.759 s
4.966 s
3.590 s
5.257 s

Priemer približne:

4.45 sekundy

Z pôvodných:

105.8 s / 15 calls

sme sa teda dostali na:

4.45 s / 1 call

Približne 24× kratší wall time.

Bez väčšieho modelu.

Bez prompt engineeringu.

Bez hardcoded workflow.

Bez fine-tuningu.

Model zrazu vyzerá múdrejší

A pritom nie je.

To je podľa mňa dôležitý rozdiel.

predtým:

LLM → správne rozhodnutie
↓
zlý primitive
↓
recovery reasoning
↓
chaos

Po úprave:

LLM → správne rozhodnutie
↓
správny primitive
↓
deterministická execution
↓
výsledok

Model nemusí premýšľať nad tým, ako funguje filesystem layout OS Layeru.

Nemusí hádať absolute path.

Nemusí vedieť presnú syntax cargo check.

Nemusí parsovať stovky riadkov compiler outputu.

Jeho úloha je:

„Potrebujem overiť Rust projekt.“

A software mu poskytne operáciu presne na tejto úrovni:

rust_check

Čím menej musí model vedieť, tým menej môže pokaziť

To je paradox, ktorý sa mi pri vývoji OS Layeru objavuje stále častejšie.

Silnejší agent nemusí nevyhnutne znamenať model, ktorému dáme ešte viac možností.

Často je lepšie zobrať modelu zbytočnú mechaniku.

Namiesto:

spusti shell
nájdi Cargo.toml
vyber cargo
zostav argv
spusti proces
parsuj stderr
pochop exit code

dostane:

rust_check(path)

Model rozhoduje čo.

Software rozhoduje ako.

Runtime rozhoduje či sa to smie.

A tu začína byť zaujímavý aj malý model

Toto celé nie je iba optimalizácia GPT-OSS 20B.

Už predtým sme podobný jav videli pri skill routingu.

Keď mal model spraviť:

vyber skill
→ načítaj SKILL.md
→ pochop, ktorý reference dokument potrebuješ
→ zavolaj tool druhýkrát

8B model druhý reasoning hop často neurobil.

Po zmene primitive na:

skill_load(
name="component-v2",
route="architecture"
)

rovnaký model začal správny workflow robiť stabilne jedným callom.

Dokonca 0.6B model už dokázal v časti behov správne vybrať celý skill + route.

A to je moment, keď začne byť zaujímavá otázka:

Koľko „inteligencie“ skutočne musí byť vo weights a koľko jej môžeme presunúť do architektúry systému?

Moja pracovná hypotéza

Čím ďalej OS Layer staviam a používam, tým viac mi sedí približne toto:

effective agent intelligence
≠
LLM intelligence

Skôr:

effective agent intelligence
≈
model capability
×
environment quality

Zlé prostredie vie veľmi schopný model utopiť v mechanike.

Dobré prostredie vie výrazne zvýšiť praktickú schopnosť menšieho modelu.

A veľmi dobrý model v kvalitnom prostredí?

To bude ďalší experiment.

Preto je pre mňa GPT-OSS 20B momentálne referenčný model OS Layeru. Je to najväčší model, ktorý sa mi ešte rozumne zmestí lokálne, a zároveň je dostatočne schopný na to, aby ukázal, kde už končí problém infraštruktúry a začína limit samotného reasoning engine.

Ďalší krok bude vo VM.

Dostane rozbitý Rust projekt, development tools a jednoduchú úlohu:

Oprav to.
Dokáž, že to funguje.
Skonči.

A potom uvidíme, čo sa stane.

Možno si opraví celý projekt.

Možno podpáli VM.

V oboch prípadoch to bude dobrý benchmark. ????