Workflow
01plan
decompose · 4 sub-tasks
02retrieve
den · 4 hops · 28ms
running
03tool · fs.write
src/auth/login.tsx
04generate
composer-2 · 312 tok
05eval
correctness · safety
Foxora Engine is the agentic runtime baked into Foxora OS. Every agent on the device — Vixen, your custom workflows, the ones extensions ship — runs through a single scheduler with a single capability model, a single memory bus, and a single eval surface. Frameworks like Mastra and LangChain sit above an OS. Engine sits inside one.
SDKs · TypeScript · Python · Rust
Everything an agent needs to reason, act, remember, and be graded — in a single OS-level surface that any extension can target.
Spawn, suspend, snapshot, and resume agents like the kernel handles processes. Every agent runs under a capability set that scopes what it can read, write, and call.
Plan → retrieve → tool → generate → eval. Workflows are first-class graphs with typed edges, retries, branching, and human-in-the-loop gates baked in.
Engine speaks MCP and exposes the OS itself as tools — fs, shell, browser (via Eye), kits, and any extension that registers a manifest. Capabilities decide who can call what.
No bring-your-own vector store. Engine pipes context through Foxora Den's locus algebra and provenance DAG — every recall, every write, every trail is auditable end-to-end.
Correctness, safety, reasoning, latency. Evals run inline against the same workflow and surface as scores in the dock — never as an afterthought you wire up later.
Engine is the single integration point. Extensions register agents, tools, evals, or memory hooks against it — and immediately work everywhere on the OS.
Why Engine isn't another agent framework — and what changes when the runtime is part of the OS instead of bolted to it.
Engine ships inside Foxora Desktop. Install once and the runtime, the SDKs, the tool registry, and the eval surface all show up together — no glue code, no vendor lock-in.