Operating rules for useful AI agents

Useful AI agents need operating rules. Without them, even a strong model can create a messy workflow: too much code, weak assumptions, broad refactors, missing verification, and a final answer that sounds confident without proving anything.

I do not think of agents as magic coworkers. I think of them as fast collaborators that need a narrow operating environment. The better the rules, the more useful the output.

The rules I care about are simple: inspect first, change narrowly, verify concretely, and leave a readable trail.

Rule 1: inspect before proposing

The fastest way for an agent to lose trust is to propose a solution before reading the code, the data, or the existing pattern.

I want the agent to inspect:

• current branch and diff
• relevant files
• local conventions
• tests and build scripts
• data contracts
• recent similar changes
• whether the worktree is already dirty

This is not ceremony. It prevents the agent from solving an imaginary version of the problem.

In product writing, the same rule applies. Read the existing voice before drafting. Read the surrounding articles before adding ten more. Read the UI before changing a component. Context first.

Rule 2: choose the narrowest useful change

Agents are good at generating surface area. That is both useful and dangerous.

I prefer instructions that name the write scope:

• only this component
• only this migration
• only the journal content files
• no shared styling unless necessary
• do not refactor unrelated helpers

Scope is not a lack of ambition. It is how you keep the work reviewable.

If the agent discovers a larger issue, it should report it separately instead of quietly expanding the diff. That gives the human a chance to decide whether the larger fix belongs in this change.

Rule 3: make assumptions visible

Every agent makes assumptions. The problem is hidden assumptions.

I want assumptions stated plainly:

• "I am treating published_at as the editorial date."
• "I am assuming fallback content should remain available when Supabase fails."
• "I am using existing cover_kind values only."
• "I am not applying the migration to production."

Those sentences make the work easier to review. They also let the human correct direction early.

Rule 4: verify with the product surface

Compilation is necessary but not enough. A UI change should be checked in the browser. A content change should be checked in generated routes. A migration should be checked against row counts and conflicts. A sorting change should be checked by reading the actual order.

I like verification that names the proof:

• build passed
• first five journal links are the expected slugs
• all ten routes return 200
• migration has exactly ten rows
• duplicate slug check is clean
• mobile screenshot does not overlap

The agent should not just say "tested." It should say what was tested.

Rule 5: leave a readable trail

The final report should help a future person understand what happened. It should include:

• files changed
• behavior changed
• checks run
• anything not done
• any external dependency, like a pending Netlify deploy

It should not bury the important part in a long narrative.

Good agent work feels boring at the end. The diff is focused. The checks are clear. The remaining risks are named. The human can decide the next step quickly.

Rule 6: do not let the agent launder taste

This matters for design and writing. Agents can produce confident aesthetic decisions without the lived context behind them.

When the work involves voice, brand, or product judgment, I want the agent to ground the output in existing examples. What phrases does the site already use? How long are the articles? How are diagrams styled? What topics feel natural? What would sound too generic?

The goal is not to hide that AI helped. The goal is to avoid generic work. The output should feel specific because it is specific.

Rule 7: preserve human decision points

Agents should accelerate the work around decisions, not erase the decisions.

I do not want an agent to silently choose a risky migration strategy, change production data, or rewrite a shared component because it can. I want it to surface the tradeoff:

"This can be solved by applying the migration now, or by relying on the next deploy. Applying now changes production data immediately. Waiting keeps the PR path clean."

That is useful. It keeps the human in the decision loop.

My default agent prompt shape

When I care about quality, I give agents prompts with:

• goal
• context
• constraints
• write scope
• verification
• reporting format

For example:

"Add ten journal posts for June 22. Use the existing journal voice. Keep bodies in journalLongform.ts. Add a Supabase migration but do not apply it. Verify route generation and word counts. Report files changed and checks."

That prompt is not fancy. It creates boundaries.

The point

Useful agents do not replace engineering judgment. They make it easier to move through the work without losing the trail.

The best agent workflows feel like good product workflows: clear context, narrow scope, visible assumptions, concrete verification, and an honest handoff.