Investigate subdomain discovery mechanism for grouping skill bundles

[olaservo]

Context

From the April 7, 2026 Office Hours, the group explored using subdomains as a grouping and trust boundary mechanism for skill bundles.

Key points from the discussion:

• Subdomains as trust boundaries — each subdomain acts as an authority for its set of skills, which is RFC-compliant with the well-known URI spec (well-known URIs must be at the domain root per the RFC)
• Subdomain discovery — Jonathan proposed an orthogonal well-known URI for subdomain discovery: a client hits the root domain first, gets a list of subdomains, then cascades to each subdomain's skill index
• Multi-tenant use case — Jack raised this from the Kong/gateway perspective: "how would they operate this without one giant tool bundle?" Large organizations need a way to partition skills across teams or services
• Gateway implications — in a gateway context, subdomain-based grouping could map naturally to backend routing and per-tenant skill sets

Questions to investigate

1. Discovery mechanism — how would a root domain advertise its skill-serving subdomains? A dedicated well-known URI? An extension to the existing index.json format?
2. Cascading resolution — what does the client workflow look like? Hit root → get subdomain list → hit each subdomain's /.well-known/agent-skills/index.json?
3. Trust model — how does subdomain-based trust interact with the existing skill trust model? Should subdomains inherit trust from the parent domain or be independently verified?
4. Scale considerations — at what point does subdomain grouping become necessary vs. a flat index? What are the practical limits?
5. Gateway/multi-tenant patterns — how would this work in a Kong-style gateway where multiple tenants share infrastructure?

Related

• Agent Skills Discovery RFC (well-known URI spec)
• Skills Extension SEP — spec, URI scheme, and reference implementation #75 — Skills Extension SEP
• April 7 meeting notes, section 6

🦉 Generated with Claude Code