Pi Agent System Prompt: Set Rules and Test Them

A Pi coding agent, like other AI coding tools, accepts a system prompt or configuration that defines how it behaves before any task starts. The instructions you put there determine what the agent does automatically, what it stops to confirm, and what it treats as off-limits. Writing them carefully and testing them on real tasks is how you avoid unpleasant surprises mid-session.

The principles here apply to any AI coding agent that accepts standing instructions. Check the Pi agent's own documentation for the exact format it uses and where to put the configuration. Tools like fenbs keep reusable prompts and project rules in a shared place that stays available across sessions and tools.

What a coding agent system prompt should contain

A useful system prompt for a coding agent covers four areas: the task scope, the constraints, the review gates and the output standards. Each area answers a specific question the agent will face.

• Task scope: what kind of work is this agent for? "Write and edit code in this project" is a scope. "Also manage GitHub issues and send messages" is a larger scope that needs an explicit decision.
• Constraints: what the agent must not do without asking. Touching production systems, deleting files, making external API calls, or committing to a branch without review.
• Review gates: the points where the agent stops and waits for your confirmation before continuing. Typically: before creating new files, before running destructive operations, and before making changes outside the current scope.
• Output standards: how the agent should present its work. Where to put comments, how to name things, whether to include tests, and how to flag uncertainty.

Writing the task scope clearly

A coding agent with a vague scope will fill in the gaps itself, usually in the most efficient way available, which may not be the way you intended. Be specific about what the agent works on.

A specific scope might say: "Work on the files in the current project directory. Do not access other directories, external services or the internet unless I explicitly ask you to. If a task requires touching something outside this scope, ask before proceeding." This is three sentences, and it prevents most of the scope creep that causes problems in longer agent sessions.

For related guidance on agent setup and system prompts in other tools, the system prompt examples guide covers a range of working patterns. The prompt engineering guide covers how to make instructions unambiguous.

Setting constraints that stick

Constraints are the rules the agent follows in every session. They are the instructions you would be most upset about the agent ignoring. Write them as explicit prohibitions rather than as guidelines: "Do not delete any file without showing me what it contains and asking for confirmation" is a constraint. "Be careful with file deletion" is a guideline that the agent may interpret loosely.

Start with a short list of the highest-stakes constraints: what the agent must never do automatically. Then add the medium-stakes constraints: what it should do cautiously with notification. Keep the constraint list short enough to review. A long list of constraints is often not read carefully by the agent or by you.

Designing review gates

A review gate is an explicit instruction to stop, show progress, and wait. Without them, a coding agent in a long task can make many interdependent changes before you see the result. A gate at a natural decision point keeps the scope of each approval small.

Useful gate points for coding agents: before creating a new module or file structure, before running a command that modifies data, before making a change the agent thinks is outside the original request, and before finishing a multi-step task to confirm the intended end state. You do not need a gate at every step; put them where a wrong decision would be costly to reverse.

Testing the system prompt on real tasks

Write the system prompt, then give the agent a real task from your current project. Watch whether it respects the scope, triggers the review gates at the right points and stays within the constraints. A task that should hit a gate and does not means the gate instruction needs to be more specific.

Test the constraints explicitly. Give the agent a request that should hit a constraint and check whether it asks for confirmation or proceeds. If it proceeds, add a more specific prohibition. If the constraint fires too often on normal work, narrow its scope.

For how other agents handle these patterns, the hermes agent and microsoft copilot agents guides cover different agent setups that face similar configuration questions.

How to do this with fenbs

fenbs keeps your approved system prompt instructions and project rules in a shared record that persists across sessions. When a new session starts, the agent reads the current rules before any task.

1. Create a free account. Set up a project for the codebase the Pi agent works on.
2. Add the approved system prompt instructions as a Skill in the project. Include the scope, constraints, review gates and output standards.
3. Add the project's standing rules to Decisions and rules. These appear first in the AI context, before the skill, so the agent knows what is always off-limits.
4. Connect your AI app over MCP at Integrations. The agent reads the rules and the current skill at the start of each session.
5. After testing, record what each constraint or gate got wrong as a lesson. Adjust the skill and test again. Two or three rounds usually produces reliable behavior.