Ability to filter skills by agent

[k33g]

It should be possible to provide a list of the skills each agent has access to.

[aheritier]

Given that our codebase automatically discovers and loads skills from multiple sources, our global skill pool can grow quickly. If every agent inherits this entire pool, we bloat the LLM context window with irrelevant tool schemas, which increases token costs, latency, and the risk of hallucinations.

At the same time, relying on dynamic runtime approvals (prompting the user to allow/deny a tool mid-execution, similar to Claude Code) creates too much friction and disrupts autonomous workflows.

Instead, the industry pattern leans heavily toward configuration-based allow/deny lists at the agent level for context management and specialization:

• CrewAI & AutoGen: Tool scoping is core to the agent's definition. You configure a "Researcher" agent with only search/scrape skills, while an "Executor" agent gets shell/fs skills. The available tools are filtered at initialization.
• OpenAI Assistants / API: Supports an allowed_tools configuration. You can have a massive backend registry of tools, but you explicitly pass a narrowed list when configuring a specific assistant or run to keep the context lean.
• LangGraph: Tools are bound directly to specific nodes via configuration. The graph's routing architecture itself acts as the permission model.

Proposed approach for Docker Agent:
Rather than dynamic execution-time approvals, we implement configuration-level filtering:

1. Auto-Discovery: Continue discovering and loading all skills globally into a registry.
2. Agent-Level Config: Introduce allowed_skills and/or denied_skills arrays in the agent's definition/configuration.
3. Context Filtering: When an agent is instantiated, filter the globally discovered skills through its allow/deny config. Only the permitted tool schemas are injected into that agent's prompt.

This gives us the best of both worlds: zero friction during execution, and highly specialized, context-efficient agents.