Sparsi packages repeatable multi-step tasks into deterministic-first MCP tools. It replaces costly, multi-call reasoning loops with a single call to a composed workflow, maximizing determinism to reduce token usage and completion time by handling routines in code and saving raw reasoning for the unique cases that actually need it.
Workflows orchestrate services in any language. You design them in plain English and the codegen skills generate the Sparsi program — the Go runtime ships today, with more authoring runtimes (TypeScript next) on the roadmap.
Skill users:
try /sparsi-design and /sparsi-codegen — AI-assisted workflow design & codegen in your editor.
Get started →
The difference between an interpreter and a compiler is when the work happens — on every run, or just once. Today's agents are interpreters: they re-derive the same routine on every request. Sparsi gives them the build step they never had.
The plan is re-derived every request. Your system
prompt, your installed skills, your MCP servers — those stand still.
The plan built on top of them does not: your agent takes the same
goal and stitches the routine together from primitives —
search, fetch, read,
write, call — from scratch, every time it
runs. No plan carries over between runs. So every time a user asks
"where's my order?" the routine is built fresh, and you pay
the reasoning cost again in tokens, in latency, and in a fresh chance
to get it wrong.
Authored once, then replayed. A compiler pays the stitching cost a single time, at build time, and every run after gets the result for free. Sparsi is that build step for agents: you author the routine once — classify the ask, route through the right channel, hit your systems in order, write the reply — and Sparsi compiles it into a fixed DAG. Every request after runs that compiled path instead of re-deriving it — less work, fewer tokens, right more often. The unique, novel scenarios still fall through to the primitives, exactly as today.
A Sparsi MCP server registers like any other tool — it lands in the agent's
tool list right beside search, fetch, and the rest.
The agent never has to choose primitives or Sparsi; it draws from one
palette and calls whatever mix a given request needs.
It's a mix, not a switch. Within a single request the agent blends both kinds of call freely. Sometimes one Sparsi tool call does the whole job. More often it does the bulk of the work — the known, repeating part of the request — while a few primitive calls handle whatever falls outside it. It's never all-or-nothing: primitives and Sparsi tools compose, call by call.
The more Sparsi, the better. Every request type you capture as a Sparsi tool moves more of the agent's traffic onto a deterministic, bounded-cost, audited path — while the primitives stay as the long-tail fallback. The larger the share of an agent's work that flows through Sparsi tools, the more reliable and efficient the whole system becomes.
The user talks to your chatbot. The agent LLM recognizes the intent and forwards it to a Sparsi MCP server. Inside, an AI classifier routes the request through deterministic channels; a final AI node writes the reply, which the agent relays back. The diagram below shows the minimum useful shape — one AI op upstream, one downstream — but a workflow can place additional AI nodes anywhere along the path wherever a step genuinely needs language understanding or judgment. One boundary, crossed twice — and nothing else leaks across it.
The agent LLM and Sparsi's node models are different models. The chatbot's model only ever sees a tool call and a finished natural-language reply. Inside the workflow, Sparsi embeds its own AI with a purpose-fit model at each point — a cheap classifier here, a strong synthesizer there, an independent checker where it earns its keep — each chosen, versioned, and audited per workflow. The boundary is real: no prompts, no scratchpad, no intermediate state crosses it in either direction.
You don't rewrite your agent. You peel the predictable request types off it, one at a time, and give each its own determinism-geared tool.
Look at what users actually ask your agent. A handful of intents — returns, status checks, plan changes — cover most of the volume. Rank them by frequency and start at the top of the list.
One Sparsi MCP server per request type. An AI node reads the request into structured facts; deterministic nodes call your order, fraud, shipping, and billing systems in a fixed sequence; an AI node drafts the response. Mostly code, a few AI nodes where judgment is unavoidable.
Because everything but the AI nodes is deterministic — and you pin those — you unit-test it without ever calling a model. Replay real requests, and you know exactly how it behaves before it ever reaches a user.
Register the server with a description the LLM reliably matches to the right kind of prompt. From the agent's side it's one tool call. From yours, it's a tested, auditable pipeline — while unique, novel requests still fall through to the agent, unchanged.
These aren't options you tune. They fall out of capturing a known path as a workflow: deterministic by default, AI only where judgment is genuinely required.
The same inputs produce the same outputs, every time, forever. The bulk of every workflow is plain code you can test without ever calling a model.
AI runs only where no deterministic rule can cover the gap. Every AI step is recorded with its exact input, output, and reasoning — inspectable long after the run.
Independent work runs concurrently with no manual thread management. Speed comes from the shape of the workflow, not from hand-tuning.
When something breaks, the exact failing step is named immediately. Errors surface at their source instead of disappearing into a prompt chain.
The number of AI calls is fixed by the workflow, not by input length or model mood. Cost is known before you run — and shrinks as deterministic coverage grows.
Route each step to the model best suited to it, and have a second, independent model verify the first. Cross-checking is wiring, not a research project.
On a known, repeating request type, an agent's improvisation is overhead: it re-derives the same plan and re-pays for non-determinism in tokens, in audit gaps, and in surprises. But that same improvisation is exactly what you want for novel work. The two aren't rivals — a Sparsi tool takes the known path, and the agent keeps everything else.
| Dimension | ⚡ Sparsi tool | Raw agent / prompt chain |
|---|---|---|
| Where a Sparsi tool leads — known, repeating request types | ||
| Output reproducibility | ✓ Deterministic steps always reproduce exactly | ✗ Non-deterministic at every link |
| Token cost | ✓ Tokens only for true AI gaps; all else is free | ✗ Every transformation burns tokens |
| Unit testability | ✓ Deterministic ops tested without any API key | ✗ No natural isolation boundary for testing |
| Failure attribution | ✓ Error pinpointed to the exact failing step | ✗ Error buried somewhere in the chain |
| Audit trail | ✓ Every AI call logs input, output, reasoning | ✗ Black box; no per-step record |
| Parallel execution | ✓ Independent branches run concurrently for free | ✗ Sequential by default; parallelism is manual |
| Model-version stability | ✓ Deterministic logic is immune to model drift | ✗ Behaviour shifts when the provider updates |
| Misroute handling | ✓ Out-of-scope detected early, punted back cleanly | ✗ No notion of scope; pushes ahead regardless |
| Compliance readiness | ✓ Deterministic steps satisfy data-flow requirements | ✗ Hard to prove consistency run-to-run |
| Where the raw agent leads — novel work and unique, one-off requests | ||
| Unanticipated request types | — Covers only the workflows you authored; the rest falls through | ✓ Improvises a plan for request types no one modeled in advance |
| Upfront investment | ✗ Each request type needs a workflow authored, tested, and compiled | ✓ Works the moment it has primitives — no build step |
| Adapting to change | ✗ A changed rule means re-authoring and recompiling the DAG | ✓ A prompt edit absorbs new requirements on the spot |
| Open-ended reasoning | ✗ The path is fixed at build time — no improvising mid-run | ✓ Chains and back-tracks freely as an open task unfolds |
Move your repeating agentic tasks from high-latency "thinking" loops to stable, deterministic-first tool calls.