Skip to content
pi-delegation-policy

Limits and privacy

Product boundary

Section titled “Product boundary”

pi-delegation-policy guides the main agent by adding one policy block through Pi’s public before_agent_start event when the active configuration is valid. It does not create, launch, route, supervise, or block subagents. It does not change Pi’s main model or thinking level.

The policy evaluates task fit before preference. It considers demand, difficulty, quantity, risk, and error and review cost. efficient and intensive only break ties between comparably credible Small and Medium fits; standard adds no extra bias. The main agent chooses thinking for every task from those factors and the selected model’s capabilities instead of inheriting an ambient subagent default. Thinking remains dynamic and advisory, and this extension does not persist it.

For every delegated launch, the policy names the selected role’s exact provider/model base and requires the per-task thinking choice to be transmitted through the launcher. pi-subagents uses model: "provider/model:LEVEL"; another launcher may expose a separate field. This guidance applies to Small, Medium, Large, and configured Visual Design. The extension does not supply a fallback or enforce that another system follows the reference or thinking choice.

It has no presets, project configuration, external skill loading, tool interception, model fallback, enforcement, telemetry, credential storage, or network requests. It is not a subagent runner and cannot make another system perform delegation.

The optional Visual Design role may design, create, implement, and review a bounded presentation patch only when behavior and data contracts remain unchanged, the affected surface is identifiable, and visual quality or user experience is the primary acceptance criterion. It may edit scoped presentation code and assets and run the relevant existing checks.

It does not own product behavior, logic, data, APIs, routes, architecture, tooling, interaction, semantic or behavioral accessibility, test infrastructure, cross-system integration, or final acceptance. These limits are guidance; the extension does not inspect or enforce another system’s work.

Panel and status limits

Section titled “Panel and status limits”

The panel shows a compact effective-policy preview and short explanations for its fields and selectors. Model selection can show transient public metadata when Pi supplies it: name, API, reasoning support, context window, and maximum output. The extension does not persist that metadata.

/delegate status shows exact effective provider/model references and their provenance (default, global, or session), along with runtime diagnostics. D:NORM and D:AGG show that the active configuration passed local validation; they do not mean that a delegated launch occurred or that another system followed the guidance.

Fail-closed behavior

Section titled “Fail-closed behavior”

An active normal or aggressive configuration requires valid Small, Medium, and Large model references. A configured Visual Design reference must also be valid. Missing, unavailable, out-of-scope, or unauthenticated references produce D:ERR and inject no policy. The extension does not substitute another model, role, or thinking level.

off is intentionally different: it always injects nothing and reports D:OFF, even when defaults are incomplete. Turning the policy off affects later runs; it does not rewrite an agent that is already running.

A valid status only means the extension accepted the local configuration. It cannot guarantee that another system follows the role, model, or thinking guidance once it is injected.

Local data and privacy

Section titled “Local data and privacy”

The extension stores intensity, preference, and provider/model identifiers in the local global defaults file and Pi session entries. It never stores credentials, prompts, thinking settings, or panel catalog metadata, and it does not send telemetry or make network requests.

Review local configuration before sharing diagnostics. Remove credentials, prompts, personal paths, session files, and unredacted logs from reports. Model identifiers and provider names can still reveal information about your environment.

Reporting vulnerabilities

Section titled “Reporting vulnerabilities”

Use GitHub’s private vulnerability reporting for an undisclosed vulnerability; do not open a public issue. Include the affected version or commit, operating system, Pi version, reproduction steps, expected behavior, observed behavior, and a minimal sanitized configuration.

For ordinary changes, read the contribution guide.

More information

Section titled “More information”