OAK (MasterAgent): an open agent kernel where the runtime is not in the repo
Build AI agents that run 100% on-device. Sub-100ms latency on Qualcomm NPU. Zero cloud dependency.
At a glance
- What is it?
- OpenSparX/MasterAgent ships the algorithmic core of an on-device agent framework under Apache-2.0, but the orchestrator, WAL recovery and agent dispatch live in a proprietary kernel runtime. Here is what the repository actually contains and what it does not.
- Who is it for?
- OAK is worth cloning if you want to read or reuse the speculative execution, CDCL plan verification, CRDT mesh or DP-SGD learning code, all of which build and test from source under Apache-2.0. It is the wrong choice if you need an end-to-end on-device agent today, because task orchestration, WAL recovery and agent dispatch sit in the proprietary kernel runtime, and the README itself labels the project Alpha with unstable APIs.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 7 days ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem OAK targets: agent loops that phone home
Most agent frameworks assume a network call is available. The README positions OAK against that assumption directly, describing it as an agent kernel for builds that run 100% on-device with no cloud dependency, no network round-trip and no telemetry. The audience named by the repository topics is narrow and specific: automotive, embedded, IoT and edge deployments on Qualcomm hardware, plus anyone who needs inference to stay inside a device boundary for data-handling reasons rather than latency reasons. The homepage is opensparx.ai and the primary language is C++, which tells you the intended integrator is comfortable with CMake and a native toolchain, not a Python notebook. The README's own comparison table puts OAK beside LangChain, AutoGPT and Apple Intelligence and marks only OAK and Apple Intelligence as running fully on-device, with OAK the only open-source entry in that pair. That framing is the whole pitch: the same class of capability as a vendor-locked on-device assistant, but with source you can read. Whether the source you can read is the part that matters is the question this review keeps returning to.
What the open-core split actually excludes
This is the first thing to understand about the repository, and the README states it without hedging. OAK uses an open-core model. The table of components marks 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) as full source. Kernel interfaces ship as public API headers. The kernel runtime, described as orchestrator, WAL and dispatch, is marked proprietary with no LOC figure. The README explains the split as deliberate: the strategic feature modules are the algorithmic innovations and are independently testable, while the proprietary runtime handles task orchestration, WAL recovery and agent dispatch. It also points to issue #1 as the place tracking progress toward open-sourcing the runtime. Read the architecture diagram with that split in mind and you will notice the bottom box, the task orchestrator with DAG execution, WAL recovery and MCP services, is the part that is not in this repository. The diagram is a map of the product, not a map of the checkout.
How the request path is supposed to work
The architecture section gives a data flow worth restating precisely, because the latency claim depends on it. Input is preprocessed: UTF-8 normalization, parameter extraction, then memory lookup. A route decision then splits traffic, with the README stating that 80% of requests are deterministic and 20% go to inference. Deterministic requests hit the skill engine, which the diagram annotates at 0.02ms. The remaining fifth go to LLM inference, annotated at 87ms on NPU or 1,200ms on CPU. Both branches converge on the task orchestrator, which runs DAG execution with WAL recovery and MCP services, and the response comes back. The stated typical latency of 87ms is therefore an inference-path figure, not an average across all requests, and the README's own claim that 80% of requests resolve via pattern matching in microseconds is what pulls the blended number down. The README also notes that most intent routing works without a model loaded and that only open-ended queries need LLM inference. The WAL design is described as crash-safe with three terminal states: COMMITTED, FAILED and UNKNOWN. That third state is the interesting one, because it is an admission that a crash can leave a task in a position where the system cannot tell you what happened, which is a real constraint for anything with side effects.
Building the OSS half and running the CLI
The build path is ordinary CMake. Prerequisites listed are CMake 3.18+ and a C++17 compiler (GCC 9+ or Clang 11+). The one-line version from the README is: git clone https://github.com/OpenSparX/MasterAgent.git && cd MasterAgent, then cmake -B build -DCMAKE_BUILD_TYPE=Release && cmake --build build -j$(nproc). The fuller quick-start adds two flags, -DMASTER_AGENT_BUILD_CLI=ON and -DMASTER_AGENT_BUILD_TESTS=ON, and then ctest --test-dir build --output-on-failure. Those two MASTER_AGENT_BUILD_* keys are the only configuration surface the README documents. The 30-second demo shows five tests: test_integration_speculation, test_orset, test_merkle, test_embedding and bench_strategic, with the note that the OSS build compiles and tests the strategic features and that the full CLI with model inference requires the kernel runtime. For model-backed runs, the CLI connects to any llama-server compatible endpoint. The README's example starts llama-server -m your-model.gguf --port 8080, installed separately from llama.cpp, then runs ./build/cli/sparx run --endpoint 127.0.0.1:8080. There is also a model-free path: ./build/cli/sparx demo automotive, which exercises deterministic skills with no model loaded. Note the asymmetry: a local llama-server is still a separate process on the same machine, so the endpoint flag is a loopback connection, not a cloud one, and the on-device claim survives it only because the server is local.
Where OAK is the wrong tool
If you need a working on-device agent end to end, this repository does not give you one. The README says the full CLI with model inference requires the kernel runtime, and the kernel runtime is the proprietary piece. The Alpha status warning is explicit: core kernel is functional, APIs are unstable, contributions welcome. Unstable APIs plus a closed runtime is a difficult combination to plan a product around, because you cannot read the code that will change under you. The latency comparison table is also not independently checkable from this material. The 87ms typical figure, the 14x speedup and 3.5x power reduction on Qualcomm NPU, and the 2-5s figure attributed to LangChain are all README claims with no benchmark harness published in the open portion, and the open tests are correctness tests rather than latency benchmarks. Treat the NPU numbers as vendor-target claims until you measure them on your own silicon. A second limitation is hardware scope. The supported-hardware badge lists CPU and Qualcomm NPU. CPU is described as the development target and NPU as the production target, so if your deployment silicon is not Qualcomm, the production half of the value proposition does not apply to you. Finally, the deterministic-first design is a real constraint on the model, not just an optimization: 80% of traffic bypassing inference means the skill engine's coverage defines what your agent can actually do, and the README does not describe how skills are authored or extended.
How it differs from llama.cpp plus your own glue
The obvious alternative is llama.cpp directly, and the comparison is concrete rather than rhetorical. llama.cpp gives you model inference on CPU or GPU with a server mode, and OAK already depends on it for the model runtime, 527 LOC of it. What llama.cpp does not provide is a route decision in front of inference, a skill engine for the deterministic majority of requests, a DAG task orchestrator, WAL recovery with COMMITTED/FAILED/UNKNOWN terminal states, or multi-device mesh sync over mDNS, CRDT and Merkle trees. That list is what OAK adds, and it is also, notably, the list where the open and closed halves interleave: the mesh and speculative execution modules are open source, while the orchestrator and WAL are not. So the honest framing is that OAK is not competing with llama.cpp on inference quality. It is competing on the scaffolding around inference, and roughly the top half of that scaffolding is the part you cannot read. If your problem is purely running a model locally, llama.cpp alone is the smaller dependency. If your problem is routing, recovery and multi-device coordination, OAK's open modules are worth reading even if you never ship the runtime.
Maintenance, release cadence and licence terms
The repository is not archived and last push is 2026-09-09. Recent releases cluster tightly: v2.1.6 on 2026-08-10, then v2.1.14 and v2.1.15 both on 2026-08-12, the last of those roughly four weeks before the final push. That pattern of same-day patch releases suggests active iteration rather than a settled API, which is consistent with the Alpha warning and the unstable-API note. Upgrading across minor versions in that regime means expecting interface churn in the open modules, and you have no visibility into churn in the closed runtime. The licence is Apache-2.0, which permits commercial use, modification and redistribution with the usual conditions around notices and the patent grant. One caveat worth stating plainly: Apache-2.0 covers what is in the repository. The proprietary kernel runtime is not in the repository and is therefore not covered by that licence, so a build that depends on orchestration, WAL recovery or agent dispatch is depending on something whose terms are not stated in this material. If your product needs the runtime, that is a separate conversation with the vendor, and this review cannot tell you what those terms are. Do not read the Apache-2.0 badge as covering the whole product.
Who should clone this, and what to check first
Clone it if you are evaluating the algorithms. Speculative execution combining an LSTM with HNSW, CDCL-based SAT verification of agent plans, a CRDT mesh with Merkle reconciliation, DP-SGD on-device learning and GBNF constrained decoding are each independently testable from source, and the README states the OSS build compiles and tests exactly these. Five ctest targets give you a fast signal on whether the code does what it says. Skip it if you need a shippable on-device agent this quarter, or if your silicon is not Qualcomm and you were counting on the NPU path, or if you cannot accept a dependency whose orchestration layer is closed. The single most useful thing to check before investing time is issue #1, which the README names as the tracker for open-sourcing the kernel runtime. If it has closed and the runtime is published, the calculus changes substantially and the Alpha warning becomes the main risk rather than the licence boundary. If it is still open, plan around the split: build the open modules, run ./build/cli/sparx demo automotive to see the deterministic path without a model, and measure the 87ms and 14x figures on your own hardware before they appear in anyone's roadmap.
Editorial conclusion
OAK is worth cloning if you want to read or reuse the speculative execution, CDCL plan verification, CRDT mesh or DP-SGD learning code, all of which build and test from source under Apache-2.0. It is the wrong choice if you need an end-to-end on-device agent today, because task orchestration, WAL recovery and agent dispatch sit in the proprietary kernel runtime, and the README itself labels the project Alpha with unstable APIs. Before adopting, verify two things: whether issue #1 has closed with the kernel runtime published, and whether the sparx CLI you build against a llama-server endpoint can reach any of that orchestration code at all.
Community notes