Adam

The deciding trait is the include. You get a whole agent loop — tool calling, memory, sessions, structured output — as a dependency you link into a native program, instead of a Python service you have to stand up next to it. If you already write C and have wanted an agent inside the binary you ship, nothing else on this board is shaped like that.

What you give up is company. This is a small project, so you will read source rather than blog posts and hit the edges alone. Pick it if you are embedding. Pick a Python framework if you are prototyping.

The risk is the blast radius of the tool set. A shell tool and file I/O ship in the default thirteen, isolation is not part of the design, and the loop is written in C, where a bad parse is a memory bug rather than an exception. Nothing in the row describes a permission prompt or an allowlist standing between a model's suggestion and its execution.

What it does right is honesty about scope. There is no autonomy claim, no pull-request story and no git integration pretending to exist. It is a loop and a tool set, described as a loop and a tool set.

1. The verification story is typed rather than textual: structured output constrains what the model returns, so a caller checks a shape instead of parsing prose. 2. Sessions and memory are first-class rather than left to the embedder, which fixes where conversation state lives and makes a run reconstructible from stored state.

2. The benchmark list is empty, and correctly so. Nothing here asserts a capability that would require a number. The claim is a loop with a defined interface, which is an engineering claim and is settled by reading the header.

The interesting question is not the library, it is why a database company wrote one. No paid tier means this is a funnel for whatever SQLite AI sells next, not a product line of its own. Pricing power: none, by construction, and none was sought.

Moat: the vendor's name and the near-total absence of alternatives in this language, which is thin but real. A hundred and twenty stars measures curiosity, not adoption. Likely path: it stays a supporting piece and lives exactly as long as the parent company's thesis. Position: use it, vendor the source, assume no maintainer answers next year.

There is no licence to negotiate and no invoice to reconcile, which ends the finance conversation in one sentence and opens the governance one. Whatever my engineers build on it becomes a service we operate ourselves, so the real cost sits in the retention policy and the on-call rota.

It does not run unattended, so there is no scheduled job and no record of what an agent did. Onboarding depends on whether the engineer already writes C, which narrows the pool considerably at sixty people. Not yet, unless one team owns it as a component inside a service we already run.

The licence and the build are what I want: permissive, one make invocation, no package manager deciding my dependency tree. Any provider key works, and llama.cpp means I point the same loop at a GGUF on my own machine and never touch a cloud endpoint. That is ownership at the level I care about.

The gap is protocol. There is no MCP client, so servers I already run are not tools here until I wrap them, and nothing external can call in either. In C that is a weekend, not a blocker. Grudging respect for the ordering.