The protocols that keep AI agents sharp across complex, real-world work. Not templates. Actual engineering for founders, coaches, and creators whose standards cannot be reduced to generic prompts.
For any task where the input is large and the risk of quality trail-off is real.
Activation Triggers
The Protocol
Create a persistent notes file before starting. This file IS the continuity. Not memory. Not context window. The file itself.
If the session dies mid-task, the next session picks up from that file. No progress lost. No re-reading the source.
Never process everything at once. Break input into sections, process each thoroughly, write findings immediately. Never move to the next section until the current one is recorded.
Preserve original language. The notes file must contain the source's actual words, not a lossy restatement.
## Section 3: Pricing Strategy
The author recommends tiered pricing
with entry-level options to reduce
friction. They suggest anchoring high
and offering a mid-tier as the target.
## Section 3: Pricing Strategy (pages 14-16) "The biggest mistake I see coaches make is pricing from fear. You anchor at the transformation value, not your comfort level." (p.14) "Three tiers. Top tier is the anchor -- nobody buys it but it makes the middle tier feel reasonable." (p.15) Key concept: Anchor > Target > Safety Net
Every 3-4 sections, a mandatory self-assessment fires. Not optional. Not skippable.
If the answer to any of these is yes: hard stop. See step 4.
When quality starts degrading, the correct move is to surface it directly rather than push through with diminishing returns.
After completing all sections, key concepts get broken into structured knowledge entries that can be recalled and applied in future conversations.
Each entry carries enough detail to actually advise from, not just reference. The goal is recalled knowledge with real substance, not just pointers to where the info lives.
When genuinely done with quality maintained throughout:
Why This Exists
Designed around how AI actually fails
"You will probably get tired and confused and lose steam. We need a plan for what you do when that happens."
"I notice you often start work off strong and then sort of trail off."
The protocol exists because quality degradation on long tasks is predictable. Without enforced checkpoints and file-based continuity, agents work well for the first 40% and coast through the rest. This skill changes that default.
What Causes Trail-Off
Anti-Patterns
The failure modes this protocol is specifically engineered to prevent.
For structural questions where you need source-grounded analysis, not news summaries or punditry.
Activation Triggers
The Protocol
Start with a live, structural question -- not "what happened" but "what system is being revealed." Define the time horizon (30/60/90 days), audience, and your analytical lens. The question shapes every source decision that follows.
Bad: "What's happening with AI?" Good: "Who controls the infrastructure layer under AI models, and how does that control translate into geopolitical leverage over the next 12 months?"
Cast wide across at least five source classes. Primary documents, technical sources, financial filings, policy and regulatory, media and narrative analysis, and human impact. The goal is not "more sources" but "different kinds of evidence that can contradict each other."
Sources: 4 news articles, 2 blog posts All from the same 48-hour news cycle All citing the same original report No primary documents consulted
Sources: 32 across 6 classes ├─ Primary: SEC filings, procurement notices ├─ Technical: GitHub repos, architecture docs ├─ Financial: Earnings calls, capex reports ├─ Policy: Export controls, lobbying records ├─ Media: Trade press + adversarial analysis └─ Human impact: Labor data, energy audits Tier 1 (primary): 8 | Tier 2 (secondary): 16 Tier 3 (situational): 8
For each source cluster, build a source and scope ledger: domain, timeframe, search terms, sources consulted, classification, and what the source can and cannot prove. Then identify the primary driver and explain the causal mechanism -- how A leads to B, not just what's happening.
Test the central thesis against structured alternatives. H0 is your primary hypothesis. H1 is the null -- the pattern is noise or temporary. H2 names an alternative driver. H3 is a model miscalibration check -- where might you be pattern-matching too aggressively?
The depth pass is not optional. It pressure-tests the core brief through eight analytic layers. This is what separates intelligence analysis from news commentary.
Eight depth layers: Source conflict map (where sources disagree and why), Actor incentive map (wants, constraints, public story, what to watch), Constraint ranking (which operational limit binds first), Narrative conflict (official story vs material reality), Exogenous shock map (external events that could change everything), Forecast states (three scenarios with probability and confirming signals), Model miscalibration log (overfit, underweight, correlated-source risk), Watch indicators with thresholds (specific, observable, not vague).
Watch for: - "More data centers announced" - "Increased government attention" - "Market shifts"
Watch indicators: ├─ 3+ state utility commissions approve │ data-center-specific rate structures │ within 90 days → State B confirmed ├─ Export control expansion to include │ model weights (not just chips) │ → H2 probability rises to 60%+ └─ Major cloud provider announces sovereign hosting in 2+ non-allied nations → reweight constraint map
Before calling a brief finished, answer eight questions. If the answers are weak, the brief is not deep yet.
The public version should not look like an intelligence report. Start from the live thing people saw. Name the structure underneath it. Give 2-3 concrete signals. Explain the causal mechanism. Name why the obvious interpretation is too small. Say what to watch next. End on the structure reveal, not a CTA.
A good brief should make the reader feel: "I saw the event. They saw the system." That is the point. The product feels like intelligence because of structure and source transparency, not because of secret information.
Do not perform certainty. Do not flatten the issue. If evidence is thin, say so. Preserve uncertainty without becoming mushy.
Why This Exists
Designed around how analysis actually fails
Most "analysis" is news recaps with opinions stapled on. No source ledger. No competing hypotheses. No acknowledgment of what the analyst might be wrong about.
The depth pass exists because first drafts of intelligence always feel done. They aren't. The layers that catch overfit, correlated sources, and missing constraints are the ones that make the brief trustworthy.
This protocol exists because the gap between "I read about it" and "I understand the system" is exactly the gap the depth pass fills. Source transparency plus structured uncertainty plus specific observable indicators. That's the methodology.
What Breaks Analysis
Anti-Patterns
The failure modes this protocol is specifically engineered to prevent.
For any message that asks you for an action, approval, choice, or ruling, so you can answer in one read without digging for context.
Activation Triggers
The Protocol
Three to five plain sentences explaining what is happening, defining unfamiliar names, and saying what you would observe. Written for a reader joining cold.
One direct plain-English question. Not a statement, not a topic, an actual question you can answer.
Every real option, including defer or do nothing when real. For each option: how you would experience it, then its pros and cons.
First, one or two sentences on how an expert in the domain would proceed, named plainly. Then one recommendation with the decisive reason. If it differs from the expert path, the ask says why. It is never hidden inside the context.
The exact answer, action, or input needed. Required on every ask, so you never have to guess what a reply should look like.
Gate and Contracts
Before a real-bucket ask goes out, the actual message is checked: premise verified and still unanswered, all five parts present and in order, context of three to five sentences, a true question, pros and cons on every option, an expert path before the recommendation, and an exact request. Any NO means the ask is not sent. It is rewritten and the full check runs again. Mentioning all five labels is not enough if a part lacks substance.
Everything outside the real bucket is not an ask. The agent decides, executes when ready, and sends one line naming what was delivered, with a revert line naming the command or commit to undo it. Before that line goes out, the work must match the sources at full parity and must work end to end, observed rather than represented by a flag. An ask drafted on work that is already built or already decided is a defect.
Any ask that would authorize a commit (to code, a published document, or live configuration) carries three things: the actual diff at a named path, byte-identical to what would be committed; a plain-language reading of that diff, hunk by hunk; and the verifier-fail branch, stating what happens if an independent check fails after approval. An approval given on a description whose artifact later changes is not an approval on the new artifact.
What Breaks Asks
Anti-Patterns
The failure modes this protocol is specifically engineered to prevent.
Answer a few questions about your business. Get a custom plan that shows where AI fits the work only you can do and what to build first.
Get My AI Roadmap →