You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: add per-agent tool visibility via defaultAgent.excludedTools
Add a new DefaultAgentConfig type and defaultAgent property to SessionConfig
across all four SDKs (Node.js, Python, Go, .NET). This allows tools
to be hidden from the default agent while remaining available to custom
sub-agents, enabling the orchestrator pattern where the default agent
delegates heavy-context work to specialized sub-agents.
The default agent is the built-in agent that handles turns when no
custom agent is selected. Tools listed in defaultAgent.excludedTools
are excluded from the default agent but remain available to sub-agents
that reference them in their tools array.
Changes:
- Node.js: DefaultAgentConfig interface, defaultAgent on SessionConfig/
ResumeSessionConfig, RPC pass-through, 2 unit tests
- Python: DefaultAgentConfig TypedDict, default_agent parameter on
create_session()/resume_session(), wire format conversion
- Go: DefaultAgentConfig struct, DefaultAgent on config and request structs
- .NET: DefaultAgentConfig class, DefaultAgent property on configs, copy
constructors, and RPC request records
- Docs: Agent-Exclusive Tools section in custom-agents.md
- Test scenario: custom-agents scenario updated with defaultAgent usage
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
> **Note:** When `tools` is `null` or omitted, the agent inherits access to all tools configured on the session. Use explicit tool lists to enforce the principle of least privilege.
761
761
762
+
## Agent-Exclusive Tools
763
+
764
+
Use the `defaultAgent` property on the session configuration to hide specific tools from the default agent (the built-in agent that handles turns when no custom agent is selected). This forces the main agent to delegate to sub-agents when those tools' capabilities are needed, keeping the main agent's context clean.
765
+
766
+
This is useful when:
767
+
- Certain tools generate large amounts of context that would overwhelm the main agent
768
+
- You want the main agent to act as an orchestrator, delegating heavy work to specialized sub-agents
769
+
- You need strict separation between orchestration and execution
1.**Are registered** — their handlers are available for execution
890
+
2.**Are hidden** from the main agent's tool list — the LLM won't see or call them directly
891
+
3.**Remain available** to any custom sub-agent that includes them in its `tools` array
892
+
893
+
### Interaction with Other Tool Filters
894
+
895
+
`defaultAgent.excludedTools` is orthogonal to the session-level `availableTools` and `excludedTools`:
896
+
897
+
| Filter | Scope | Effect |
898
+
|--------|-------|--------|
899
+
|`availableTools`| Session-wide | Allowlist — only these tools exist for anyone |
900
+
|`excludedTools`| Session-wide | Blocklist — these tools are blocked for everyone |
901
+
|`defaultAgent.excludedTools`| Main agent only | These tools are hidden from the main agent but available to sub-agents |
902
+
903
+
Precedence:
904
+
1. Session-level `availableTools`/`excludedTools` are applied first (globally)
905
+
2.`defaultAgent.excludedTools` is applied on top, further restricting the main agent only
906
+
907
+
> **Note:** If a tool is in both `excludedTools` (session-level) and `defaultAgent.excludedTools`, the session-level exclusion takes precedence — the tool is unavailable to everyone.
908
+
762
909
## Attaching MCP Servers to Agents
763
910
764
911
Each custom agent can have its own MCP (Model Context Protocol) servers, giving it access to specialized data sources:
0 commit comments