OAK (OpenSparX/MasterAgent): an open agent kernel for 100% on-device AI, with a proprietary runtime in the middle

The problem OAK targets: agent loops that phone home

Most agent frameworks assume a network. The model runs behind an API, tool calls are HTTP requests, and the orchestration loop lives in a process somewhere else. That assumption is fine for a chat product and wrong for a car, a robot arm or a medical device, where a round trip to a datacenter is either too slow or legally awkward. OAK, which the README calls the Open Agent Kernel and describes as "The Linux kernel for AI agents", is aimed at that second setting.

The pitch is a split execution path. According to the README's architecture diagram, a route decision sends roughly 80% of requests to a deterministic Skill Engine, measured there at 0.02ms, and the remaining 20% to local LLM inference, quoted at 87ms on an NPU and 1200ms on CPU. The claim is that most intent routing does not need a model at all, which is why the repository ships a demo mode that runs without one. The intended user is an embedded or automotive engineer who needs an agent that keeps working when the network does not, and who is willing to trade framework convenience for a C++ build and a hardware target.

What is actually open: five modules, one missing runtime

The README is unusually direct about this, and it is the single most important thing to understand before evaluating OAK. The repository uses an open-core model. The table in the README lists full source for Speculative Execution (LSTM plus HNSW, 2,565 LOC), Formal Plan Verification (CDCL SAT, 3,656 LOC), Agent Mesh (mDNS plus CRDT plus Merkle, 4,875 LOC), On-Device Learning (DP-SGD, 1,800+ LOC), Constrained Decoding (GBNF, 1,200+ LOC), the llama.cpp Model Runtime (527 LOC) and the Agent Scheduler (600+ LOC). Kernel Interfaces are published as headers.

Kernel Runtime is marked proprietary, and the README says it handles task orchestration, WAL recovery and agent dispatch. The stated rationale is that the strategic algorithmic modules are fully open and independently testable while the orchestration layer is not. The repository also says work is underway to open-source the runtime, tracked in issue #1.

That is a real boundary, not a marketing footnote. The architecture diagram shows a Task Orchestrator executing a DAG with WAL recovery and MCP services sitting between the skill engine and the response. If you clone this repository, you get the pieces on either side of that box and the headers that describe it. You do not get the box. Any evaluation of OAK as a complete agent system is therefore an evaluation of a promise plus a set of modules, and the modules are the part you can actually inspect.

How the mechanism works: deterministic routing, speculation, and a DAG

The data flow in the README runs top to bottom. User input goes through preprocessing (UTF-8 normalization, parameter extraction, memory), then a route decision splits deterministic from inference work. The Skill Engine handles the deterministic branch; LLM inference handles the rest. Both converge on the task orchestrator, which executes a DAG and produces the response.

Two design choices in that diagram deserve attention. The first is the ordering: pattern matching runs before the model, not after it. That is what makes the sub-100ms claim plausible for the common case, and it is also the source of the main failure mode, since a request that pattern matching misroutes never reaches the model that would have handled it correctly. The second is speculative execution, listed in the open-source table as LSTM plus HNSW. The README describes the intent as predicting the user's next intent and pre-computing during idle time, which is a latency trade: work done speculatively is wasted whenever the prediction is wrong, and the design only pays off if the prediction is right often enough.

The README also lists crash safety as a design principle, with a write-ahead log and three terminal states: COMMITTED, FAILED and UNKNOWN. That is a sensible state machine, and it is also entirely inside the proprietary component. The open repository contains the tests that exercise the strategic features, not the recovery path.

Building OAK from source and running the deterministic demo

The README gives the prerequisites as CMake 3.18+ and a C++17 compiler (GCC 9+ or Clang 11+). The short build command from the header clones the repository and configures a release build:

git clone https://github.com/OpenSparX/MasterAgent.git && cd MasterAgent
cmake -B build -DCMAKE_BUILD_TYPE=Release && cmake --build build -j$(nproc)

For a build that includes the CLI and the tests, the Quick Start section uses explicit flags instead:

cmake -B build -DCMAKE_BUILD_TYPE=Release \
      -DMASTER_AGENT_BUILD_CLI=ON \
      -DMASTER_AGENT_BUILD_TESTS=ON
cmake --build build -j$(nproc)

Then run the test suite, which the README's 30-second demo shows passing five tests: test_integration_speculation, test_orset, test_merkle, test_embedding and bench_strategic.

ctest --test-dir build --output-on-failure

If you want to see the agent respond without loading a model at all, the README provides a deterministic-only mode. The demo automotive command exercises the built-in skills:

