Sprix SAGE Is the Missing Decision Layer for the Agent Internet — And It Has Zero Dependencies

Table of Contents

• The Problem
• What Is SAGE?
• Cloning and Testing
• The Benchmark
• Finding the Rough Edges
• The Big Picture
• Bottom Line

Agent-to-agent protocols finally exist. A2A is shipping. MCP is in production at every major AI company. The plumbing is done. What nobody has built is the traffic cop — the runtime decision layer that looks at a task, looks at the available agents, and decides: should the current agent keep going, recruit help, or hand off to a specialist?

Yesterday, a repo appeared on GitHub called Sprix SAGE Router (90★, Python, no dependencies). I cloned it, ran the tests, broke a few things, and came away convinced that this is the kind of infrastructure the agent ecosystem has been missing. Let me show you why.

§The Problem

Right now, agent orchestration works one of two ways:

• Hardcoded DAGs (Prefect, Airflow, LangGraph) — you declare the topology at design time. Good for pipelines, useless for open agent networks where agents come and go.
• LLM-as-orchestrator (AutoGPT, BabyAGI, most "agent frameworks") — the LLM decides who to call next via function calls. The decision is opaque, unconstrained, and has no memory of past outcomes.

Sprix SAGE sits in the gap. It's a library that takes a task (with requirements, budget, deadline, permissions, and a DAG of dependencies), a set of agents (with skills, cost, latency, permissions), and bids from those agents, and outputs one of three decisions:

graph TD
  subgraph "Task arrives mid-execution"
    A[Task DAG + progress state]
  end
  subgraph "SAGE Router"
    B[Filter by permissions]
    C[Filter by budget/deadline]
    D{Beam search}
    E[Evaluate SELF vs COLLABORATE vs HANDOFF]
    F[Assign DAG roles]
    G[Score utility]
  end
  subgraph "Execution"
    H[Run assigned agents]
    I[Record outcome: trust + synergy update]
  end
  A --> B --> C --> D --> E --> F --> G --> H --> I --> D
  style E fill:#312e81,stroke:#a78bfa
  style G fill:#312e81,stroke:#a78bfa

The learning loop is what distinguishes it from a one-shot heuristic. After each execution, the router updates per-skill reliability, pair-synergy scores (how well two agents worked together), and bid-fidelity scores (did an agent deliver what it bid?). These all feed into the next routing decision. It's an online learning system with the regret bounds of a combinatorial bandit, dressed up as a routing library.

§What Is SAGE?

SAGE stands for State-Aware Graph Exchange. It defines three routes in one objective function:

Route	Ownership	When It Wins
SELF	Incumbent keeps it	The current agent has enough skill + context. Adding collaborators would cost more than it buys.
COLLABORATE	Incumbent retains ownership	The task needs a complementary skill that a small team covers. Coordination overhead is worth it.
HANDOFF	Peer takes full control	A specialist is so much better that the context-transfer loss is outweighed.

The key insight: these three modes compete in the same utility function. The router doesn't try SELF first and fall back. It evaluates all feasible configurations (bounded beam search over agent subsets) and picks the one with the highest estimated utility, subject to hard constraints.

§Cloning and Testing

I cloned the repo and ran it cold. Here's what happened:

git clone https://github.com/wang2122/sprix-sage-router.git
cd sprix-sage-router
python3 demo.py

The demo ran immediately — no pip install, no dependency resolution, no version conflicts. The pyproject.toml defines zero runtime dependencies. Pure stdlib.

mode       : collaborate
agents     : incumbent-planner, security-reviewer
utility    : 0.616
p(success) : 0.814
cost       : 0.176
latency    : 1122 ms
assignments: {'planning': 'incumbent-planner', 'coding': 'security-reviewer', 'security': 'security-reviewer'}
topology   : (('incumbent-planner', 'security-reviewer'),)
reason     : COLLABORATE via [incumbent-planner, security-reviewer]: the selected team improves
task-DAG coverage after coordination cost; estimated success=0.814, coverage=0.756

The router correctly identified that the incumbent (good at planning, mediocre at coding and security) should collaborate with a security specialist rather than going it alone or handing off entirely. The explanation field is a nice touch — in a production system, you'd log this for audits.

Running the full test suite:

============================= 12 passed in 0.13s ==============================

All 12 tests pass in 0.13 seconds. The test suite covers:

• Self-routing for easy tasks
• Collaboration for complementary skills
• Handoff to clear specialists
• DAG role assignment and topology building
• Permission enforcement as a hard filter
• Deadline enforcement after DAG scheduling
• Outcome recording with partial credit
• Replanning when the incumbent fails
• Reliability updates that don't bleed across skills
• Rejection of evidence for unselected agents

