Add auth-native routing (Router): route tasks by scope-defined capability#39
Merged
Conversation
The differentiator the harness research called out. Route a task to a worker whose harness (its granted scopes) covers the scopes the task needs: - Router.register(worker, scopes); route(required) -> a capable worker (round-robin across eligible), or None if none is capable (visible, not a silent misroute); candidates(required) lists them. - The same scopes that gate tool calls decide who is capable of a task, so work can't be routed to an agent that isn't authorized for it. Pair with dispatch or the task queue: route first, hand off to the chosen worker. 292 tests (+6), mypy --strict, ruff (whole repo), catalog freshness all green. v1.6.0. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Auth-native routing (
Router)Route a task to a worker by capability, where capability is the auth scope set — the one differentiator the harness-comparison research kept calling out. Most harnesses route by name, tag, or a hand-maintained skills table that can drift from what an agent can actually do. hallpass already knows what each agent is allowed to do (its granted scopes, enforced at call time), so it routes on that same fact:
Router.register(worker, scopes)— declare a worker and the scopes its harness grants.Router.route(required)— return a worker whose harness coversrequired, round-robin across the eligible ones;Noneif none is capable (visible, not a silent misroute onto an agent that would just get denied).Router.candidates(required)— list every capable worker.Because the routing key is the authorization key, a task can never be routed to an agent that isn't authorized to perform it — the failure the research flagged in tag/name routing. Pair it with
dispatchor the durableTaskQueue: route first, then hand the task to the chosen worker.Verification
tests/test_router.py— 6 tests: capability match, uncovered scope → not a candidate, superset harness matches, round-robin spread,Nonewhen none capable, thread-safe register/route.mypy --strict,ruff(whole repo), and catalog-freshness all green.Additive; no breaking changes. Closes out the last high-impact item from the competitive-performance research plan.