./build/cli/sparx demo automotive

The README notes that most intent routing works without a model and only open-ended queries need inference, which is why this command produces output on a machine with no GGUF file present. To attach a real model, the README points at llama.cpp as a separate install and connects the CLI to a llama-server endpoint on port 8080:

llama-server -m your-model.gguf --port 8080
./build/cli/sparx run --endpoint 127.0.0.1:8080

The sparx binary is expected at build/cli/sparx, and the endpoint flag takes a host and port rather than a URL scheme.

The Alpha label, the unstable API, and the misrouted request

The README carries a status banner that says the core kernel is functional, the APIs are unstable, and contributions are welcome. Take that literally. Unstable APIs in a C++ project mean header churn, and if you build against the kernel interfaces today you should expect to recompile against changed signatures rather than assume source compatibility across releases. The release history is consistent with active churn: v2.1.6, v2.1.14 and v2.1.15 all landed within a few days of each other in August 2026, and the last push to main was 2026-09-09.

The second limitation is structural rather than temporary. Deterministic-first routing is a bet that your traffic is repetitive. In a vehicle cabin, where a small set of commands covers most interactions, that bet is reasonable. In a general assistant where users ask novel questions, the 80/20 split inverts, and every one of those requests pays the full inference cost the README quotes at 1200ms on CPU. If your workload is mostly open-ended, OAK's headline latency number describes a case you rarely hit.

There is also the hardware asymmetry. The README says you develop on CPU anywhere and deploy to a Qualcomm NPU for a quoted 14x speedup at 3.5x less power, with the same code on a different backend. That means the performance characteristics you observe during development are not the ones you ship, and the NPU path is the one you cannot fully validate without the target silicon.

OAK versus LangChain and AutoGPT: different assumptions, not different quality

The README's own comparison table puts OAK against LangChain, AutoGPT and Apple Intelligence. The useful way to read it is as a list of assumptions rather than a scoreboard. LangChain and AutoGPT are Python frameworks built around hosted model APIs; their strength is the breadth of integrations and the speed of getting an agent running, and their cost is a runtime dependency on a network and a provider. OAK inverts that: a C++ build, a hardware target, and no cloud calls, at the price of a much smaller ecosystem and a repository that does not contain its own orchestrator.

Apple Intelligence is the closer comparison on the axis that matters, since both run on-device with NPU acceleration. The difference is licensing and reach: Apple's stack is closed and tied to Apple hardware, while OAK is Apache-2.0 and targets Qualcomm NPUs, which puts it in automotive and embedded Linux territory rather than phones. If you are choosing between them, the question is not which is faster but which hardware you are shipping on.

Worth noting: the comparison table lists Crash recovery (WAL), Formal verification, Multi-device mesh, Speculative execution and On-device learning as OAK capabilities that the others lack. Four of those five live in the open modules, but WAL recovery is the one the README places in the proprietary kernel runtime, so the checkmark in that row is not something this repository lets you verify.

Licence, maintenance and what an upgrade costs you

The repository is Apache-2.0, which permits commercial use, modification and redistribution with the usual notice and patent-grant terms. The practical wrinkle is that Apache-2.0 covers what is in the repository, and the kernel runtime is not in the repository. If your product depends on the orchestrator, WAL recovery or dispatch, your dependency is on a separate proprietary component with its own terms, and the licence file here says nothing about it. That is a question for the vendor, not for the LICENSE file.

On maintenance, the evidence is a last push on 2026-09-09, three releases in August 2026, and an open issue tracking the runtime open-sourcing. That is a project moving quickly, which cuts both ways: fixes arrive, and so does API churn. The upgrade cost is concentrated in the interface headers and in whatever you build against the CLI's endpoint contract. Because the open modules are independently testable, a reasonable upgrade check is to rebuild and run the same five tests the README lists, then re-read the headers you compile against. The README does not document a rollback or version-pinning procedure, so if you need reproducible builds you will be pinning commits yourself.

Editorial conclusion

OAK is worth adopting if you are building an on-device agent for automotive, IoT or embedded hardware and you want to read, build and test the algorithmic core before committing to a vendor runtime. It is the wrong tool if you need a complete, stable agent framework this quarter: the README labels the project Alpha, the APIs are declared unstable, and the orchestration, WAL and dispatch layer is not in this repository. Before you build anything on it, clone the repo and run ctest --test-dir build to confirm the five open tests pass on your toolchain, then read the open-core table and issue #1 to see exactly which component you would be depending on that you cannot inspect.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. OpenSparX/MasterAgent on GitHub
3. Project website
4. README
5. Releases