An AI agent doesn't fail loudly. It drifts — a slightly wrong brand claim here, a shortcut there, a "completed" task that was never verified — until one day the output is confidently, expensively wrong. I run the infrastructure of five brands through Claude Code and agent fleets, much of it on scheduled loops with no human watching. The only reason that works is that I stopped treating context files as notes and started treating them as standard operating procedures.
Here's the system.
Context files are SOPs, not suggestions
Every project I operate has a CLAUDE.md — a file the agent loads before doing anything. Most people write these like sticky notes: a few preferences, a tech-stack mention. Mine read like the operations manual you'd hand a new employee on day one, because that's functionally what they are.
A working CLAUDE.md for one of my brands contains the brand's positioning, voice rules with good and bad examples side by side, the exact content formula every piece must follow, claims the brand is and is not allowed to make, and explicit "never do this" lists. When an agent produces content at 3 a.m. with nobody reviewing it, that file is the difference between on-brand output and generic slop.
The test I apply: if I hired a competent stranger and gave them only this file, would they produce acceptable work? If not, the file is incomplete — and the agent will drift exactly where the file is silent.
Hard rules vs. preferences — and why the distinction matters
Not all instructions carry the same weight, and agents need to know which is which. I separate them explicitly:
Hard rules are non-negotiable and labeled that way in the file: never fabricate metrics, never touch these frozen pages, never deploy — a human runs the deploy script, never replace a client's images with stock or AI substitutes, never send an email without approval. These get words like "HARD RULE" and "NON-NEGOTIABLE" in the text, because emphasis genuinely changes compliance.
Preferences are defaults the agent may override with judgment: formatting choices, tone calibration, which library to reach for first.
When everything is written with equal weight, agents treat everything as a preference. The drift starts precisely at the rules you didn't mark as rules.
Skills: procedures an agent loads on demand
CLAUDE.md is always-on context; skills are procedures loaded when a task matches. I maintain custom skills for repeatable workflows — a blog framework that encodes the on-page structure every post must follow, a photo-culling workflow, an ad-production pipeline, a book-production process.
The principle: any workflow I've corrected twice becomes a skill. If I had to tell an agent "no, do it this way" more than once, that correction is now a documented procedure with steps, checks, and examples — not something I hope the next session remembers. Skills turn one-time fixes into permanent capability, which is the core loop of the whole approach I described in what running five brands with agent fleets actually looks like.
Memory: feedback that survives the session
Sessions end; lessons shouldn't. I run a memory system — an indexed set of markdown files — that persists across every conversation. It has two main record types:
- Feedback records: "never do X, always do Y," written the moment I correct an agent. Example entries from mine: verify a link is live before emailing it; use the brand's real logo file, never a recreation; specific wording rules for a brand's manufacturing claims.
- Reference records: infrastructure maps, account structures, deploy gotchas — facts an agent needs but shouldn't rediscover every session.
A top-level index file surfaces the most dangerous rules first. New sessions read the index before touching anything. Without this, every session starts naive and repeats last month's mistakes; with it, the fleet compounds instead of resetting.
Verification before completion
The most dangerous agent behavior is declaring victory. "Done" from a language model means "I produced output," not "it works." So completion is defined operationally, never rhetorically:
An agent may not report a task complete until it has exercised the thing end-to-end — loaded the page, run the script, checked the HTTP status, viewed the generated image. I keep a standing rule that any asset must be viewed before being presented, because generation pipelines fail silently and an unexamined "success" is how a broken image ends up in front of a customer.
For scheduled automation the bar is higher still: "armed" means the launchd job or cron entry is verified as loaded and a manual end-to-end run has succeeded — not that the config file exists. My authority engine publishes on a 2-hour scheduled loop; that only earns the label "running" because the schedule itself was tested, not assumed.
Customer-eye QA
Technical verification catches broken; it doesn't catch bad. The last gate is looking at the output the way the end user will: open the page at real size in a real browser, read the email as the recipient, watch the video without the creator's forgiveness. Agents check DOM elements and exit codes; a customer sees an overlapping header and an off-brand headline. I encode this as an explicit final step — render it, look at it, compare it against a known-good reference — because "the tests pass" and "a buyer would trust this" are different claims.
The anti-drift checklist
If you're running agents on real work, here's the system in order:
- Write
CLAUDE.mdas an operations manual — positioning, voice, formulas, forbidden actions — not a sticky note - Include good AND bad examples side by side; agents calibrate on contrast
- Mark hard rules explicitly and separate them from preferences
- Convert every repeated correction into a skill — a named, documented procedure
- Maintain a persistent memory index; write feedback records the moment you correct an agent
- Define "done" operationally: the agent must exercise the output end-to-end before reporting completion
- Require customer-eye QA as the final gate — view the deliverable as the buyer will
- Verify scheduled automation is actually armed (job loaded, manual run succeeded), never just configured
None of this is exotic. It's the same discipline any operations leader applies to a human team — documented procedures, explicit non-negotiables, institutional memory, inspection before shipping — applied to a workforce that reads instructions perfectly and forgets everything between shifts.
This is also the layer most people skip, which is why "we tried agents and they were unreliable" usually means "we ran agents without SOPs." The tooling matters less than the operating system around it — more on that in what an AI systems builder actually does and how I run agents on schedules overnight.
FAQ
How long should a CLAUDE.md file be?
As long as an onboarding doc for a competent stranger needs to be — mine run from one page for simple projects to several pages for a full brand. The constraint isn't length; it's that every line must earn its place, because context is the agent's working attention.
What's the difference between putting something in CLAUDE.md vs. a skill?
CLAUDE.md holds always-relevant context: identity, rules, constraints. Skills hold task-specific procedures loaded on demand: how to produce a blog post, how to cull a photo shoot. If it applies to everything, it's context; if it applies to a workflow, it's a skill.
Can this work with agents other than Claude Code?
Yes. The pattern — persistent SOP context, hard-rule separation, memory records, verification gates — is tool-agnostic. Claude Code happens to make it natural with CLAUDE.md and skills, but the discipline is what stops drift, not the file format.
— Italo Campilii. If you're building something that needs this kind of operator, get in touch.