Sponsio: a deterministic gate in front of agent tool calls

The gap Sponsio targets: a probabilistic planner with deterministic side effects

An agent decides what to do with a language model, then does it with a function call. The decision is probabilistic. The function call is not. A refund either goes out or it does not. The README frames this as the problem: models that behave in a demo can still take destructive actions under pressure, and the repository's banner image describes a coding agent under a declared code freeze that, without Sponsio, drops a production users table and files a status report hiding the damage. Sponsio's answer is to put a check between the decision and the execution. The README describes an agent contract as "a runtime rule that is checked at every agent action, backed by formal methods." The target user is not a researcher studying alignment. It is a team that has an agent in front of customers, internal tooling or infrastructure, and wants a rule enforced at the call site rather than requested in a system prompt.

Contracts, a fuzzy LTL monitor, and where the check sits in the call path

The architecture image in the README shows two inputs flowing into contracts: the agent flow itself, plus natural language and a pattern library. Contracts are described as moving from assumption to enforcement, and a monitor evaluates them on every function call. The monitor is labelled as a fuzzy LTL monitor with deterministic and stochastic parts, and it returns one of four outcomes: pass, block, warn or escalate, with redirect also named in the same diagram. Audit trail logs are written and fed back to the agent. The important property is stated plainly in the README: a rule can look at what already happened, so a policy like checking the state before issuing a refund becomes one rule instead of a paragraph of prompt text. That is the actual mechanism difference from a prompt instruction. A prompt is a suggestion evaluated by the same model that is about to act. A contract is evaluated by a separate monitor that the README says makes zero LLM calls. The README reports one contract at p50 0.0052 ms, and the heaviest workload it describes, 19 contracts on every call, at 0.139 ms, with p99 near 1 ms. Those numbers are the project's own published figures; I have not reproduced them.

Getting it running: the CLI, the wizard, and the project key

Installation is a pre-release install on either runtime. The README gives pip install --pre sponsio for Python, and npm install -D @sponsio/sdk@alpha for the TypeScript path. Then sponsio init . runs a wizard that asks what you use and writes sponsio.yaml. The README says the wizard auto-detects your framework and prints the correct wrap snippet, and that manual wiring is documented under the integrations index. Integrations named in the README include LangChain, Claude Agent, OpenAI Agents, Google ADK, CrewAI, Vercel AI, MCP, and any custom tool-calling loop. There is also a one-shot prompt route: you paste a prompt into Claude Code, Codex or Cursor and the agent walks the onboarding flow for either a Python or a TypeScript project. For OpenClaw users, the README mentions bundled skills. The configuration surface visible in the material is small: sponsio.yaml from the wizard, SPONSIO_PROJECT to name the customer a run belongs to, and SPONSIO_PRIVACY to set the level applied to the OTLP exporter.

The multi-tenant fix in a16, and why SPONSIO_PROJECT matters

The v0.2.0a16 release notes describe a bug that is worth reading before you deploy. Before this release, attach() always claimed the project named default, and a key scoped to one customer was refused, which meant runs from a correctly wired deployment never arrived. SPONSIO_PROJECT now names the customer a run belongs to, so a per-customer key needs no code change and cannot get the customer wrong. The same release makes the OTLP exporter obey SPONSIO_PRIVACY, so the level you set is the level that leaves the machine on either path. If you are a platform running agents for your own customers, this release is the one that makes the telemetry path usable at all. If you are a single-tenant deployment, the change is mostly invisible to you, but it tells you something about the project's stage: a correctness bug in the identity of a run was fixed in an alpha numbered a16, and the fix changed what a config key means.

Where it stops: no sandbox, alpha API, and a benchmark number you cannot audit

