Stage 11: Make your agents remember

The short answer

AI coding agents may keep some memory between sessions, but you cannot count on it to hold the legal and security decisions you made last week. Write those decisions into the instruction file each agent reads on every run (AGENTS.md, CLAUDE.md or an always-on Cursor rule), so a new feature cannot quietly add a tracker, put a secret in browser code or skip consent. Then run one audit prompt across all ten areas before each launch, and again whenever you add a vendor, a form, a price or an AI feature. Agent memory is recall; a file in your repo is the rule.

Why this matters

Most cases in this course are a promise or a setting that was right once, and then drifted away from what the code did.

• Agents change things nobody reviews. When Supabase changed how new tables are exposed, it gave this reason: "agents, CLI scripts, and AI platforms create tables too, and many of those operations do not have a human reviewing the diff" (Supabase changelog).
• Healthline, $1.55 million. In July 2025, California's Attorney General settled with Healthline. Its cookie banner did not turn off tracking cookies when a visitor unchecked the box, and it kept sharing data after people opted out (California Attorney General).
• Todd Snyder, $345,178. In May 2025, the California Privacy Protection Agency fined this retailer because its privacy portal was set up wrong and did not process opt-out requests for 40 days (CPPA).
• Tractor Supply, $1.35 million. In September 2025, the same agency said Tractor Supply did not set up its site to honor opt-out signals until July 2024, and its privacy policy lacked required parts (CPPA).
• OkCupid. In March 2026, the FTC said OkCupid's policy promised not to share personal data except as the policy listed, and then gave nearly three million user photos plus location data to an unrelated third party. These are allegations, and the FTC lists the case as pending (FTC).

Each needed someone to remember a decision every time the code changed. This stage gives that job to a file.

Core concepts

Why your agent forgets

An AI coding agent is a tool such as Claude Code, Codex or Cursor that reads and writes code for you. Some agents keep memory between sessions: Claude Code's auto memory is on by default (Claude Code memory), and Codex has optional memories. Treat that memory as recall, not as the rules. Codex's own docs call memories a recall layer, not the only source for rules that must always apply (Codex memories). Rules that must always apply belong in a plain text instruction file that the agent loads from your project at the start of every session. Claude Code reads CLAUDE.md. Codex reads AGENTS.md. Cursor reads AGENTS.md, and rule files in .cursor/rules only if they end in .mdc: a plain .md file there is ignored, and a rule applies to every chat only with alwaysApply: true in its frontmatter (Cursor rules). If you use more than one tool, keep one file and point the others at the same text. The Orchestrator Course shows how I link AGENTS.md to CLAUDE.md so both tools read the same rules.

Worked example. On Monday you tell your agent: "Never add a tracking script without asking me." It agrees. On Thursday, in a new session, you ask it to "add analytics so I can see sign-ups". It adds Google Analytics to every page, because Monday's rule was only in Monday's chat. If the rule had been one line in AGENTS.md, Thursday's session would have read it first and stopped to ask.

The rules block

A rules block is a short list of rules, one per line, that you paste into your instruction file. Each line is a decision from Stages 1 to 10, written as an order. "Be careful with privacy" changes nothing. "Do not add a script that sends user data to another company without asking me first" does.

Paste this into AGENTS.md or CLAUDE.md. For Cursor, use AGENTS.md, or a file such as .cursor/rules/launch-rules.mdc whose first lines are:

---
alwaysApply: true
---

Replace every part in <ANGLE_BRACKETS> with your own facts. Delete a line only if you are sure it does not apply, and write down why.

LAUNCH RULES: legal and security. Follow them on every change.

Data access and secrets
- Every new table gets Row Level Security and an ownership policy in the same change; never grant a table to anon without RLS.
- Secret keys stay on the server; never put a secret in a NEXT_PUBLIC_ or VITE_ variable, in app code, or in git.

Third parties
- Do not add any script, SDK, font, pixel or API that sends user data to another company without asking me first.
- Approved vendors today: <LIST EVERY VENDOR, FOR EXAMPLE SUPABASE, STRIPE, POSTHOG>.
- When I approve a vendor, add it to <PATH TO YOUR PRIVACY POLICY> and <PATH TO YOUR VENDOR LIST> in the same change.

Paperwork
- The privacy policy must match the code; if a change collects new data or sends it somewhere new, update the policy or stop and tell me.

