AI core v Ruste, runtime policy a otvorené dvere cez MCP

Za posledné dni sa OS Layer posunul výraznejšie než za celé predchádzajúce týždne. Nie preto, že by sa zmenila základná architektúra. Práve naopak.

Základná požiadavka bola od začiatku jasná: systém musí byť modulárny, nezávislý, postavený z jednoduchých primitív a bez pevnej väzby na jeden model, provider alebo framework.

To sa teraz začína naplno vyplácať.

OS Layer dnes dokáže kombinovať lokálne aj cloudové modely, vlastné capability moduly, pôvodné shellové tools a externé MCP servery. Všetko pritom prechádza cez vlastný runtime, vlastnú policy vrstvu a jednotný execution model.

AI core je po novom v Ruste

Pôvodná shellová implementácia AI vrstvy splnila svoju úlohu. Umožnila rýchlo overiť celý koncept, experimentovať s providermi, tool callingom, promptami aj agentickým loopom.

Postupne sa však ukázalo, že hot path potrebuje kompaktnejšie a výkonnejšie jadro.

Nový AI core je preto napísaný v Ruste.

Rustová implementácia zabezpečuje:

• komunikáciu s model providermi,

• streaming odpovedí,

• tool calling loop,

• discovery dostupných nástrojov,

• dispatch cez runtime,

• spracovanie výsledkov toolov,

• metriky výkonu,

• token usage,

• TTFT,

• tool execution time,

• detailný realtime event stream.

Výsledkom je výrazne rýchlejší a predvídateľnejší klient bez množstva pomocných procesov, dočasných súborov a opakovaného parsovania cez externé utility.

Shell z OS Layera nezmizol. Stále zostáva ideálnym jazykom pre jednoduché capability moduly a primitíva. Rust iba prevzal časti, kde dáva zmysel výkon, bezpečné spracovanie dát a dlhodobo bežiaci proces.

Architektúra teda nie je:

shell → Rust

ale:

shell primitives
+
Rust core
+
Rust runtime

Každá vrstva robí to, na čo je najvhodnejšia.

Jeden AI klient, viac providerov

AI core nie je naviazaný na jeden model.

Aktuálne môže používať napríklad:

Ollama
OpenAI-compatible API
OpenAI API
lokálny model
vzdialený model

Model môže bežať priamo na zariadení, na desktope, na inom serveri alebo v cloude.

OS Layer zostáva orchestrátorom.

AI klient
→ model provider
→ rozhodnutie
→ tool dispatch
→ runtime
→ výsledok
→ model

Provider je v tomto systéme iba vymeniteľný modul. Zmena modelu neznamená zmenu runtime, toolov ani capability vrstvy.

Runtime sa stal skutočnou execution vrstvou

Runtime už nie je iba jednoduchý spúšťač príkazov.

Dnes rieši:

• capability registry,

• povolené entrypointy,

• povolené funkcie,

• argumenty procesu,

• execution policy,

• approvals,

• timeouty,

• procesné limity,

• udalosti,

• stav,

• izoláciu jednotlivých capability modulov.

AI model teda nikdy nemusí dostávať priamy prístup k systému.

Namiesto toho vytvorí tool call:

capability
entrypoint
function
arguments

Runtime následne rozhodne, či je daná operácia povolená a ako sa má vykonať.

Základný princíp je jednoduchý:

AI rozhoduje
runtime kontroluje
policy povoľuje
capability vykonáva

Toto oddelenie je kľúčové. Model môže byť lokálny, cloudový alebo úplne vymenený, no oprávnenia a execution policy zostávajú pod kontrolou OS Layera.

Tri typy toolov, jedno rozhranie

AI dnes vidí všetky dostupné nástroje cez jednotnú tool schému:

name
description
JSON parameters

Pod touto jednotnou vrstvou však môže byť viacero spôsobov vykonania.

Legacy tools

Legacy tools sú jednoduché shellové primitíva, ktoré už v systéme existovali.

Napríklad:

