Tool Policy
One-line summary
The tool policy system filters which tools are available to the LLM on each call, directly controlling the JSON schema token cost via a 7-step cascading policy pipeline.
Responsibilities
- Filter available tools through a 7-step policy cascade (profile → provider → global → agent → group)
- Expand plugin tool groups into individual tool names
- Enforce sub-agent tool restrictions (hardcoded deny lists by depth)
- Apply owner-only tool policies for security-sensitive operations
- Warn about unknown allowlist entries (plugin tools without matching plugins)
Architecture diagram
Key source files
Data flow
Inbound
Processing
Outbound
Token optimization impact
Quantified impact
How it connects to other modules
-
Depends on:
config/— policy configuration (tools.allow,tools.deny,byProvider)plugins/— plugin tool metadata for group expansion
-
Depended by:
agents/pi-embedded-runner/run/attempt.ts— calls pipeline before each LLM callsystem-prompt.ts— filtered tools determine tool summaries section
My blind spots
- Exact list of
SUBAGENT_TOOL_DENY_ALWAYSandSUBAGENT_TOOL_DENY_LEAFtools - Whether tool schemas are cached or regenerated per call
-
tools.alsoAllow— additive plugin tool enablement mentioned in warnings - How
resolveGroupToolPolicy()interacts with channel capabilities
Related contributions
- None yet
Change frequency
tool-policy-pipeline.ts: Low — the 7-step cascade is stabletool-policy.ts: Low — utility functions rarely changepi-tools.policy.ts: Medium — sub-agent restrictions and group policies evolve with features