Consent
- No analytics, session replay, ad pixel or chat widget may load before consent for visitors in <REGIONS WHERE YOU ASK FIRST, FOR EXAMPLE EU, UK>.
- Session replay stays off in code (disable_session_recording: true), not only in a vendor dashboard.

Sensitive data and kids
- This app is for people aged <MINIMUM AGE, FOR EXAMPLE 13> and older and is not directed to children; never add age-based features without asking me.
- Never send health-related events, page titles or URLs to any analytics or ad tool; ask me before any feature collects health data.

Accessibility
- Every image has alt text, every form field has a label, every control works by keyboard with a visible focus, and text contrast is at least 4.5:1.

AI disclosure
- Any chat or reply written by AI says so at the start; current AI providers that receive user content: <LIST YOUR AI PROVIDERS>.

User content
- If a change lets users post, upload or share content, stop and tell me first: we need a DMCA agent, a takedown path and a report path before launch.

Subscriptions
- Every pay button shows the price, the billing period, that it renews automatically, and how to cancel; cancelling works online where people subscribe.

Email
- Every marketing email has a one-click unsubscribe, our postal address <YOUR POSTAL ADDRESS>, and no marketing inside receipts or password emails.
- Before any marketing send, check the opt-out list in <WHERE YOU STORE OPT-OUTS>.

Evidence
- Never say a rule is met without the file and line that proves it; when you are not sure a rule applies, ask me.

The block will not make an agent perfect. It turns a silent change into a question.

Pin decisions in code, not in a dashboard

A setting in a vendor's web dashboard is not in your repo. Your agent cannot see it, and one click can change it. Where the vendor offers a code setting, use it.

Session replay is a recording of what a visitor does on your page. PostHog, an analytics tool, has two layers: a project setting in the dashboard, and settings in code. Once the project setting is on, the web code records from page load unless you turn it off (PostHog JS config, PostHog replay controls). Opted out by default means the tool captures no events or replays until the visitor says yes (PostHog data collection).

Worked example. This start-up code keeps replay off in code and captures no events or replays until consent. Confirm in your browser's network tab that nothing is sent before Accept:

posthog.init('<your project token>', {
  api_host: '<your PostHog host>',
  disable_session_recording: true,
  opt_out_capturing_by_default: true,
  autocapture: false
});
// After the visitor clicks Accept:
posthog.opt_in_capturing();

Now one line of your rules block ("Session replay stays off in code") can be checked against one line of code.

What I found when I audited Ducktate

I ran these checks on my own app, Ducktate, on 2026-10-09. It was a read-only check of the code, the live site and the analytics settings. Some items passed. Three stories show what an audit finds, and the open list shows what it costs to skip a rerun.

What passed. All 14 tables in my database migrations (the files that create and change tables) have Row Level Security on, and the Mac app ships only the publishable key. I did not query the live production database, and my migrations had drifted from it once before, so that check is still owed.

Story 1: my privacy policy said there was no analytics. The July version of my privacy policy said the app had no analytics or tracking. That was false. PostHog was on by default. An internal audit on 2026-07-25 caught it. On 2026-08-25 I rewrote the policy to name PostHog, Supabase, Slack, Claude and OpenRouter, corrected how Mac payments work (Stripe), and added a public page that lists my vendors.

That fixed the "no analytics" line, but not the whole policy. A website audit on 2026-10-09 found that the August policy still described tracking wrongly: it called PostHog "anonymous" while the account page sent the signed-in user's email to PostHog, and the policy page's meta description said "no tracking". The policy also missed tools added after August. On 2026-09-14, Google Analytics 4 went on 77 pages of the website. On 2026-09-24, a cloud feature that uses Google Cloud and Gemini models shipped. The app's own copy names them. The public policy and the vendor page do not. No rule in my agents' context said "update the policy when you add a vendor", so nothing stopped either change.

Story 2: unsubscribe meant "reply to this email". Until 2026-10-09, the only way to leave my marketing email was to reply and ask, and nothing recorded the request. I fixed it that day: a table of email preferences with RLS on, an unsubscribe function that uses a signed link, one-click unsubscribe headers that Gmail and other mail apps understand, a public unsubscribe page, and send scripts that check the table before sending.

Story 3: there was no way to delete an account. The 2026-07-25 audit searched the code for any way to delete an account and found none. A delete-account function and a retention purge landed the same day. On 2026-09-30, I added two more steps: the paid subscription is cancelled in Stripe before the account is deleted, and a queue table tracks each deletion until it finishes.

