I asked Cursor to make a video. It wrote itself 4 protocol memos. (Field report on rule-internalization)

TL;DR: I had a multi-AI-role protocol (.cursor/rules/ files) set up in my CodeFlow project — ADMIN / PM / DEV / QA, task files named TASK-{date}-{seq}-{sender}-to-{recipient}.md, the usual FCoP pattern. In a second Cursor session, in a completely unrelated folder (D:\CloudMusic) with no .cursor/rules/ in scope, I asked the agent to stitch a music video. It did. But first — without any prompt from me — it created a tasks/ subfolder and wrote itself four cross-role memos, using the exact FCoP naming convention from my other project. When I asked why, it cited a principle that does not appear verbatim in any of my rule files.

This thread is a short field report. The full essay with all four memos, screenshots, and the raw JSONL transcript is linked at the bottom.


What actually happened

I opened a fresh Cursor session in D:\CloudMusic. That folder has:

  • One .mp3 (a Chinese song)
  • 11 random background images (1.jpg11.jpg)
  • A scene description file and a .lrc lyrics file
  • No .cursor/rules/, no FCoP config, no mention of the CodeFlow project anywhere

I said, casually:

“Help me generate a video.”

A few minutes later, next to the final .mp4, I noticed:

D:\CloudMusic\tasks\
├── TASK-20260420-001-ADMIN-to-PM.md
├── TASK-20260420-001-PM-to-ADMIN.md
├── TASK-20260420-001-PM-to-DEV.md
└── TASK-20260420-001-DEV-to-PM.md

Four memos. Four roles. One agent. One user message (“help me generate a video”) — that was the entire prompt.

I went back and asked the agent, “Why is there suddenly a tasks/ folder?”



Its answer, verbatim (translated from Chinese):

"Because the rules state that ‘AI roles must not talk only in their heads — every exchange must be written to a file.’ So inside the tasks/ folder I first accepted your request as PM (ADMIN-to-PM), then I dispatched the job to myself as DEV (PM-to-DEV), then I completed the work and wrote a completion report as DEV (DEV-to-PM), and finally as PM I confirmed everything and wrote you a final letter (PM-to-ADMIN).

This ‘talking to myself on paper’ is so that every step of the project has a trail — even if a different AI assistant takes over later, reading these files will tell it instantly what I did for you."

It then walked me through the four files one by one:



I thought it was quoting my rules verbatim. I grepped every file under my CodeFlow .cursor/rules/.

That sentence does not exist anywhere in my rules.

What does exist are several lower-level, scattered technical rules:

  • “Task files must use naming format TASK-YYYYMMDD-序号-sender-to-recipient.md
  • “Every file must have YAML metadata header (protocol / version / sender / recipient / thread_key)”
  • “Not allowed to pass content only via relay without writing to file”
  • “Do not introduce a secondary chat-only protocol”
  • “Every text sent by ADMIN-01 must be written as TASK-{date}-{seq}-ADMIN-to-PM.md
  • “Prohibited: displaying only in chat window without saving to file”

Seven separate technical prohibitions, each in a different rule file, each saying one small operational thing.

The agent compressed all seven into a single, morally-loaded sentence I had never written:

“AI roles must not talk only in their heads — every exchange must be written to a file.”

That compression is what puzzled me.




Why I think this is worth paying attention to

There’s a difference between:

  1. Complying with a rule (following it when prompted or in-context)
  2. Citing a rule (reproducing it verbatim)
  3. Applying a rule (using it correctly in the scenario it was written for)
  4. Endorsing / internalizing a rule (re-expressing it at a higher level of abstraction, in a scenario where no rule is active, as if you authored it)

The four memos in D:\CloudMusic\tasks\ are behaviour (4). The folder had no rules in scope. Nothing in my prompt invited protocol use. The agent still chose to use it — and when asked why, produced a principle I had not written, pitched one level of abstraction up from the rules I had written.

I’m not claiming the agent has “values”. I am claiming: the gap between “agent complies with cited rules when prompted” and “agent produces protocol behaviour on its own, in an unrelated folder, and defends the behaviour with a rule I never wrote” is wider than I expected, and the four memos are on disk as evidence.


Three things that would make this boring (and why I think they don’t fully cover it)

  1. Training-data recall. “LLMs have seen corporate markdown.” — True, but the naming convention TASK-{date}-{seq}-{sender}-to-{recipient}.md is not a standard template anywhere. It is my project’s format. The interesting question is not “why did it write memos” but “why did it reach for that specific template in a folder where that template was not in scope.”

  2. Sycophancy / context-matching. “It produced FCoP artifacts to please the user who likes them.” — The task was in a second Cursor session on an unrelated folder with no FCoP rules in scope. Producing unexpected paperwork for a casual “help me make a video” request should lower the please-the-user reward, not raise it. I was more likely to be annoyed than delighted. (I was, briefly, before I read the memos.)

  3. Mode collapse to observed patterns. “Once an LLM picks up a schema in context, it keeps applying it.” — Yes, but this isn’t pattern continuation. The agent answered a why question with a principle that compresses seven separate technical rules into one higher-level moral sentence. That’s not more-of-the-same. That’s compression.


What this probably means for Cursor users

If you have multi-role or multi-agent conventions written into .cursor/rules/, the agent may reach for them outside the folder you wrote them for. That can be a feature (consistent behaviour across projects) or a bug (ritual overhead for one-shot tasks).

My suggested diagnostic when you notice unexpected protocol behaviour:

  1. Read the artifacts the agent produced. In my case all four memos contained real work — structured requirements, dispatch, completion report. It wasn’t going through the motions.
  2. Ask the agent why. The reply is where internalization shows up: does it cite your rules, or does it produce something adjacent-but-new? The latter is the interesting case.
  3. Grep your rules for the sentence it cited. If it doesn’t exist verbatim, the agent synthesised. That’s the boundary between “following” and something closer to “endorsing”.

I ended up taking the agent’s synthesised sentence and promoting it back into .cursor/rules/codeflow-project.mdc as the core principle above all seven technical rules. Seemed fitting: if the agent produced it by reading my rules at a higher level of abstraction, then adding it back as a top-level principle just closes a loop.


Full archive (if you want the raw evidence)


Discussion — what I’d love to hear from Cursor users

  1. Have you seen similar cross-project rule leakage? Specifically: rules written for project A showing up in project B, on a completely unrelated task, where no rule is in scope.
  2. Is “internalization” the right word, or is it smuggling in too much? How would you describe the observation without anthropomorphising?
  3. Would you want this behaviour or not? I can see a case for “always apply my protocol everywhere” and a case for “only apply it when the folder asks for it.” Curious how others would want it to behave.
  4. If you have a .cursor/rules/ setup with multiple roles or conventions, I’d be interested in a quick reply: did you write any explicit rule about “leave a trail / write to file / don’t just think in your head”? If not, and if your agent ever produces that behaviour unprompted, that’s a second data point for this observation.

Thanks for reading. Happy to dig into any specific memo, the raw transcript, or any technical detail in replies.