cat
grep
find
tree
write_memory
web_search

AI ich volá cez runtime a spoločný tool bridge.

Sú vhodné pre malé, transparentné a ľahko kombinovateľné operácie.

Native capabilities

Komplexnejšie moduly môžu byť priamo capability systému.

Napríklad:

rss
mail
render
deploy
remote
wireguard
crypto

Tie už môžu poskytovať viac funkcií, vlastnú konfiguráciu, stav a policy.

MCP

MCP je tretí dispatch provider.

Nie je to nový základ OS Layera a nie je to náhrada vlastných capability modulov. Je to ďalší provider, ktorý sprístupňuje externé tools cez štandardizovaný protokol.

tool schema
→ dispatch provider
→ legacy | capability | MCP
→ normalizovaný výsledok
→ model

Práve preto MCP zapadlo do systému bez nutnosti meniť základnú architektúru.

OS Layer bol od začiatku navrhnutý modulárne. MCP iba pribudlo ako ďalší modul.

MCP otvorilo dvere do existujúceho ekosystému

Pred MCP platilo:

čo si napíšem, to agent vie

Po pridaní MCP platí:

čo existuje ako MCP server, to môžem pripojiť

To dramaticky mení rýchlosť rozširovania systému.

Nie je nutné implementovať každú integráciu od nuly. Stačí pripojiť vhodný MCP server a AI si dynamicky načíta jeho tools cez discovery.

MCP klient v OS Layeri podporuje:

• initialize,

• tools/list,

• tools/call,

• resources,

• prompts,

• ping,

• stdio transport,

• Streamable HTTP transport.

Nástroje z MCP servera sa automaticky preložia do rovnakej schémy, akú používajú interné tools.

Model preto nemusí vedieť, či volá:

shellový tool
natívnu capability
externý MCP server

Vidí iba nástroj, popis a parametre.

Dispatch ostáva internou záležitosťou OS Layera.

MCP cez HTTP a WireGuard

Najzaujímavejší model nie je nutne lokálny MCP server na rovnakom zariadení.

OS Layer môže bežať napríklad v Termuxe na mobile, zatiaľ čo MCP servery bežia na desktope.

mobil
→ WireGuard
→ desktop
→ MCP server

Desktop môže poskytovať:

• filesystem,

• browser automation,

• databázy,

• dokumenty,

• Git repozitáre,

• výpočtové nástroje,

• lokálne modely,

• ďalšie externé integrácie.

Mobil zostáva ľahkým klientom a orchestrátorom.

Vďaka WireGuardu nemusia byť MCP servery vystavené na verejný internet. Môžu počúvať iba na privátnej VPN adrese.

Termux AI
→ privátna WireGuard sieť
→ desktop MCP endpoint
→ výsledok späť do mobilu

Tento model sa podobá cloudovým API, ale infraštruktúra zostáva súkromná a plne pod kontrolou používateľa.

Recovery loop už funguje

Tool calling už nie je iba jednorazové zavolanie príkazu.

Model dokáže reagovať na chybu, upraviť argumenty a pokračovať.

Pri filesystem MCP serveri napríklad prvý pokus smeroval na:

/

Runtime a MCP server prístup odmietli, pretože povolený bol iba konkrétny adresár.

Model následne použil správnu cestu:

/home/pihi/os_layer

a získal obsah rootu projektu.

MCP call
→ access denied
→ model opraví cestu
→ nový MCP call
→ úspešný výsledok
→ finálna odpoveď

To už nie je iba tool execution. Je to základný agentický recovery loop pod kontrolou policy.

Pozorovateľnosť je súčasť architektúry

AI klient dokáže po každom rune zobraziť:

• model,

• provider,

• endpoint,

• celkový čas,

• TTFT,

• viditeľný TTFT,

• rýchlosť generovania,

• tool execution time,

• token usage,

• veľkosť kontextu,

• počet tool rounds,

• počet volaní,

• argumenty,

• dispatch typ,

• runtime target,

• argv,

• výsledok alebo chybu.

