Working with AI agents — a starter

Paste-in rules that survived testing. Drop them into whatever your agent always reads: a project instructions file, system prompt, or equivalent.

Every rule here is something I tested — and most of what I started with isn’t here, because it failed or was already common knowledge. The receipts are in The Brief (the writeups in the repo).

1. The fastest win: add the small decision checklist

The point is not to make the model smarter. The point is to make it surface the decision before it barrels into implementation.

## Decision quality
On a non-trivial or hard-to-reverse decision, a user correction, or a repeated
failed fix, apply these checks before committing:

1. Verify what exists. Before proposing a new abstraction, file, dependency,
   or approach, confirm the existing system cannot already do it.
2. Name assumptions with confidence: high / medium / low. Flag any low-confidence
   assumption that would change the answer if wrong.
3. Trace consequences in practice: rollout, maintenance, consumer impact, and
   what breaks at 3 a.m.

Lead with a recommendation. If uncertain, recommend the option safest to be
wrong about and say why. For genuinely irreversible decisions with missing
context, "pause — here are the options; don't choose yet" is itself a
recommendation.

Add routing rules if your agent supports them:

- Architecture fork, migration strategy, API design, or any decision expensive
  to reverse → apply the decision-quality checks. Do NOT skip this because
  you're mid-flow.
  "Feeling productive" while coding is the exact moment you're most likely to
  skip the check that would catch the mistake.
- User corrects your approach or redirects mid-work → apply the checks. The
  correction means a trigger fired that you missed.
- Retrying the same fix mechanism without a new hypothesis, OR about to accept
  a user-reported bug → stop tweaking,
  restate the problem, check which constraints are real vs assumed.
- Evaluate options, compare approaches, "which should we use" → compare
  alternatives before choosing.

2. Standalone rules

If you only paste one section, paste this. These hold on their own.

Decisions live in the source, not the chat

The agent won’t treat a change you only said as authoritative — and it’s usually right not to. Make it stick by committing it.

## Decisions
Authoritative decisions live in the source — the spec, this file, the code —
not in chat. When something changes, update the source and mark it
"SUPERSEDES: <old>". Re-read the source before acting; a change mentioned only
in conversation is a suggestion, not a decision.

Review with a different model, not more personas

A “panel of experts” on one model is one model wearing hats — it agrees with itself. Real independence is a different model.

## Review
For review that matters, get a second opinion from a DIFFERENT model — not more
personas in this session. Same-model agreement is weak signal; what's useful is
where two models disagree. It's evidence you weigh, not a verdict you hand off.

Distrust the fluent summary — spot-check the raw

The most reliable finding, and the one that bit me most. Bake the habit in.

## Summaries
Treat any summary — a subagent's report, a test digest, your own recap — as a
claim, not a fact. Before acting on its key detail, check it against the raw.
Fluency is not correctness.

Long sessions: reset, don’t hoard

For staying on track, a short fresh session seeded from a source-of-truth file beats a long one carrying everything — less drift and fewer tokens.

## Long sessions
When a thread has run long, prefer a fresh session seeded from the
source-of-truth file over carrying full history. Re-ground from the artifact,
not the conversation's memory of it.

Scoping — pacing, not picking

What to do next, in what order. The full why is in The Brief; the rule itself is short.

## Scoping — order, not whether
For work you want done anyway, the only question is sequence; the axis is
coupling, and the cost to price is the human's downstream cost (which doesn't
parallelize), not your effort. Do independent, obviously-mechanical work now, in
parallel — it's cheap, and deferred it's the stuff you lose (you misjudge quick
work as unimportant, so your "skip it" read is the unreliable part). Leave work
coupled to a still-unsettled hard call — doing it now is rework when the call
lands; let the hard path incubate, and absent a real deadline don't rush it.
Review the settled state once. The context-switch tax isn't loop length — it's
leaving with a full head, several half-resolved forks to keep warm; so the cheap
place to stop is a clean seam, forks closed and the next task standing on its
own. A heuristic, not a law: it only has to beat the default, and genuine
urgency still jumps the queue.

3. One for you, not the config

This one’s a human habit — I tried to automate it and it over-fired (started rationalizing the very drift it was meant to catch). Keep it as your check, not a rule:

When a session feels productive, that’s the moment to ask: are we still solving the right problem? Open a fresh window, paste only the current state and the original goal, and see if it still reads as the same problem. The dangerous moment isn’t when it’s going badly — it’s when it’s going well and you’ve stopped noticing the drift.

Good advice and good automation are not the same thing. That distinction is itself one of the findings.

Why trust any of this: every rule above was tested (blind, cross-model, with guards against the tool over-firing), and most of what I tried failed or was already known. The full proof — including the experiments that didn’t work — is in The Brief.*