# Pure ReAct is expensive and fragile. Sparsi lowers costs and increases reliability.

> Source: <https://dev.to/npolarski/pure-react-is-expensive-and-fragile-sparsi-lowers-costs-and-increases-reliability-ke5>
> Published: 2026-07-10 00:45:10+00:00

If you’ve built AI applications in production recently, you’ve probably hit the "Agent Wall."

You build a ReAct agent, give it 10 granular tools (search, extract, route, format), a massive system prompt, and tell it to go to work. It feels like magic...until you look at your latency metrics and token bills.

Today’s agents act as interpreters. They re-derive the exact same routines from scratch on *every single request*. They embed massive tool schemas and reasoning histories into every loop. It's slow, it's incredibly token-hungry, and occasionally, they hallucinate tool calls, drop constraints, or get stuck in endless reasoning loops. In a production environment, even occasional errors can be critical failures that waste time and tokens.

The problem isn't the ReAct pattern itself. The problem is that we are forcing the LLM to orchestrate low-level, predictable logic that should be deterministic code.

We got tired of paying the "reasoning tax" for sub-routines that don't need it. So, we built **Sparsi**—a framework for shifting complex logic out of your ReAct agent's prompt and into deterministic "Macro-Tools" built as DAGs (Directed Acyclic Graphs).

There are two ways to use Sparsi: as an end-to-end solution for a specific task, or to create higher-level tools that plug into your existing agents.

The latter is where the magic happens. Instead of giving your ReAct agent 10 tiny, flaky tools and hoping it chains them correctly, you build one highly reliable, deterministic Sparsi DAG to handle that specific sub-routine. You then expose that DAG to your agent as a single Model Context Protocol (MCP) tool. The overall agent still drives the conversation, but it delegates the heavy lifting to a reliable macro-tool.

We chose the DAG architecture for three main reasons:

`asyncio`

in Python, goroutines in Go, or Promises in TS). Your speed comes from the graph's shape, not manual threading.`sparsi.library`

, a collection of pre-built operators (like `AIComputeOp`

, `WebScrapeOp`

, or `MCPCallOp`

) so you don't have to reinvent the wheel. Just import them and wire them into your graph.To prove why shifting logic into a DAG is superior, we ran a rigorous benchmark.

The task was a realistic 5-step **Advanced Customer Support Ticket Triage**:

`order_id`

and `user_email`

.We compared a pure LangChain ReAct agent (juggling tools for each step) against a Sparsi DAG pipeline. We used `gemini-3.1-flash-lite`

for both, and heavily optimized the prompts for both frameworks via tree search. This optimization process involved an automated script that iteratively generated and tested multiple generations of prompt variations against a validation dataset, ensuring both systems were operating at their absolute mathematical limit.

Here are the results (100 samples):

| System | Pipeline Accuracy* | Avg Latency (s) | Total Tokens | Failures** |
|---|---|---|---|---|
Sparsi (Multi-Step DAG) |
100.00% |
1.73 |
61,158 |
0 |
| Pure LangChain ReAct | 94.00% | 3.06 | 258,050 | 0 |

**Pipeline Accuracy** requires perfect intent matching, perfect policy routing, and a passing grade from an independent LLM-as-a-judge on the drafted email's formatting and politeness.*

***Failures** tracks hard application crashes or unparseable outputs.*

Pure ReAct agents must embed massive system rules, multiple tool schemas, and their own expanding reasoning history into every single iterative loop.

Sparsi simply passes the exact, minimal context needed to the specific node that needs it. It reduces token usage even further by using incredibly small, focused prompts in its individual AI DAG nodes. For example, instead of a massive ReAct system prompt that has to load instructions for sentiment, intent, routing, and tools all at once, the isolated Sparsi node for classifying a ticket intent uses this tiny prompt:

"Classify 'intent' into EXACTLY one of: [refund, escalate, question, feedback]"

By replacing predictable routing steps with deterministic code (like handling the policy logic), we bypassed an entire LLM network hop. Combined with the DAG's concurrent execution, latency dropped to 1.73 seconds.

When a ReAct agent is juggling multiple granular tools, its context window gets bloated. During the benchmark, the LangChain agent occasionally bled internal system variables into the customer-facing output, drafting emails that actually said: *"We have noted your request with a neutral sentiment and an urgency score of 2."*

By shifting this sub-routine into a Sparsi DAG, Step 5 (Drafting the Email) is completely isolated. It only sees the variables it explicitly needs, forcing it to generate a natural response without leaking raw internal metadata.

One of the most powerful features of Sparsi is how easily these DAG workflows can be exposed to your overarching agents.

Sparsi has native support for serving your DAGs as high-performance **Model Context Protocol (MCP)** servers. We built the `run_dual_mode`

helper to allow your script to act as both a CLI testing tool *and* an MCP server:

``` python
from dagor import Builder
from sparsi import run_dual_mode

def build_graph():
    b = Builder("ticket_macro_tool")
    b.vertex("in").op("ContextValOp").params({"key": "val"}).output("result", "in_wire")
    # ... wire up extraction, sentiment, and email drafting ...
    return b

if __name__ == "__main__":
    # Map MCP argument 'input' to ContextValOp key 'val'
    run_dual_mode("ticket_macro_tool", build_graph, {"input": "val"}, output_wire="final_result")
```

By running `python my_script.py --mcp`

, the script boots up as an official MCP server, communicating over stdio. Your overarching AI assistant (whether it's Claude Desktop, a LangChain agent, or an AutoGen swarm) can now discover and execute your deterministic workflow exactly like a native tool.

You keep the flexibility of the ReAct pattern at the top level, but gain the speed, reliability, and cost-savings of a DAG for the heavy lifting.

To make building these MCP tools even easier, Sparsi ships with two bundled skills: `sparsi-py-design`

and `sparsi-py-codegen`

.

You can drop these directly into your AI assistant. Then, simply ask:

*"Design a Sparsi workflow that takes a recipe URL, extracts the ingredients, and scores the difficulty."*

The assistant will automatically design the deterministic DAG architecture and generate the exact Python code required to run it as an MCP tool.

If you are building production-grade agents where strict adherence to formatting, low latency, and low token costs are critical, stop giving your agents tiny tools. Start giving them Macro-Tools.

Sparsi is fully open-source and available across three ecosystems:

Let me know what you think of the approach. I'm interested to hear how you optimize your own AI pipelines.