To výrazne zjednodušuje debugging.

Namiesto hádania je viditeľné:

čo model zavolal
prečo to neprešlo
kam to runtime dispatchol
aké argumenty dostal proces
koľko celé vykonanie trvalo

AI core zároveň produkuje realtime udalosti pre Board, ktorý sa postupne mení na plnohodnotný debugger agentického behu.

Cieľom nie je iba zobraziť finálnu odpoveď, ale celý priebeh:

thinking
content
tool call
arguments
runtime dispatch
stdout
stderr
error
ďalšie rozhodnutie
finálna odpoveď

Modularita nebola výsledok. Bola požiadavka.

Dôležité je, že OS Layer neprešiel z monolitu na modularitu.

Modularita bola základná požiadavka od začiatku.

Vývoj vyzeral skôr takto:

modulárny základ
→ silnejšie spoločné rozhrania
→ tenšie capability moduly
→ výkonnejší runtime
→ viac dispatch providerov

Prvý tool mohol obsahovať viac integračného kódu, no stále bol samostatným modulom s jasnou rolou.

Postupne sa iba opakované časti presunuli do spoločných vrstiev:

• provider komunikácia do AI core,

• execution do runtime,

• oprávnenia do policy,

• discovery do registry,

• externé integrácie do MCP provideru.

Výsledkom je systém, kde nový protokol alebo nový provider nevyžaduje prepis jadra.

Stačí pridať ďalší modul.

OS Layer dnes

Aktuálny model systému možno zhrnúť takto:

Model providers
├─ Ollama
├─ OpenAI-compatible API
└─ OpenAI API

AI core
├─ streaming
├─ tool loop
├─ discovery
├─ metrics
└─ event stream

Tool providers
├─ legacy tools
├─ native capabilities
└─ MCP

Runtime
├─ registry
├─ dispatch
├─ policy
├─ approvals
├─ limits
└─ events

Execution targets
├─ lokálne zariadenie
├─ desktop
├─ VPS
└─ vzdialené MCP servery cez WireGuard

OS Layer tak zostáva nezávislý od konkrétneho modelu, konkrétneho tool ekosystému aj konkrétneho zariadenia.

Model je vymeniteľný.

Tool provider je vymeniteľný.

Execution backend je vymeniteľný.

Runtime a policy zostávajú vlastné.

Čo sa tým reálne zmenilo

Najväčšia zmena nie je iba technická.

Zmenila sa rýchlosť, akou môže systém získavať nové schopnosti.

Predtým:

nápad
→ implementácia toolu
→ API integrácia
→ parser
→ wrapper
→ debug
→ nasadenie

Dnes často stačí:

nápad
→ pripojenie MCP servera
→ tools/list
→ hotovo

Vlastné capability moduly stále majú zmysel tam, kde je potrebná presná kontrola, špecifická policy alebo úzka integrácia s OS Layerom.

MCP však otvára cestu k obrovskému množstvu hotových nástrojov bez toho, aby OS Layer stratil vlastnú identitu alebo kontrolu.

A práve tu sa naplno ukazuje hodnota pôvodného návrhu.

Keď sa objavil nový protokol, systém sa nemusel prerábať.

Pribudol iba ďalší provider modul.

Záver

OS Layer sa za posledné dni posunul z experimentálneho agentického runtime na reálne použiteľnú distribuovanú platformu.

AI core v Ruste priniesol výkon a pozorovateľnosť.

Runtime policy priniesla kontrolu.

Capability systém zachoval modularitu.

MCP otvorilo dvere do externého sveta.

WireGuard umožnil bezpečne prepojiť mobil, desktop a VPS.

Výsledkom je systém, v ktorom môže inteligencia bežať kdekoľvek, tools môžu bežať kdekoľvek, ale orchestration, execution pravidlá a kontrola zostávajú v OS Layeri.

AI rozhoduje.
Runtime kontroluje.
Policy povoľuje.
Capabilities vykonávajú.
MCP pripája svet.
OS Layer zostáva centrom.