When Intent Becomes Authority: Agent, Plan, and Goal

In PI-Desktop, choosing Plan or Goal changes how the same Agent prepares work; it does not create a second planner or grant a hidden execution channel. This chapter examines the transition from intention to authority: what the Agent is allowed to do while forming a contract, what the user actually approves, and what happens when approval is rejected, expires, or is interrupted. The practical judgment is whether PI-Desktop makes review meaningful without breaking the session's continuity.

One Agent, two kinds of contract

The ordinary Agent mode is execution-oriented. The model can inspect the project, use the available tools, change files under the selected policy, run commands, and continue iterating. Plan and Goal begin from the same pi Agent but put that Agent into a contract state before execution. The difference is not which model is used or which application is launched. The difference is what the Agent must make explicit before it can cross the approval boundary.

Plan is about a proposed path. The Agent studies the request and the relevant project, identifies the work that needs to happen, and submits ordered implementation steps. A plan answers a question such as: “What sequence of changes, checks, and migrations should be carried out?” It gives the user a concrete route to inspect before execution.

Goal is about a proposed outcome. The Agent states what should be achieved, the acceptance criteria that would demonstrate success, and the boundaries that must not be crossed. It does not need to prescribe the implementation sequence, because after approval the Agent chooses the approach. A goal answers a different question: “What result must be true, how will we know, and what constraints remain in force?”

That distinction is useful when a developer knows either more or less about the path. If the change is sensitive and the developer wants to examine the steps, Plan makes the proposed method the object of review. If the desired result is clear but several implementation routes are plausible, Goal keeps the outcome and evidence of success fixed while leaving the route to the Agent. Both are ways of making an Agent's future behavior legible before it starts changing the project.

Neither contract state is a second intelligence that watches the first one. PI-Desktop keeps one pi Agent per session. The same Agent that inspected the repository submits the contract, receives the approval outcome, and continues in Agent mode if approval succeeds. That preserves the context it already built and avoids a handoff in which one model's plan has to be translated into another model's execution request.

The one-Agent rule also narrows the authority problem. A separate planner would introduce another runtime, another context, and another boundary at exactly the point where the user needs to know whether a proposal will be executed. By keeping the planner and executor continuous, PI-Desktop can make the transition explicit in the session's durable state instead of treating the plan as an informal message passed between systems.

Plan and Goal do not mean “read-only” in the strict security sense. They deny Write and Edit, and they deny ordinary plugin tools, while the Agent is forming the contract.