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.jpg…11.jpg) - A scene description file and a
.lrclyrics 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:
- Complying with a rule (following it when prompted or in-context)
- Citing a rule (reproducing it verbatim)
- Applying a rule (using it correctly in the scenario it was written for)
- 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)
-
Training-data recall. “LLMs have seen corporate markdown.” — True, but the naming convention
TASK-{date}-{seq}-{sender}-to-{recipient}.mdis 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.” -
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.)
-
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:
- 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.
- 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.
- 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)
- Essay (English) with all four memos, four screenshots, agent quotes, evidence archive: github.com/joinwell52-AI/FCoP/essays/fcop-natural-protocol.en.md
- Dev.to mirror (same content, nicer reading experience): dev.to/joinwell52/…
- Essay (Chinese original) on GitHub: github.com/joinwell52-AI/FCoP/essays/fcop-natural-protocol.md — the Chinese version was written first; the English above is translated
- Evidence folder (4 Cursor screenshots, 4 agent-written memos, full raw JSONL transcript): essays/fcop-natural-protocol-evidence/
- The FCoP protocol itself (
.cursor/rules/pattern we use): github.com/joinwell52-AI/FCoP
Discussion — what I’d love to hear from Cursor users
- 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.
- Is “internalization” the right word, or is it smuggling in too much? How would you describe the observation without anthropomorphising?
- 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.
- 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.


