One Agent, Every On-Device AI Stack: A Grounded Look at LyboAI Edge

On-device AI has quietly stopped being one thing. Android ships Gemini Nano, iOS exposes Apple's on-device foundation models, Windows runs Phi Silica on the NPU, and a large share of hardware in the field has none of the above. The usual result is that a team writes the same assistant three or four times, once per platform, and still has nothing for the offline case.

LyboAI Edge starts from the opposite premise: one governed agent that runs across every OS-native AI stack. Each platform's model is treated as a routing tier, not a rewrite — the runtime uses the native engine where it exists (zero download, NPU-fast, private) and falls back to its own built-in inference where it doesn't. Everything below is grounded in our developer docs at lyboai.app/developers/docs — the stack, the routing model, the trust model, and how you'd build one yourself.

Under every companion sits a layered runtime. Your app — Expo, React Native or native — talks to thin platform bindings (expo-lyboai, Swift, Kotlin), which cross into the core through lybo-ffi: a deliberately small four-function C ABI that speaks a JSON protocol. Behind that ABI is lybo-core, a Rust engine that holds the agents, workflows, middleware, model router, RAG and memory, policy-gated tools, pack management and encrypted storage.

The whole runtime executes on-device, per app instance. A request flows through middleware, intent routing, skill execution, policy-gated tools, then memory and trace persistence — and the host receives progress as a stream of events (agent.token, tool.awaitingApproval, checkpoint.created). An optional server, lybo-plane, handles the pack catalogue and entitlements, but the agent itself never depends on it to think.

Lybo OS is the layer that makes one agent portable. It treats each platform model as a normal routing tier — leveraging the OS engine where it exists, augmenting what the OS API lacks, and degrading gracefully where there's nothing. On Android that's os.android.nano (Gemini Nano, with structured output and prefix caching); on iOS, os.apple.afm (guided generation, tool calling, a Spotlight search tool); on Windows, os.windows.phi (Phi Silica on the NPU, with LoRA fine-tuning); and with no native engine at all, lybo.builtin runs full GGUF inference locally.

Selection happens through a cascade: deterministic rules for low-end or offline devices, a tiny intent classifier, small quantised models (1–8B), larger local models on capable hardware, and only then — privacy permitting — a cloud fallback. The point of the design is stated plainly in the docs: agents, skills, workflows and packs never change when models do. You can even attach any engine that speaks one JSON object per line — llama.cpp, Ollama, or a custom bridge — via --model-cmd, and model downloads are resumable, SHA256-checked and storage-pressure gated.

Capabilities ship as packs: a pack is one signed JSON document that can add skills, workflows, knowledge, prompts, policies and eval suites — and, critically, packs never contain executable code. That single constraint is what makes over-the-air updates safe. Each pack's content is hashed with SHA256 and the manifest signed with ed25519; a device installs it only if the publisher's key is already trusted, and verifies the hash and signature locally before anything registers.

The rest of the safety model is similarly concrete. Storage is encrypted with ChaCha20-Poly1305 using keys drawn from the device keychain. Every tool call runs a fixed pipeline — permission, policy, schema, confirmation, execute, audit — and human approvals are single-use, survive app restarts, and never let a call skip the checks it would otherwise face. Workflows carry step budgets and agent loops carry iteration caps, so a runaway process fails safely rather than spinning. And every routing decision, tool call and repair is written to a glass-box trace chain you can verify (verify_trace_chain).

The same building blocks scale past a single phone. Lybo OS describes three tiers that share one agent definition. Edge devices — handhelds running OS-native or tiny models under roughly 1.5B — handle voice-to-text, form filling, urgency flagging and structuring messy input into clean JSON. Node machines — a site or vehicle PC running quantised 3–14B models with a local vector database — do regional RAG over manuals and assets, plus aggregation, dedupe and summarisation. Core — a cloud hub with frontier models behind adapters — handles cross-fleet reasoning, anomaly detection and compliance.

Between tiers, data moves by store-and-forward: structured deltas queue locally and trickle up when bandwidth allows, with redaction at every egress boundary. Media crosses boundaries by reference — a content-hash id and path, never inlined base64 — with EXIF scrubbed before hashing.

None of this requires a GPU, an API key or a network to try. The quickstart runs ./scripts/try.sh and opens Studio — the same runtime that ships in production apps — on 127.0.0.1:4242; add --with-llm and it ships a small Qwen model for real inference. A first agent is a handful of declarative calls: install some knowledge, register a skill that binds trigger phrases to one of six execution patterns (from simple_chat and retrieval to a policy-gated react_tool_use), and define a workflow as a JSON state graph with a confirm step for human approval.

For teams who'd rather not touch Rust, the Cloud Canvas in Edge Studio does design, validation, the eval gate, Try-it simulation, signing and OTA publishing in the browser — and the eval gate has to be green before a pack can be signed. SDKs cover TypeScript, Python and Expo, so the same agent you prototype in the browser is the one that ships to the device.