Give every AI coding agent a scope limit and a done condition

An agent that is told to "clean up the search feature" will often do more than you meant: rename a helper used elsewhere, upgrade a dependency, reformat a directory. Each change may be reasonable on its own. Together they make the diff hard to review and collide with other sessions working nearby.

The fix is not a longer prompt. It is a brief with four explicit parts.

The four-part brief

1. Allowed area. Where the agent may edit. "Change files under src/search/ and its tests."
2. Forbidden area. What it must not touch, even if it looks related. "Do not modify package.json, lockfiles, shared config, or files outside src/search/. If you need a change there, stop and describe it."
3. Stop condition. When to stop and report instead of continuing. "Stop after the failing test passes, or after two attempts that don't work — whichever comes first."
4. Proof of done. What evidence you expect back. "Report the test command you ran and its output, plus a list of changed files."

Why each part matters

• The allowed area makes review possible. You know in advance which files the diff should contain, so anything outside it stands out.
• The forbidden area protects shared files. Manifests, lockfiles and configuration are where parallel sessions most often step on each other. Routing those changes through a single owner is covered in splitting work for parallel agents.
• The stop condition prevents quiet thrashing. Without one, an agent that is stuck may keep trying variations and leave a large, low-value diff behind.
• Proof of done replaces "looks finished" with something you can check. Asking for the actual command and output is more reliable than asking whether the task is complete.

A template you can paste

Task: one sentence. You may edit: paths. Do not edit: paths / file types. If you need a change outside your area, stop and describe it. Stop when: condition, or after two failed attempts. When done, report: files changed, the verification command, and its output.

Keeping track of briefs across sessions

With several sessions running, the brief is also how you remember what each one is for. Two cheap habits: put the one-sentence task in the session's name, and keep each session in its own directory or Git worktree so the allowed area matches the folder.

That is the part Agent Tile helps with: a one-time $10 macOS app that shows each Claude Code session as a tile with its project and folder visible, and relaunches each one with --resume in its original directory after a restart. It does not enforce the brief — you still write it — but it makes it obvious which session is working where.

Takeaway

Before starting an agent, write four things: where it may edit, where it may not, when it should stop, and what proof you want back. Drift drops, reviews get smaller, and parallel sessions stop colliding over shared files.