§The Benchmark

The repo ships a benchmark.py that runs 2,500 simulated tasks (5 seeds × 500 tasks each) across five strategies:

strategy       quality       utility       cost/budget   latency/deadline  deadline-miss
self           0.507+/-0.003  0.389+/-0.002  0.239+/-0.005  0.611+/-0.010    26.4%
skill_solo     0.558+/-0.005  0.435+/-0.005  0.292+/-0.004  0.568+/-0.006    11.9%
oracle_solo    0.553+/-0.005  0.440+/-0.005  0.271+/-0.005  0.540+/-0.006     0.0%
static_sage    0.591+/-0.007  0.467+/-0.007  0.329+/-0.007  0.520+/-0.010     0.0%
learned_sage   0.634+/-0.006  0.487+/-0.006  0.434+/-0.011  0.512+/-0.009     0.2%

The numbers tell a clear story:

• "self" — the incumbent never delegates. 26.4% deadline miss rate, lowest quality (0.507). This is the default for most "agent" implementations today.
• "skill_solo" — always pick the best-skilled agent. Better quality, but no team awareness. Still 11.9% deadline misses.
• "oracle_solo" — always pick the agent that would be best. Zero deadline misses but 0.553 quality. This is the upper bound for any solo strategy.
• "static_sage" — the routing logic without learning. 0.591 quality, 0.0% deadline misses. Already beats every solo strategy.
• "learned_sage" — full system with online learning. 0.634 quality, 0.2% deadline misses. A 25% quality improvement over solo.

The cost angle is interesting. learned_sage spends 43.4% of budget vs self's 23.9% — it pays more because it actually hires collaborators. The question is whether the quality uplift justifies the cost. In a high-value task (the benchmark uses value=1.0 normalized), 0.634 > 0.507 is a 25% improvement. That's the entire thesis of multi-agent systems compressed into a single table.

§Finding the Rough Edges

I spent time trying to break things. Here's what I found:

1. The documentation assumes A2A familiarity. If you don't know what an "Agent Card" is or how A2A discovery works, the README doesn't hold your hand. The project sits above A2A and assumes you already have that layer in place. A "quick start" that simulates a full end-to-end scenario would help.

2. No type stubs. The code uses from typing import ... but only provides runtime annotations. No .pyi files, no mypy strict compatibility. For a library that wants to be infrastructure, this matters.

3. The bid system is underspecified. In the demo, bids are hand-constructed. In a real system, bids would come from the agents themselves (or a discovery service). The library doesn't prescribe a protocol for bid generation — that's left as an exercise, and the gap between demo and production is noticeable.

4. Single-file architecture. The entire library is one 749-line sprix_sage.py file. This is great for reading the whole thing in one sitting but will become unwieldy as the system grows. I'd split it into core.py, types.py, learning.py by version 1.0.

5. The CI badge is aspirational. The README shows a GitHub Actions badge, but the .github/workflows/tests.yml is standard copy-pasta. The tests pass, but there's no linting, no type checking, no coverage reporting in CI.

6. Permission checking isn't publicly exported. There's a _check_permissions prefixed function that's private. I couldn't call it from outside the module. For a hard constraint that every integrator will need, this should be a public API.

None of these are fatal. This is version 0.2.0, labeled "Research Preview." The core algorithm is sound, the code is clean, and the zero-dependency choice is a strong signal of engineering maturity.

§The Big Picture

SAGE is part of a pattern I've been tracking for months. The agent ecosystem is going through the same evolution that microservices went through in 2014–2018:

1. Discovery — "Here's how agents find each other." A2A gets this right (Agent Cards over HTTP).
2. Messaging — "Here's how agents talk to each other." MCP (tools/resources/prompts), A2A (tasks/artifacts), both converging on JSON-RPC over HTTP.
3. Routing — "Here's how to decide who does what." This is the missing layer. SAGE is the first credible open-source attempt at it.
4. Observability — "Here's what happened and why." Doesn't exist yet for agent networks.

We're at step 3. If you're building an agent platform, you need a routing layer. SAGE is a good starting point — and its zero-dependency design means you can drop it into any Python project without worrying about version conflicts.

§Bottom Line

Sprix SAGE solves the right problem at the right time. The algorithm is sound (combinatorial beam search with contextual bandit learning), the code is clean (749 lines, stdlib only, 12/12 tests passing), and the benchmark shows real improvement over any solo strategy. The rough edges are organizational, not fundamental.

I expect this space to move fast. If the Sprix team turns this into a proper A2A middleware layer (with HTTP transport, bid protocol, and observability hooks), they'll have something that every agent platform will need. For now, it's a promising research prototype that's worth watching — and worth forking if you're building agent infrastructure today.