One task in. An eligible provider out.
ATL routes supported search, extract, summarize, translate, and classify tasks to eligible providers, executes the selected route when ATL owns execution, applies bounded fallback when appropriate, and learns from durable outcomes.
Less routing overhead. Smaller machine responses. Fail-closed behavior preserved.
After the first Decision hot-path performance pass, ATL was benchmarked from an external GitHub-hosted runner against the public production endpoint. These are measured results from that test set, not theoretical projections.
Scope matters: the 91.3% figure is response-body reduction for this benchmark, not a claim about model tokens or total application bandwidth. The 16/16 figure describes this test set, not universal accuracy. Read the benchmark methodology and caveats.
Live Route Demo
Send a real Decision request to ATL's production entrance. ATL's safe V1 surface supports search, extract, summarize, translate, and classify; the demo uses summarize as a compact routing example.
Connect where you already build
MCP
Start with atl_decide, then follow its machine-readable next_step to atl_execute for ATL-owned execution.
Python
Zero runtime dependencies.
JavaScript
Node.js 18+.
Why ATL exists
Not just model aggregation
ATL is focused on route eligibility, lifecycle state, Gate checks, authorization, bounded failover and outcome evidence.
Fail closed before routing
A provider is not treated as production-eligible just because an endpoint exists.
Machine traffic first
The target is agent-to-infrastructure traffic, not a dashboard that humans must operate manually.