Sprix SAGE Router: Rerouting Agents Mid-Task

Most agent routing happens before anything runs. You pick a model, pick a framework, wire up the handoffs, and by the time work starts the decisions are already frozen. Sprix SAGE Router goes after the awkward case nobody wants to touch: the task is half done, the agent holding it is struggling, and somebody has to decide whether moving it is worth throwing away what's already finished.

The repo went public on 18 August 2026 and sat at 3,456 stars with 401 forks when I pulled the GitHub API on 5 September. Two releases so far, v0.1.0 the day it launched and v0.3.0 on 28 August, from eight contributors across 43 commits. It's MIT licensed, needs Python 3.10 or newer, and has no runtime dependencies at all.

What it actually decides

Agent discovery answers which agents exist. That question is largely solved; the Agent2Agent protocol gives you Agent Cards, messages, tasks, artifacts, authentication and transport, and a growing number of frameworks speak it. What A2A deliberately doesn't answer is who should be working with whom once execution is already underway.

SAGE stands for State-Aware Graph Exchange, and it sits one layer above discovery as a decision function. Feed it the task, the registry of available agents, and a snapshot of where execution currently stands, and it returns one of three routes plus an audit trail explaining why the other candidates lost.

The three routes are the whole vocabulary. SELF keeps the task with whoever has it, on the argument that existing capability and accumulated context are good enough. COLLABORATE recruits a small complementary team while the incumbent keeps ownership. HANDOFF transfers the task outright to a specialist, accepting the cost of moving context to get the capability.

The boundary between the three moves

What makes this more interesting than a switch statement is that the boundary between the routes isn't fixed. It shifts with how far along the work is, how portable the artifacts are, how much a specialist would actually add, and what the permission and budget constraints allow.

Progress raises the cost of switching, because a new owner inherits less usable work. High artifact transferability pushes the other way and makes a handoff cheap. The project is careful to label that diagram as qualitative rather than a set of fitted thresholds, which is the first of several places where it declines to oversell itself.

Why "mid-execution" carries the whole claim

Strip away the machinery and one idea is doing the work: a router that knows how much of the task is already finished should behave differently from one that doesn't.

The project tests this with a controlled intervention rather than a vibes-based table. Two policies are identical except that one receives the real in-flight completion fraction and the other is handed a zero; everything else stays pinned, from task and agents down to artifact portability, budget and deadline. Then completion sweeps from 0.0 to 0.9.

At zero completion the two curves are the same number, which is exactly what should happen when the extra information carries no signal. By 0.9 the gap reaches 0.0684. That shape is more convincing than the headline result, and I want to be blunt about why.

In the trajectory replay over 1,000 checkpoints and five seeds, progress-aware SAGE scores 0.298 ± 0.021 against the masked variant's 0.291 ± 0.021. Those error bars overlap almost entirely. If you only read the utility column you'd conclude the feature does nothing.

The difference lives in the other columns. Wasted work drops from 0.104 to 0.059, roughly 43% less discarded effort. The switch rate falls from 80.1% to 58.4%, meaning the informed router moves tasks far less often. Knowing what's already done mostly teaches the router to leave things alone, and the utility number hides that because a switch that breaks even on utility still burns real work.

The naive baselines land where you'd guess: "always continue" collapses to 0.085 utility with a 34.4% deadline miss rate, while "always hand off" reaches 0.290 but wastes 0.130 of the work, the worst figure in the table. A hidden-state oracle that cheats by seeing latent quality gets 0.375, setting a ceiling nobody claims to have reached.

A second study isolates a different assumption. Tracking reliability per agent per requirement, rather than one reputation score per agent, reaches a Brier score of 0.0125 ± 0.0018 against 0.0355 ± 0.0008 for the single-score model on the same evidence stream. In the homogeneous control, where specialisation genuinely doesn't exist, both methods hit zero routing regret. Shipping a negative control that could have embarrassed the result is not a common choice.

What Sprix SAGE Router does with A2A, and what it won't

The integration story is narrower than the ambition suggests, and the docs say so plainly. AgentCard.skills becomes a normalised capability vector, declared security requirements become a hard eligibility filter applied before scoring, and a provider quote becomes a Bid carrying cost, latency and confidence. Task status, artifacts and failures feed the execution state.

Out the other end comes a transport-neutral execution plan: ownership, assignments, DAG dependencies, communication edges, estimated resources, rationale. What it explicitly won't do is transmit anything. The prototype doesn't send tasks, authenticate endpoints or verify signatures, so a real A2A client stays responsible for message/send, streaming, polling, cancellation and secure artifact handling. Signed Agent Card ingestion and real A2A adapters are both unchecked boxes on the roadmap.