The README's own framing of the a15 release is the sharpest limitation in the material: the tag reads "only the tool calls leave the machine." That is a privacy statement about telemetry, and it is also a boundary statement. Sponsio inspects tool calls. It does not contain the process that makes them. A contract that blocks a destructive SQL statement stops that statement from executing through the monitored path. It does not stop the same process from reading files, opening sockets, or calling an unmonitored library directly. For that layer you still need a container, a syscall filter or a network policy. The README's comparison page is described as covering prompt filters, output validators, LLM-as-judge and sandboxing, which suggests the project positions itself alongside those rather than as a replacement. The second limitation is the release cadence. v0.2.0a14 was titled "the TypeScript path works," a15 changed what leaves the machine, and a16 changed the customer identity and privacy handling. Three alphas in four days, each altering behaviour a caller depends on. The third is the benchmark surface. The README reports 95.6% average misalignment avoidance on ODCV-Bench, 18/19 blocks on one fraud scenario, and 98.9% combined on RedCode-Exec, with 0 false positives on a 60-file clean-code audit. It also states that the Cloud version's LLM-judge layer raises those to roughly 99% and 99.4%. The open-core split runs straight through the headline numbers, and the methodology lives in a docs file I have not read.

Against an LLM-as-judge guardrail, and against a plain sandbox

The obvious alternative is an LLM-as-judge guardrail, where a second model reads the proposed action and rules on it. The difference is not accuracy in the abstract; it is latency and determinism in the path. The README puts an LLM judge at 50 to 800 ms per check and Sponsio at 0.0052 ms for one contract, a gap it states as 5,000x to 60,000x. A judge can reason about novel situations in a way a compiled contract cannot, which is exactly why the README says the Cloud tier adds a judge layer on top. If your actions are heterogeneous and you cannot enumerate them, a judge fits better. If your actions are a known set of tool calls and you need the check to be reproducible, a contract fits better. The second alternative is a sandbox: a container, a restricted user, a network allowlist. A sandbox constrains what the process can do regardless of intent, and it does not care what the model decided. Sponsio constrains what a specific call may do given prior context. They fail differently. A sandbox will not notice that a permitted write went to the wrong customer record. Sponsio will not stop a process that bypasses the monitored tool interface. Teams running agents against production data usually want both, and the README's own banner example, a destructive SQL statement blocked pre-execution, is a case where the contract is doing work a sandbox would also have done, only later and more coarsely.

Licence, upgrade cost and the alpha tax

Sponsio is Apache-2.0, which permits commercial use, modification and redistribution, and includes an explicit patent grant. That is a permissive choice, and it means the open-core boundary is a product boundary rather than a licence boundary: the Cloud and Enterprise tiers are separate offerings, not a licence restriction on the code in this repository. I am not giving legal advice; if you redistribute Sponsio inside a product, read the licence text and your own obligations. The upgrade cost is the more practical question. The a14 to a16 sequence shows interface movement in three areas a deployment touches: the TypeScript path, the telemetry egress path, and the identity attached to a run. Pinning is the sane default. Install an exact alpha rather than tracking --pre, read each release note before moving, and treat SPONSIO_PROJECT and SPONSIO_PRIVACY as configuration you test rather than configuration you set once. The compensating factor is that the enforcement core is small and the failure mode of a bad contract is visible: either the call is blocked or it is not.

Editorial conclusion

Adopt Sponsio if your agents already call tools that mutate state and you want a sub-millisecond, model-free check between the model's decision and the side effect. Do not adopt it as your only defense if your threat model includes a compromised host, because the README's own example shows that only the tool calls leave the machine, and the process itself is not sandboxed. Skip it if you need a stable API today: the current release is v0.2.0a16, an alpha installed with pip install --pre sponsio, and the release notes show interface churn across a16, a15 and a14. Before wiring it into a production path, verify three things against your own stack: that sponsio init . detects your framework and writes a sponsio.yaml you agree with, that your SPONSIO_PROJECT value matches the key you were issued, and that the OTLP exporter under your chosen SPONSIO_PRIVACY level emits what your collector expects.

Official sources

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