Policy-first capability filtering before agent execution

[SAURAV SINGLA (sauravsingla)]

I’m exploring a production-oriented pattern for large agent/tool catalogs:

catalog
→ authorization / policy scope
→ optional task-aware routing
→ selected capabilities
→ normal agent execution

The key principle is that dynamic routing should not be mandatory.

If identity, role, tenant, permissions, or policy already reduce the catalog sufficiently, deterministic filtering should be preferred.

Only when the remaining action space is still large or heterogeneous should task-aware routing be added.

I’ve implemented this experimentally in AgentWeave with explicit routing provenance and runtime recovery.

I’d value feedback from Semantic Kernel users on where this responsibility should live:

planner, middleware, orchestration layer, or application code?

Repo: https://github.com/sauravsingla/agentweave

[René Zander (renezander030)]

Every stage in that chain narrows what can be invoked, and the provenance you record is of the selection rather than of what the selection then did.

The case that decides the layer is the one after execution: a permitted capability ran and wrote the wrong thing, and reversing it needs the tenant and policy scope that middleware still holds and application code has already dropped.

Where does the reversal live in AgentWeave today, given routing provenance stops at the selection?