Still open as of 2026-10-09:

The lesson. A policy written once goes stale the day someone adds a tool. My August rewrite fixed one false line, kept others, and missed a new tool three weeks later. The fix is not a better policy. It is a rule in the agent's context that ties every new vendor to a policy update, and an audit that runs before every launch to catch what the rule missed.

A launch-day routine

The audit is not a one-time event. Rerun it, or the matching stages, when any of these happen:

Keep a one-page tracker inventory: every script, SDK and vendor, what data it gets, whether consent gates it, and whether you have a contract with it. California's privacy agency ordered Tractor Supply to scan and inventory its tracking tools (CPPA). Update it in the same change that adds the vendor. Re-test opt-out and unsubscribe paths after each deploy that touches them: Todd Snyder's broken portal ran for 40 days.

When to call a lawyer

This course gives you a list and sources, not advice. Book a lawyer licensed where you and your users are in these cases:

1. Health data. The FTC Health Breach Notification Rule covers health apps outside HIPAA, and since 2024 an unauthorized disclosure, such as sending health data to an ad platform, counts as a breach that needs notice (FTC). Washington treats a violation of its My Health My Data Act as an unfair or deceptive act under its consumer protection law (RCW 19.373.090).
2. Children under 13. COPPA applies if your app is directed to children or you know a user is under 13. Under the standard reading, the maximum civil penalty is $53,088 per violation, the 2025 level (FTC).
3. People in the EU. GDPR applies to a business outside the EU that offers goods or services to people in the EU, paid or free (GDPR Art. 3, unofficial copy). It has no small-business floor for that test. Get a review once you market to the EU or EU users become a real share of your base.
4. A breach. The clocks start when you find out: 72 hours to an EU data authority where feasible, and 30 calendar days to California residents (Stage 1 has the table). Call your lawyer the same day.

Key terms

The checklist

• Paste the rules block into the instruction file each of your tools reads, fill in every angle-bracket part, and commit it.Must doSource: Supabase changelog, GitGuardian
• Run the full audit prompt below before launch, and open the file and line for three PASS results yourself.Must doSource: Lovable security docs, OWASP A01:2025
• Turn every FAIL and every UNKNOWN into a dated ticket, and fix the Must items before you take sign-ups.Must doSource: CPPA on Todd Snyder, California Attorney General on Healthline
• Check your privacy policy against the audit's vendor list and remove every promise the code does not keep.Must doSource: FTC on OkCupid, CalOPPA Sec. 22576
• Keep a one-page tracker inventory and update it in the same change that adds a vendor, script or SDK.Must doSource: CPPA on Tractor Supply, GDPR Art. 28 (unofficial copy)
• Move safety settings that only live in a dashboard, such as session replay off, into code where you can.Should doSource: PostHog JS config, PostHog replay controls
• Rerun Stages 2 to 4 whenever you add a vendor, script, SDK, font or pixel.Must doSource: CPPA on Tractor Supply, PostHog data collection
• Rerun Stages 1, 3 and 5 when you add a form or a new kind of data, and update your app store privacy answers.Should doSource: Apple App Privacy details, Google Play Data safety
• Rerun Stage 9 whenever you change a price, a trial or the checkout.If it appliesSource: ROSCA, 15 U.S.C. 8403, California B&P Sec. 17602
• Rerun Stages 3 and 7 when you add an AI feature or a new AI provider.If it appliesSource: Apple App Review Guidelines, EU AI Act Art. 50
• Test your unsubscribe and opt-out paths after every deploy that touches them.Should doSource: FTC CAN-SPAM guide, CPPA on Todd Snyder
• Book a lawyer before you collect health data, direct your app to children, or learn that children under 13 use it.If it appliesSource: FTC Health Breach Notification Rule, FTC COPPA FAQ
• Book a lawyer review once you offer your app to people in the EU and they become a real share of your users.If it appliesSource: GDPR Art. 3 (unofficial copy), GDPR Art. 13 (unofficial copy)
• Write down the name and number of the lawyer you will call on the day you find a breach.Must doSource: GDPR Art. 33 (unofficial copy), California SB 446 digest, 50-state survey

The prompt for your agent

This is the audit for the whole course. Run it from the root of your project before every launch, and after any trigger in the routine above.

