Standing Instructions for AI Agents: The Pattern That Stops You Repeating Yourself

We had been typing the same five rules at the start of every session. Respond in plain English. Confirm before deleting. Match the existing style. Do not install dependencies without asking. Show the diff before applying.

It worked, but it was not real work. Five lines, ten times a day, was an obvious candidate for automation. The fix is built into every modern AI agent: a persistent rules file that is loaded automatically at the start of every session.

This piece covers the pattern, the three template sizes we use, and the failure modes that show up when standing instructions get stale.

What standing instructions are

Standing instructions are a file in your project (or a setting in your agent) that the agent reads before any task. They define the things you would otherwise type into every prompt: who the agent is acting as, what it must not do, how it should format output, what to do when it is uncertain.

Different tools call them different things, but the pattern is universal:

The mechanics differ, but the principle is the same: give the agent its standing rules once, in a file it always reads, instead of typing them into every session.

A copy-paste minimum

Three lines is enough to start. Put this file in the top level of your project folder, using the filename your tool expects, and you are done:

- Respond in plain English.
- Confirm before deleting any file.
- Match the existing code or writing style of the project.

That is the minimum viable version. The agent will respond in your language, will not silently delete files, and will not "improve" your code style without permission. These are three problems people reliably hit, and three lines solve them.

You can expand from here when you feel a specific gap. Most people never need more than ten or fifteen lines.

Three sizes of standing instructions

The right size depends on the project. We use three tiers depending on what is being built.

In our experience, once the file gets past sixty lines, agents start to ignore parts of it. The model has limited attention for instructions, and a long file means each individual rule gets less weight. If your standing instructions are getting bloated, the right move is almost always to cut, not to add.

Tier 1: minimum (the three-line version)

- Respond in plain English.
- Confirm before deleting any file.
- Match the existing code or writing style of the project.

Use this for the first session on any new project. It costs thirty seconds and prevents the most common surprises.

Tier 2: project (the working version)

This is what we use on most projects after the first week:

# Standing instructions

## Role
You are an editorial and technical assistant for this project. Help with drafting, reviewing, and small implementation tasks.

## Operating rules
- Respond in plain English unless asked otherwise.
- Confirm before deleting any file.
- Match the existing code or writing style of the project.
- Do not modify configuration files (package.json, build configs, etc.) without explicit approval.
- Do not install or change dependencies without confirmation.

## Off-limits
- Do not run commands that modify dependencies (npm install, pip install, etc.) without confirmation.
- Do not make changes outside the file or section explicitly requested.

## Response style
- Lead with the conclusion. Use bullets and tables when they help.
- If you are uncertain, ask before acting rather than guess.

The Tier 2 file is enough for most production work. It covers the common failure modes (file deletion, dependency drift, scope creep) and sets a response style that scales across tasks.

Tier 3: full (the long-running version)

Tier 3 is for projects you will run for months. It adds context the agent uses to make judgment calls when the rules above do not cover the situation.

# Standing instructions

## Mission
You are a long-running collaborator on this project. The work is substantial; the goal is for it to keep moving without you needing fresh context every session.

## Core principles
- Be useful, not performative. No filler ("great question!" etc.). Just help.
- Have an opinion. "It depends" without analysis is a failure.
- Try first before asking. Read the relevant files, check context, then come back with answers — not with questions you could have answered yourself.
- Lead with the conclusion. One sentence is enough when one sentence is enough.
- Surface problems honestly. Soft answers waste time.

## Order of decision-making
When you are not sure how to handle a situation:
1. Check the project's decision log if one exists.
2. Read the project memory or notes file.
3. If neither resolves it, ask — with the options you have considered.

## Operating rules
[All the Tier 2 operating rules]

## Off-limits
[All the Tier 2 off-limits]

## Continuity
You start each session fresh. The files in this project are your memory. Read them. Update them when something changes.

Tier 3 is what you reach when the project has its own working culture. The instructions stop being a list of rules and start being a description of how the work is done.

What makes standing instructions actually work

The most common reason standing instructions fail is that they are too abstract. Vague rules give vague results.

The agent does not have a sense of what "polite" or "safe" means in your context. It has the words you give it. Specific, observable rules turn into specific, observable behavior. Abstract rules turn into approximations.

Common failure modes

The "review monthly, revise after every incident" rhythm is the one that keeps standing instructions alive. After every minor agent failure — a deleted file, an unexpected package install, a tone-deaf rewrite — add the rule that would have prevented it. Over a few months, the file becomes a record of every lesson the project has taught you.

A decision rule for what belongs in standing instructions

If you find yourself typing the same instruction more than twice in regular session prompts, it belongs in the standing instructions.

Conversely, if a rule in the standing instructions is being ignored or is no longer relevant, remove it. The file should match what the project actually needs, not what you thought it would need three months ago.

How standing instructions work alongside session instructions

Standing instructions cover the things that are always true. Session instructions cover the specific task in front of you.

The split looks like this:

The cleaner the standing instructions, the shorter your session prompts can be. The cleaner your session prompts, the less the agent has to guess. Together, they make working with agents feel less like supervising a contractor and more like running a system.

The bottom line

Standing instructions are the cheapest leverage in agent-driven work. The cost is one small file. The return is every session that does not start with "let me explain how this project works."

Related reading

• The AI Task Delegation Checklist — the pre-flight check that runs alongside standing instructions
• How to Instruct an AI Agent So It Does What You Asked — session-level instruction patterns that pair with standing instructions
• Three Ways AI Agents Break Your Work — the failure modes standing instructions are designed to prevent
• OpenClaw: A Practitioner's Field Guide — the OpenClaw deep-dive, including its SOUL.md implementation
• Antigravity: A Practitioner's Field Guide — the Antigravity deep-dive, including its AGENTS.md implementation