Sprix SAGE Router: mid-execution routing decisions for A2A agent networks

The gap SAGE targets: discovery is solved, mid-flight reconfiguration is not

Agent discovery answers which agents exist. It does not answer who should work with whom once execution has already begun. That is the question SAGE is built around, and the README states the scope narrowly: checkpoint-aware reconfiguration after execution has begun. The intended user is someone running an A2A network who has already solved Agent Cards, messages, tasks, artifacts, authentication and transport, and now needs a policy for the moment when a plan is partly done, partly failing, and the original assignment no longer looks right. Three routes are compared in one objective: SELF, where the incumbent agent keeps the task; COLLABORATE, where the incumbent retains ownership and recruits complementary agents; and HANDOFF, where a peer takes full ownership. The README frames the choice as a trade between specialist advantage and context-transfer loss, which is the honest framing. Handing off to a better-matched agent is not free, because the new owner redoes work the old owner already did. If your tasks are short, atomic, or stateless, there is no checkpoint to route on and this project has nothing to offer you.

How the routing decision is computed: calibrated capability, reuse fraction, one utility

The mechanism is documented as a two-stage calculation. First, for each requirement r, SAGE combines global and requirement-conditioned trust into a calibrated capability q(a,r). If the current owner has completed fraction f_r of that requirement, a candidate owner reuses fraction eta_r: f_r when the owner is retained, f_r times tau_r when the owner changes, where tau_r is artifact portability. The effective quality is then a weighted blend of the incumbent's quality and the candidate's quality, weighted by how much work is reused versus redone. The README is explicit that only the assigned owner contributes requirement coverage, so adding an unassigned teammate no longer creates a noisy-OR quality gain, and the same reused fraction reduces projected remaining cost and duration so lost work is not charged twice. Second, SAGE jointly searches requirement owners and their schedule: work assigned to one agent is serialized, work on independent agents can run concurrently, and team-level cost and critical-path latency are rechecked after construction. Every feasible route is ranked by a linear utility that subtracts weighted terms for cost, latency, risk, context-transfer loss, coordination overhead and uncertainty, and adds a term for exploration. That single shared action space is what makes SELF, COLLABORATE and HANDOFF comparable rather than three separate heuristics.

Getting it running: clone, demo, unittest, and the minimal SAGERouter call

The reference implementation requires Python 3.10 or later and the README states it has no runtime dependencies. The documented sequence is git clone of the repository, cd into it, then python demo.py. Verification is python -m unittest -v, followed by python benchmark.py, python benchmark_dynamic.py and python benchmark_trust.py. Minimal usage imports Agent, ExecutionState, ExecutionOutcome, Requirement, SAGERouter and Task from the sprix_sage package. Agents are constructed with a skill-to-proficiency mapping plus cost and latency_ms. A Task takes a name, a tuple of Requirement objects (each with a name and weight, optionally depends_on another requirement), a value, a budget, a deadline_ms and a progress fraction. The router is constructed with the agent list and an incumbent_id. ExecutionState carries the runtime facts that make the decision checkpoint-aware: active_agents, active_assignments, completed_requirements, inflight_requirement, inflight_progress, inflight_quality and artifact_transferability. Calling route_with_trace returns a trace whose selected field holds the decision, with mode, assignments and topology, and whose excluded_agents field lists filtered candidates. After execution, record_outcome takes the decision plus an ExecutionOutcome with success, requirement_scores, actual_cost and actual_latency_ms. The README's code block is truncated mid-comment at the persistence step, so the exact API for saving and reloading router state is not shown in the material available here.

Where the design is thin: reliability learning, portability values, and the truncated persistence path

