Sprix SAGE Router
Chooses whether an in-flight A2A task should continue, recruit collaborators, or transfer ownership.
- Source repo
- wang2122/sprix-sage-router
- Stars
- ★ 3.6k
- Last updated
- 1mo ago
- License
- MIT
- Primary language
- Python
- FA score
- 69/100 · Some gaps
At a glance
- How it runs
- Works with
- Universal · cross-platform
- Cost
- Free, no paid service needed
- Setup effort
- Low · running in minutes
- You'll need
- Typical use
- An engineering team building an A2A orchestrator needs to decide at a checkpoint whether to preserve the incumbent's context or switch to a specialist.
- Not a fit if
- Teams needing production A2A execution, auth, and secure transport
- Teams wanting validated performance on real heterogeneous endpoints
- Teams needing a complete A2A client with discovery, streaming, and cancellation
- Source review
- 69/100 · Some gaps
What does this agent do, and when should you use it?
Sprix SAGE Router is a Python research prototype for reconsidering an A2A task's execution route after work has begun. It evaluates the task DAG, current ownership, completed nodes, partial progress and quality, artifact portability, failures, budget, and deadline before choosing SELF, COLLABORATE, or HANDOFF. Its implementation includes SAGERouter, DAG scheduling and beam search, requirement-conditioned trust, an online success model, audit traces, and exportable learning state. The sprix_a2a.py adapter normalizes Agent Card signals and produces a transport-neutral ExecutionPlan containing ownership, assignments, dependencies, communication edges, resource estimates, and rationale. It does not send tasks, authenticate endpoints, verify signatures, stream responses, poll, cancel, or securely transfer artifacts, so deployment requires a separate A2A client and security layer. The project is an early research preview, and its published measurements come from synthetic evaluations rather than real endpoint evidence.
A caller describes candidate workers with Agent, defines a dependency-aware workload with Requirement and Task, and supplies live ownership, assignments, completed requirements, in-flight progress and quality, and artifact transferability through ExecutionState. SAGERouter.route_with_trace() applies permission and compatibility filters, performs a bounded search over owners, requirement assignments, and DAG schedules, rechecks team cost and critical-path latency, and compares SELF, COLLABORATE, and HANDOFF under one utility function. The returned trace exposes the selected Decision, assignments, topology, excluded agents, and auditable alternatives. After execution, record_outcome() accepts an ExecutionOutcome with success, requirement scores, actual cost, and actual latency to update requirement-conditioned trust, the success model, and bid fidelity; export_state() produces a learning-state snapshot. For A2A use, sprix_a2a.py validates declared skill IDs and converts the route into a transport-neutral plan, but it does not contact or operate remote endpoints.
- An engineering team building an A2A orchestrator needs to decide at a checkpoint whether to preserve the incumbent's context or switch to a specialist.
- A multi-agent systems researcher wants to compare SELF, COLLABORATE, and HANDOFF under identical permission, budget, and deadline constraints.
- A marketplace team with heterogeneous specialists needs reliability estimates for each agent-requirement pair instead of one global reputation score.
- A workflow architect designing failure recovery needs reassignment decisions that account for partial completion, reusable artifacts, and context-transfer loss.
- A routing-algorithm team needs deterministic synthetic trajectory replay, controlled progress interventions, trust-convergence studies, and candidate-scaling measurements.
How do you install or deploy this agent?
Python 3.10+ and Git are required. The reference implementation has no runtime dependencies and documents no required API keys or other credentials. Clone the repository over the network and run the demo:
git clone https://github.com/wang2122/sprix-sage-router.git
cd sprix-sage-router
python demo.pyRun the supplied verification and benchmark commands with:
python -m unittest -v
python benchmark.py
python benchmark_dynamic.py
python benchmark_trust.pyHow do you use this agent?
This example defines two candidate agents and a dependency-aware task, routes from an in-flight checkpoint, reports the decision, records the execution result, and exports learned state:
from sprix_sage import (
Agent,
ExecutionOutcome,
ExecutionState,
Requirement,
SAGERouter,
Task,
)
agents = [
Agent("planner", {"planning": 0.92, "coding": 0.55}, cost=0.08, latency_ms=900),
Agent("coder", {"planning": 0.35, "coding": 0.96}, cost=0.12, latency_ms=1200),
]
task = Task(
"build-feature",
requirements=(
Requirement("planning", 0.4),
Requirement("coding", 0.6, depends_on=("planning",)),
),
value=1.0,
budget=0.30,
deadline_ms=4000,
progress=0.35,
)
router = SAGERouter(agents, incumbent_id="planner")
state = ExecutionState(
active_agents=("planner",),
active_assignments={"planning": "planner", "coding": "planner"},
completed_requirements=frozenset({"planning"}),
inflight_requirement="coding",
inflight_progress=0.35,
inflight_quality=0.72,
artifact_transferability={"planning": 0.95, "coding": 0.40},
)
trace = router.route_with_trace(task, state=state)
decision = trace.selected
print(decision.mode, decision.assignments, decision.topology)
print(trace.excluded_agents)
router.record_outcome(
decision,
ExecutionOutcome(
success=0.9,
requirement_scores={"planning": 0.95, "coding": 0.86},
actual_cost=0.19,
actual_latency_ms=1450,
),
)
snapshot = router.export_state()For an A2A deployment, the caller must separately implement message/send, streaming, polling, cancellation, authentication, signature verification, and secure artifact handling.
What are this agent's strengths and limitations?
- It models checkpoints after execution begins, incorporating completed nodes, observed quality, remaining work, and artifact reuse instead of making only an initial assignment.
- SELF, COLLABORATE, and HANDOFF share the same permission, budget, deadline, and utility constraints, with alternatives, exclusion reasons, and degraded-route flags available for audit.
- Reliability is maintained per agent and requirement, while
record_outcome()can update the success model, Beta beliefs, and bid-fidelity evidence. - It searches requirement ownership and DAG schedules together, serializes work assigned to one agent, permits independent work on separate agents to overlap, and rechecks team cost and critical-path latency.
- The Python 3.10+ reference implementation has no runtime dependencies and includes deterministic tests, multiple benchmark programs, and machine-readable JSON reporting.
- It is explicitly an early-stage research preview, not a production SLA or peer-reviewed result.
- Reported metrics come from project-authored synthetic evaluators; repeated checkpointed trials on heterogeneous real A2A endpoints and an independently governed artifact judge are still missing.
- It does not execute or transmit tasks, authenticate endpoints, verify signatures, stream, poll, cancel, or secure artifacts, creating substantial integration work for production adopters.
- Production use requires calibrated evaluators, authenticated identities, signed capability metadata, privacy and security review, persistent event-driven recovery, monitoring, and task-specific validation.
- Task-text embeddings, real endpoint adapters, a distributed router service, human approval gates, and offline replay of anonymized marketplace traces remain roadmap items.
How does this agent compare with similar options?
The repository compares progress-aware SAGE with progress-masked SAGE, always-continue, always-handoff, a static greedy team, static coalition enumeration, and a hidden-state dynamic oracle in synthetic trajectory replay. It also contrasts requirement-conditioned trust with a single-reputation model and includes incumbent-only, advertised-skill solo, random-team, greedy-team, static SAGE, and several learned SAGE configurations in its independent-task regression suite. These results are presented as regression and falsification evidence, not proof of superiority in real deployments.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Sprix SAGE Router This agent | 69 · Some gaps | CLIFree | ★ 3.6k | 1mo ago | Python | — |
| OpenCrabs Terminal Agent | 53 · Major gaps | CLIFree + model costs | ★ 1k | today | Rust | ChatGPT · Codex · OpenAI API · Claude API |
| Underthesea - Vietnamese Agentic AI Toolkit | 47 · Major gaps | Library / SDKFree + model costs | ★ 1.8k | 1mo ago | Python | OpenAI API · Claude API |
| amux Agent Control Plane | 77 · Good | Self-hosted serviceFree + model costs | ★ 543 | today | Rust | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence shows permission requirements enter as a hard eligibility filter, SECURITY.md documents a threat model and pushes identity, sandboxing, and least-privilege credentials to adopters; the core deliberately does not transmit, authenticate, or sign. Deductions: human confirmation appears only as an unchecked roadmap item with no implementation; rollback exists only as learning-state snapshot export with no decision-level recovery; source and test files were not supplied, so the hard-filter and data-flow claims score on README assertions alone.
Evidence shows cross-document consistency (README, pyproject, and CI workflows agree on modules, commands, schema versions) and near-zero dependency-availability risk with no runtime dependencies. Deductions: failure-message and exception quality cannot be verified because test_*.py and sources were not provided; CI smoke benchmarks cover only small parameter ranges.
Evidence shows unusually explicit scenario framing (the SELF/COLLABORATE/HANDOFF usage table), capability boundaries (no transport, no auth, research preview), and Python 3.10–3.12 CI matrix. Deductions: environment fit requires the adopter to build the A2A client; real-endpoint evaluation remains an open roadmap item; trigger-precision evidence is entirely from self-authored synthetic benchmarks.
Evidence shows complete information architecture (layered ALGORITHM/RELATED_WORK/INTEGRATION/OPERATIONS/BENCHMARKING docs, repository map), full MIT license text, well-formed pyproject metadata, named maintainers, and SECURITY/CONTRIBUTING/CITATION files. Deductions: CHANGELOG.md is referenced but not supplied, so version history is inferred from 0.3.0 and the roadmap; examples/README.md was not provided, so example quality is unverified; unverified publisher identity means maintenance sustainability can only be scored on declaration.
Evidence shows auditable traces with ownership, assignments, topology, and rationale, three deterministic CLIs emitting JSON reports, and near-zero deployment cost as pure Python with no runtime deps. Deductions: marginal value hinges on the core progress-awareness claim whose supporting numbers come from project-authored evaluators that the README itself labels 'not evidence of real-world superiority', so realized utility cannot be confirmed from this evidence.
Evidence shows strong fact/inference separation — synthetic numbers are repeatedly labeled regression evidence only, the research-preview status and explicit non-claims are stated, and benchmark commands and schemas are reproducible. Deductions: cross-source corroboration is entirely absent; all performance figures come from evaluators written by the same authors with no third-party or real-endpoint validation; key source and test files were not in the review materials, so formula-to-implementation traceability could not be completed.
- This is a static source review (confidence: low); no code was executed, and the supplied materials exclude source and test files, so many scores rest on README assertions.
- All benchmark figures come from project-authored evaluators that the README itself disclaims as real-world evidence; independently validate the mid-execution switching decisions on real A2A endpoints before adoption.
- The prototype performs no authentication, signing, or task transmission; production use must add identity, authorization, sandboxing, and human approval per SECURITY.md — no confirmation mechanism is implemented.
- Keep secrets, private prompts, and personal data out of snapshots and traces; poisoned learning evidence can shift online beliefs and there is no rollback mechanism.
- Publisher identity is unverified by any curated registry; treat maintenance sustainability as declared only and verify independently.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
v0.3.0 Sprix SAGE Router v0.3.0
Release notes excerpt
Benchmark rigor and scalability - structurally held-out geometric evaluator with independently specified latent skills - random and greedy team baselines - learning, exploration, initialization, and early/late ablations - bounded top-k candidate prefilter and request-local scoring caches - workload-sensitive cost and explicit authorized degraded-route flags - evidence-gated pair synergy updates - related-work comparisons, module split, ruff/mypy CI, and release automation …View on GitHub ↗
FAQ
Does it require a paid model, cloud service, or API key?
Will it execute or forward A2A tasks itself?
ExecutionPlan; an external A2A client must handle message sending, streaming, polling, cancellation, and artifact transfer.How are permissions and incompatible candidates handled?
How does the router learn from completed work?
record_outcome(). The router updates requirement-conditioned trust, its online success model, and bid fidelity, then can persist the result through export_state().