Sprix AI has released SAGE Router, a public research prototype that chooses whether an agent should keep working, recruit collaborators, or hand a task to another agent. The consequence is less glamorous but more useful than another agent-discovery layer: it treats multi-agent routing as a decision that must account for work already completed, the cost of moving context, and the dependencies still blocking a task.
The repository calls this State-Aware Graph Exchange, or SAGE. It sits above the Agent2Agent protocol rather than replacing it. A2A can describe agents, tasks, artifacts and transport; SAGE’s narrower job is to decide a feasible execution arrangement and explain it. The prototype is explicitly not an execution client: it returns a routing decision but does not itself transmit tasks.
That boundary is important. The project is not evidence that open agent networks have solved reliable delegation. It is a reasonably concrete attempt to identify the layer where such networks are likely to fail in practice: a directory can tell a system which agents exist, but not whether changing the active team midway through a constrained task is worth the disruption.
The route decision includes the cost of changing course
SAGE compares three modes in one objective. In SELF, the incumbent retains the task alone. In COLLABORATE, the incumbent remains owner while a complementary group takes assigned work. In HANDOFF, a peer receives full ownership. The distinction is not just administrative. A handoff may gain specialist capability but lose accumulated task context; collaboration may cover missing skills but create coordination overhead.
The router represents a task as weighted requirements, with dependencies expressed as a directed acyclic graph. It then assigns each remaining requirement to an executor, schedules dependent work, and estimates a critical path. Assigning separate independent requirements to different agents can permit parallel work; assignments concentrated on one agent are serialized. Budget and deadline constraints are checked at the team level after construction, rather than treated as a property of an individual agent profile.
Its stated utility function combines a predicted probability of success with penalties for cost, latency, risk, context-transfer loss, coordination overhead and uncertainty. It also includes an exploration term. That is an ambitious scope for a small reference implementation, but the modeling choice is sound in one limited sense: a routing system that optimizes only apparent competence will systematically prefer impressive-looking agents even when switching them into a live task is expensive or infeasible.
The project also filters permissions and compatibility before scoring candidates. This is more than an implementation detail. In agent marketplaces, eligibility needs to be a hard constraint; a ranking model should not be allowed to recommend a high-scoring agent that cannot meet a security requirement or support the needed input and output modes.
SAGE’s more interesting claim is progress-aware replanning. Its execution state can include active executors, completed DAG nodes, failures and transferable context. A router that sees only the original prompt cannot distinguish a task that is still cheap to reassign from one where the incumbent has accumulated the decisive context. The latter is the case where a nominally better specialist may be the wrong choice.
Capability scores are not enough to build a team
The repository models capability by combining global trust with trust conditioned on a particular requirement, then calibrating it against outcome evidence. This is intended to avoid a familiar error in agent selection: treating a general reputation score as transferable across work types. Success on coding tasks should not automatically establish reliability for research, planning or another requirement category.
For a team, SAGE calculates requirement coverage from the combined capability of its members and assigns each requirement to the strongest calibrated member. It uses beam search over team prefixes instead of a purely greedy team-building procedure. The stated aim is complementarity: adding an agent should be rewarded for marginally covering requirements that the existing team does not cover, not simply for adding another highly ranked profile with overlapping strengths.
This is the strongest design judgment in the project. Multi-agent frameworks often make collaboration sound like an unconditional upgrade from a single capable worker. In real scheduling terms, each additional participant adds messages, dependencies, conflicting estimates and an attribution problem when the result fails. A router needs a reason not to recruit.
SAGE attempts to supply that reason through explicit coordination and transfer-loss penalties, plus a role assignment that exposes the communication topology. The output is designed to include assignments, predicted success, coverage, cost, latency, risk, utility and a human-readable rationale. Such observability is necessary if an operator is expected to approve or challenge an automated handoff.
Still, the system’s learned component should be read carefully. The repository says a regularized online predictor has replaced an earlier fixed success equation, and that bid confidence, quoted cost and quoted latency can be calibrated against observed evidence. Online adaptation is useful when marketplace claims diverge from delivery. It also raises a difficult question the prototype cannot settle: whether feedback reflects agent quality, task difficulty, the router’s prior choices, or all three.
The repository acknowledges that production use would require calibrated evaluators, authenticated identities, signed capability metadata, privacy and security review, persistent event-driven recovery, monitoring and task-specific validation. Those are not peripheral deployment chores. They determine whether the evidence used to update trust is meaningful.
A synthetic benchmark shows a trade-off, not readiness
The included benchmark runs 2,500 tasks across five deterministic seeds in an external simulator. The simulator deliberately makes hidden capabilities, pair effects, nonlinear quality, realized cost and realized latency differ from SAGE’s prediction model. That separation is a better test design than evaluating the router with its own score as ground truth.
In the reported comparison, Online SAGE reached a mean quality of 0.634 and common utility of 0.487, compared with 0.591 and 0.467 for Static SAGE. The online variant also consumed a larger share of budget on average, 0.434 versus 0.329. Its deadline-miss rate was 0.2%, while Static SAGE reported none. The repository does not conceal the cost-quality trade-off, which is preferable to presenting improved quality as a free gain.
But these figures are synthetic results, not validation of a production routing policy. The project says as much: it calls itself an early-stage research preview, says the benchmark is not evidence of real-world superiority, and lists real executions, stronger learned-routing baselines, heterogeneous agent benchmarks, trace replay, calibration analysis and adversarial conditions as needed work.
That restraint should frame the release. SAGE is credible as an algorithmic sketch of how an A2A network might make mid-execution delegation decisions. It is not yet a demonstration that a learned router can safely improve an agent marketplace under real incentives, unreliable bids and incomplete outcome labels.
The unresolved trade-off is central: the more SAGE learns from observed outcomes and marketplace signals, the more it can route around weak or overpriced agents; the more it relies on those signals, the more its decisions depend on trustworthy identity, evaluation and privacy controls that open agent networks have yet to establish.