The README claims requirement-conditioned evidence: reliability is tracked per agent and per requirement rather than assuming one reputation score transfers across skills. That is the right modelling choice, but it also means the router needs per-requirement outcome data before its estimates are worth anything. Feed it a single scalar success value per task and you are effectively back to a global reputation score. The artifact_transferability mapping is a second soft spot. In the example it is hand-authored (0.95 for planning, 0.40 for coding), and nothing in the supplied material describes how those numbers are measured or calibrated in a live system. If you cannot estimate portability, tau_r becomes a guess and the HANDOFF branch of the calculation is only as good as that guess. The persistence API is also not fully visible: the README's minimal example ends at a comment beginning Persist, and the material does not show the save or load call. The project labels itself Research Preview in its own badge, and releases v0.1.0 and v0.3.0 are dated ten days apart, which is consistent with an actively changing interface rather than a frozen one. Treat the module surface as unstable until you pin a version.

SAGE versus a static coalition or a progress-masked baseline

The README names two comparison points directly: progress-masked and static-coalition baselines. The difference is in what each one is allowed to see. A static coalition fixes the team before execution starts and never revisits it, so it cannot react to a partially completed requirement, an observed partial quality of 0.72, or a failure that only appears at a checkpoint. A progress-masked variant knows how far along the task is but does not use that progress to reduce the projected remaining work of a candidate owner, which means it either overestimates the cost of switching or double-counts work already done. SAGE's position is that the reuse fraction eta_r should simultaneously raise the effective quality estimate and lower the projected remaining cost and duration. The README also states that the baselines receive the same registry, permissions, budget and deadline limits, which is the right way to make the comparison meaningful. It is worth noting what the README does not claim: noisy-OR, beam search, linear utility, Beta beliefs, online logistic regression and DAG-induced communication edges are all described as replaceable implementation mechanisms rather than inventions. That is an unusually candid framing, and it means the interesting part of the project is the state model and the action-space unification, not the individual scoring functions.

Evaluation, falsification and the evidence loop

The README describes a separate evaluator that replays checkpoints and scores artifact reuse, added cost, recovery latency, wasted work and final quality, and states that it does so without calling SAGE's switching equation. That separation matters. If the same utility function that chose the route also scored it, the evaluation would be circular, and the README's phrase trajectory-level falsification is a claim about avoiding exactly that. The operational loop is closed by record_outcome, which returns success, per-requirement scores, actual cost and actual latency to the router so that the Beta beliefs and the logistic success model can be updated. This is the part that will determine whether SAGE works in your environment. The demo and benchmark scripts run offline; the material does not report any benchmark numbers, so there is no published figure here to compare against your own workload. You will need to run benchmark.py, benchmark_dynamic.py and benchmark_trust.py yourself and read the output before drawing conclusions about routing quality.

Licence, maintenance surface and what the two releases imply

The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. Nothing in the supplied material indicates a CLA, a dual-licence arrangement or a separate commercial tier, but this is a description of the repository metadata, not legal advice, and you should read the LICENSE file yourself before shipping it inside a product. Maintenance cost is hard to estimate from the material. Two releases exist, v0.1.0 on 2026-08-18 and v0.3.0 on 2026-08-28, which is a ten-day gap and a minor-version jump of two. The last push to main is dated 2026-08-28, the same day as v0.3.0. That pattern suggests rapid iteration on an unstable interface, so pinning a commit hash or a tag is more sensible than tracking main. Because the package has no runtime dependencies, the upgrade cost is mostly API churn in sprix_sage rather than dependency resolution, and the unittest suite is the thing to run after each bump. The README links ALGORITHM.md, RELATED_WORK.md, docs/INTEGRATION.md, docs/OPERATIONS.md, CHANGELOG.md and CONTRIBUTING.md, so the operational detail you need beyond this README lives in those files, which are not part of the material reviewed here.

Editorial conclusion

Adopt SAGE if you already run A2A agents and your routing problem is reconfiguration after work has started, not initial assignment. Skip it if you need a production scheduler with an operations story, or if your tasks have no meaningful checkpoint state to feed in. Before committing, read ALGORITHM.md end to end, run python demo.py and python -m unittest -v on your Python 3.10+ interpreter, and check whether the ExecutionState fields you can actually populate (inflight_quality, artifact_transferability, completed_requirements) match what your agents emit.

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. wang2122/sprix-sage-router on GitHub