Audit this project against all ten areas of a pre-launch legal and security
checklist, in the order below. Do not change any code, config, migration,
dashboard setting, or document until I approve a plan.

For each numbered check, report PASS, FAIL, UNKNOWN, or NOT APPLICABLE, with the
file and line (or the table, setting, or page) that proves it, and one sentence
of reason. If you cannot prove an item from what you can read, report UNKNOWN.
NOT APPLICABLE needs a reason too (for example: "no upload feature exists, see
routes in app/"). Never report PASS without evidence.

1. Data access and secrets: every table has Row Level Security (or Firebase
   rules) with ownership checks; no secret key is reachable from browser or app
   code or from a NEXT_PUBLIC_ or VITE_ variable; login and reset are rate limited.
2. Third parties: list every script, SDK, font, pixel, and API that receives
   user or visitor data. For each, is it named in the privacy policy and the
   vendor list? Are dependencies locked, and is there a license or audit check?
3. Paperwork: a privacy policy and terms exist at public URLs and are linked in
   the footer, at sign-up, and in the app. Name every data flow the code has that
   the policy does not mention. Is there an in-app way to delete an account?
4. Consent: which trackers load before the visitor chooses? Is session replay
   off in code? Does "Reject" stop every tracker? Is Global Privacy Control read?
5. Sensitive data and kids: does any event, page title, or URL sent to an
   analytics or ad tool reveal health information? What does the app say about
   age, and is any feature aimed at children?
6. Accessibility: images have alt text, form fields have labels, controls work
   by keyboard with visible focus, pages have a language tag and a main
   landmark. Is there an accessibility test or statement?
7. AI disclosure: does every AI chat say it is AI at the start? Is every AI
   provider that receives user content named in the app and the policy?
8. User content: can users post, upload, or share? If yes: a DMCA agent, a
   takedown process, and a report path for intimate images.
9. Subscriptions: next to every pay button, are the price, billing period,
   automatic renewal, and cancel method shown? Can a user cancel online where
   they subscribed? Is a confirmation email sent?
10. Email: does every marketing email have a working unsubscribe, a one-click
   unsubscribe header, and a postal address? Is the opt-out list checked before
   each send? Are receipts and password emails free of marketing?

Then compare the results with the rules in AGENTS.md, CLAUDE.md, or
.cursor/rules. List any rule that is missing or that the code breaks.

End with a table: item, status, evidence (file and line), and the smallest fix
you suggest. Then stop and wait for my approval.

Tool notes. A tool setting is a second lock: Claude Code's plan mode, a Codex read-only sandbox, or a Cursor chat mode that does not apply edits. Then open the evidence for a few PASS lines yourself. If one does not hold, treat the whole report as unproven.

Common mistakes

• Leaving decisions in chat history. The next session never sees them.
• Writing rules as advice ("be careful with user data") instead of orders an agent can check.
• Keeping a safety setting only in a vendor dashboard, where one click or one default can undo it.
• Running the audit once at launch and never again. Three weeks after my policy rewrite, a new analytics tool made it wrong again.
• Reading UNKNOWN as "probably fine". It means nobody proved it.
• Spot-checking only the homepage. My fonts were clean there and not on the account page.

Check yourself

Resources

• Supabase changelog: tables not exposed automaticallyDocsFree

  A vendor's own statement that agents change things with no human reviewing them.

• PostHog: control which sessions you recordDocsFree

  How to keep replay off in code and start it only after consent.

• FTC: action against Match and OkCupidArticleFree

  What happens when a privacy policy and real data sharing drift apart.

• CPPA: Tractor Supply decisionArticleFree

  A fine that came with an order to scan and inventory tracking tools.

• California Attorney General: Healthline settlementArticleFree

  A cookie banner that looked right and did not block anything.

• FTC: Health Breach Notification Rule changesGuidanceFree

  Why health apps outside HIPAA need a lawyer and a breach plan.

• FTC: COPPA six-step compliance planGuidanceFree

  The FTC's own walk-through for apps that children may use.

• Privacy Rights Clearinghouse: breach notification laws, 2026ResearchFree

  The state deadlines your breach plan and your lawyer will need.

• The Orchestrator CourseCourseFree

  How I set up instruction files so several coding agents read the same rules.

Next stage

This is the last stage. Go back to the full checklist, paste the rules block into your project today, and run the audit before your next launch. If you have only an hour, start again with Stage 1.