Sparsi packages repeatable tasks into stable, deterministic-first MCP tools. By replacing multi-call reasoning loops with a single call to a composed workflow, you get workloads that are auditable, cost-effective, and right more often—reserving AI for genuine judgment.
"AI" is used for two structurally different things. Conflating them is the single most common reason agent systems become unauditable. Sparsi is the boundary between the two.
The autonomous agent that decides which tool to invoke and what to do with the result. It reasons about the goal — as an executive, a support lead, an analyst. It has no visibility into the steps inside a tool and never appears in graph code. To it, a Sparsi workflow is one reliable function call.
Individual vertices within a DAG workflow that interpret, transform, or route data where no deterministic rule exists. Each is tightly scoped, pinned to a specific model, and logged with its exact input, output, and reasoning. The agent never invokes these — the graph does, in a fixed position.
Why the distinction is load-bearing: the agent's reasoning is inherently non-deterministic and that is fine — it is choosing what to do. The determinism guarantee applies inside the tool, to how the work is done. Keeping the layers separate is what lets one be free-wheeling while the other is auditable.
A Sparsi workflow is one repeating request type captured as a compiled graph — a Directed Acyclic Graph of typed operations. To the calling agent it is a single tool: one request goes in, one typed result comes back, and everything in between is fixed at build time. Every run moves through the same three stages.
The agent calls the tool with one typed request. That payload becomes the graph's root, and the engine routes it to every operation whose inputs subscribe to it.
The engine resolves the wiring and runs each operation as its inputs become ready — independent ones in parallel. Branches a predicate gate leaves unreached are pruned, so their AI ops never run.
Execution ends at the leaf operations. Side effects are solidified and the final typed result is handed back to the calling agent as the tool's return value.
The shape of the DAG is also its execution plan. These properties fall out of that structure — you get them without writing a line of scheduling code.
Each vertex is an op — a pure function with typed inputs and outputs. Wires are named typed values; the wiring is the data contract and the documentation.
Independent vertices run concurrently with no manual thread management. Speed is a property of the graph's shape, not of hand-tuning.
Conditional branches are plain code predicates. Unreached branches are pruned — and the AI ops inside them are never invoked or paid for.
An error is attributed to the exact failing vertex before any downstream work runs. There is a natural isolation boundary for both testing and debugging.
Map an operation across a collection and merge the results back. Parallelism and recombination are first-class, not bolted on.
Because deterministic ops are pure functions, they are unit-tested with no API key and no model call — the part you control is verifiable in CI.
Every node in the graph is an operation — a typed unit with a fixed set of named inputs and outputs. Four kinds cover the whole surface: a deterministic library, an AI library, a RAG library, and custom operations you write yourself. They share one wiring contract, so a single workflow mixes them freely.
Dozens of ready-made operators that run as plain functions — arithmetic, string and slice work, predicates, routing and selection, JSON and time. No tokens, no API key, no network. The same inputs always produce the same outputs — the deterministic backbone of every workflow.
Operators that hand a step to a model and return a typed, structured result — classify, extract, score, semantic yes/no, rerank, best-match, summarize, parse. Each AI operation is configured independently — see below — so every model call in a workflow runs on its own settings. Because that includes the provider and model, one AI op can verify another's output on a different model — cross-model checking is just one more node on the graph.
A retrieval layer behind a backend-agnostic Retriever interface —
implement it once over BM25, a vector store, or a hosted search service.
Retrieve operators pull context into the graph; a citation validator filters
model-emitted sources against an allow-list, so answers stay grounded.
When nothing in the libraries fits, write your own — a small struct with
dag:"input" / dag:"output" tags and a
Run(ctx) method. This is how a workflow reaches your existing
services in any language. A custom op is a first-class node: same wiring, same
testing, same audit record.
Each AI operation is configured on its own. Two AI ops on the same graph share nothing by default — each pins six settings independently, so a cheap classifier and a strong synthesizer coexist in one workflow without compromise.
The role and standing rules the model runs under.
The per-call framing wrapped around the wired inputs.
Anthropic or Google — the SDK the call routes through.
The exact model pinned for this operation.
The factory that sources the credential — env var, Vault, per-tenant store.
A hard ceiling on the tokens the call may spend.
The boundary is sharper than most teams assume. Most "complex" steps are deterministic once you know the rule. AI is reserved for what genuinely needs language understanding or judgment — which is also what keeps cost and audit under control.
Conditional routing, formula scoring, structured parsing, lookups with fallback, calls to your own systems, arithmetic, threshold decisions — anything you could test reliably without ever calling a model.
Free-form classification, extraction from prose, subjective judgment, semantic yes/no, summarization and drafting, ranking and matching, messy number parsing — anything that depends on reading a sentence and understanding what a human meant.
The practical test: if you could test it reliably without ever calling a model, it belongs in code. If the answer depends on reading a sentence and understanding what a human likely meant — hand it to AI.
Lots of tools can be packaged as MCP tools. What matters to you is narrower: a Sparsi tool is deterministic at every possible point, so its behavior, cost, and audit trail are things you can count on — fixed by how the workflow is built, not coaxed out of prompt-engineering. You don't tune for these properties; they fall out of capturing a known path as a workflow.
The bulk of every workflow is plain code. It produces identical results on identical inputs, forever, and is testable without ever calling a model.
The number of AI calls is fixed by the shape of the graph, not by input length. Cost is known before a run and shrinks as deterministic coverage grows.
The inversion: hand an agent fifty low-level tools and every problem means reinventing a long, brittle tool chain. Package each business process as its own deterministic tool instead — multiple task-specific tools, never one monolith — and the calling agent reasons like an executive, not a plumber.
Auditability is not only logging — it is being able to have one model's output independently checked by another. Because AI steps are discrete typed vertices, cross-model checking and cost-aware routing are ordinary wiring, not a research project.
A model that wrote something tends to believe it. Put a second, independent model in the path as a quality gate: one drafts, another checks every claim against the source. The handoff between them is plain deterministic code — no tokens, no latency, fully logged.
Not every step needs your most expensive model. Route bulk and simple sorting to a cheap, fast model; reserve the top tier for hard reasoning. Cost drops with no change to business logic.
Different providers lead at different things. Use the strongest model per task — multilingual here, code there, fast-and-cheap for volume — inside one coherent workflow.
The LLM picks the tool, so it won't always pick right. Sparsi is built for that: a misroute costs you almost nothing, and the request lands exactly where it would have without the tool.
The request really is this type. It runs through the workflow along a fixed path — low, bounded token cost, every step logged, the same path every time. This is the routine path you came for.
The agent routed it here, but it isn't really this request type. The workflow detects the mismatch early — before touching any system — and punts it straight back to the LLM. No side effects, negligible cost.
A genuine instance the workflow can't safely complete — a policy edge, missing data, a value past a threshold. It's returned to the LLM for fallback, or escalated into a human-backed queue. Never forced through.
The asymmetry that makes this safe: capturing the common path is a large, permanent win; getting a match wrong costs an early bail-out and a hand-back. You're never worse off than the plain agent — and on the requests that repeat, you're dramatically better.
These guides take the ideas above down to the API surface. They are the technical-tier companions to this page.
Vertices, typed wires, field tags, the scheduler, predicate gates, skip-propagation, fan-out, and merge — the shape every workflow starts from.
One-shot tool calls and multi-call sessions that share server state, pooled subprocesses, custom formatters and parsers, tool-error recovery.
The retriever interface, retrieval ops, deterministic citation allow-list filtering, and pluggable embedding providers.
Wrap a deterministic op so a typed repairable error escalates to a bounded AI pass that mutates the input until it satisfies your rules.
Source provider clients from Vault, a secrets manager, workload identity, or per-tenant stores — without env vars and without changing graph code.