That gap is worth sitting with. You're getting a decision layer, not a runtime, and you supply the runtime. The cost and latency terms in the objective assume compute is a metered resource with a price attached, which holds for a fleet of hosted endpoints and is quietly false of a laptop, where the real constraint is that closing it stops everything. MoClaw is one way to make that assumption honest: a hosted cloud AI computer with its own always-on machine, so the thing your router is scheduling work onto actually stays reachable. We've written before about how agent handoff works in practice and about orchestrating multiple agents if you want the broader picture around this.

Not the other routing problem

A quick disambiguation, because "router" is carrying two unrelated jobs in this space.

Model routers decide which model answers a request, usually to cut inference spend by sending easy prompts to cheap ones; we covered one recently in our write-up of Workweave's LLM router. A sagerouter.dev does provider routing under a nearly identical name, and there's a SAGE order router in equities trading, so the bare term returns three different products.

Sprix SAGE Router does none of that. It never touches model selection. It decides which agent owns a task and who else joins in, which is a scheduling and ownership question rather than an inference-cost one.

Running Sprix SAGE Router, and the missing pip install

There's a wrinkle worth knowing before you plan an afternoon around this. There is no PyPI package. I checked sprix-sage-router, sprix-sage and sprix and all three return 404, which matches the v0.3.0 release note saying PyPI upload stays gated until the owner configures Trusted Publishing. A built wheel and source distribution ride along as release assets, both small, and the release text says they passed twine check and a clean-environment install.

The documented path is therefore a clone, python demo.py, then python -m unittest -v and the benchmark scripts if you want to reproduce the tables. All of them take deterministic seeds and emit JSON, which is the part I'd actually use: you can re-run the controlled intervention on your own parameters instead of trusting the plot.

State persistence goes through export_state(), which snapshots learned reliability estimates so they survive a restart. That matters more than it sounds: a router learning per-agent, per-requirement trust only becomes useful after enough outcomes, and every process death that loses the snapshot resets you toward the random-prior row of the benchmark. MoClaw helps on that axis too, for the ordinary reason that a machine you don't shut down accumulates evidence a laptop keeps discarding.

Who should look at this now

Researchers working on multi-agent allocation are the obvious audience, and the repo is set up for them. ALGORITHM.md carries the formal objective and its limitations; RELATED_WORK.md maps the design against coalition formation, combinatorial allocation and contextual bandits while stating which optimality claims are not being made.

Engineers running A2A networks in anger should read it and not deploy it. The project calls itself an early-stage research preview in three separate places, and the honest summary is that the ideas are sharper than the evidence supporting them, by the authors' own account.

Everyone else gets a useful mental model for free, and it's what I'd take away even without running the code. Most multi-agent systems make the routing call once, at the start, when they know the least; Sprix SAGE Router asks again at a checkpoint, with the completed work priced in, which is a better question. The reason that's hard in practice usually isn't the maths; it's that a checkpoint an hour into a job only exists if the job survived the hour. That's the gap MoClaw fills for teams without their own infrastructure, a hosted cloud AI computer that stays up so scheduled and long-running agent work has somewhere to land. The free trial runs 3 days and 1,000 credits, and a $20 subscription is 1,000 credits a month.

The honest read

Twelve days between the first release and the second, with the second one adding baselines and ablations that make the project's own numbers look less impressive. That's an unusual direction of travel. Most projects at 3,456 stars spend release two adding features.

Watch the roadmap rather than the star count. Two unchecked boxes decide whether Sprix SAGE Router becomes usable: repeated checkpointed evaluation on heterogeneous real A2A endpoints, and offline replay on anonymised marketplace traces. Until one lands, every number in the README is a simulation arguing with itself, which the authors put more bluntly than I just did.

FAQ

What problem does Sprix SAGE Router solve that A2A doesn't?

A2A handles discovery and transport: which agents exist, how to reach them, how tasks and artifacts move. It takes no position on whether a struggling agent should keep its task. SAGE is a decision layer that answers that second question and hands back a plan your A2A client then executes.

Can I install it with pip?

Not yet. All three plausible package names return 404 on PyPI, and the v0.3.0 notes say publishing is gated on Trusted Publishing setup. Clone the repo or grab the wheel attached to the release; it needs Python 3.10+ and pulls in no runtime dependencies.

Are the benchmark results trustworthy?

They're internally rigorous and externally unproven, and the project says so itself in an admonition block. The evaluators are structurally separate from the router and never call its switching equation, seeds are deterministic, and there's a negative control. But both evaluators were written by the same authors, and every task is synthetic. Treat the numbers as falsification evidence rather than performance claims.

Is it production ready?

No. It labels itself an early-stage research preview, doesn't authenticate endpoints or verify signatures, and lists signed Agent Card ingestion plus real A2A adapters as future work. The operations guide sets out rollout gates that a production deployment would need to clear first.

Who is behind it?

Sprix AI, described in the README as the A2A initiative of 屿智同行, with Yonghao Zhang credited as CEO and Yichen Wang as CTO and SAGE algorithm designer. The code is MIT licensed and the contributor graph shows eight people, so community pull requests are already landing.