What the platform owns
General coding agents already provide governance primitives. This platform packages one repeatable operating model for Pi across every repository.
This is not a new agent
The platform has no model, runtime, or agent loop of its own. It runs as a Pi extension and adds one thing: a repeatable operating model that every repository can reuse.
General coding agent CLIs already provide sandboxes, approvals, and project configuration. The useful question is not which agent is stronger. It is who configures those controls, and whether the configuration stays consistent across twenty repositories.
| Area | General agent CLI | What this platform adds |
|---|---|---|
| Role | A coding agent operating on a local repository with tool and command selection. | A governance layer for Pi: policy, profiles, and workflows represented as files instead of prompt conventions. |
| Team customization | Instructions, settings, permissions, hooks, skills, and MCP configured per repository. | Profile adapters, base policy, command guards, capability packs, docs, and scripts defined once and distributed with piagent-init. |
| Execution permissions | OS or process sandboxing, per-action approval, and workspace boundaries. | Three named modes: read-only, workspace-write, and trusted-full-access, changed with one command. |
| Secret safety | Sandbox, approval, and network policy beneath the tool layer. | Application-level policy after a tool call: protected paths, shell checks, symlink aliases, output redaction, and integrity locks. |
| Distinct value | A complete agent experience and broad tool ecosystem. | Repeatability: the same profiles, guard, and verification discipline across repositories, with differences visible in files. |
The two layers are complementary
The host sandbox controls processes: a process cannot open files outside its permitted scope. The platform guard controls tool calls: it can inspect the arguments the agent intends to use, including paths, destinations, and external payloads.
The lower layer sees processes
It can tell that a process is writing outside the workspace. It cannot tell whether that process is npm test or a script generated during the current turn.
The upper layer sees intent
It knows the tool, arguments, and capability. That is enough to block .env by name, redact tokens in output, and reject an MCP server supplied by a repository.
An application guard cannot replace a sandbox once a process is running. A sandbox does not know why .env differs from .env.example. The platform assumes the lower layer remains enabled.
When you may not need it
For one person, one repository, no meaningful secrets, and no shared operating process, Pi's native configuration may be sufficient.
The platform becomes useful when no one can remember which permissions are active across many repositories, or when "has this been verified?" needs the same evidence-based answer everywhere.