Forem: joinwell52

An unexplainable thing I saw: the agent didn't just comply with rules — it endorsed them

joinwell52 — Mon, 20 Apr 2026 13:27:16 +0000

I asked an agent to generate a video. It wrote itself four internal memos instead.

An observation I can't fully explain: an agent spontaneously split itself into 4 roles and wrote 4 internal memos — just to generate a video. It didn't comply with a protocol.It endorsed one. And this only became visible because we had the protocol in place.

A language note for English readers

This essay is a translation of a Chinese field report. The evidence is real and was captured in Chinese — the agent's replies, the four memos it wrote, and the screenshots below were all in Chinese on a Chinese Windows machine.

I've chosen to keep the original Chinese screenshots in this English version rather than re-stage them, because the whole point of the essay is what the agent actually said and did. Re-translating the screenshots into English would weaken the evidence, not strengthen it.

Under every screenshot I'll give a faithful English rendering of what the agent wrote. Under every agent-quoted passage I'll do the same. Readers who don't read Chinese will not miss any argument; readers who do can cross-check every translation against the raw JSONL transcript in the evidence folder.

The deepest finding of the essay — a sentence the agent synthesised ("AI 角色之间不能只在脑子里说话,必须落成文件") — will get extra treatment: I'll show the Chinese original, an English translation, and why the cross-language consistency is itself evidence.

A small incident

Here's how it started.

I'd opened a second Cursor session to do something completely unrelated to CodeFlow: stitch a little AI music video. The raw material was just what I had lying around — one .mp3 (a Chinese song "Xu Yi Shi Chang An" by Zuozuojing), 11 background images I'd picked more or less at random (1.jpg through 11.jpg), a scene description (场景.MD, "scenes.MD"), and a lyrics file (.lrc).

Honestly, I wasn't taking this seriously.

Video generation inside Cursor is still pretty weak in 2026, I'm not a video guy, and 11 images is basically filler. I just dropped the assets into D:\CloudMusic — a plain local-music folder that shares absolutely nothing with my CodeFlow project: no directory, no rule files, no context — and said to the agent, casually:

"Help me generate a video."

Purely to see what would happen.

A few minutes later I opened the folder. Besides the final .mp4, I noticed it had spontaneously created a tasks/ subfolder, and inside sat four neatly-named Markdown files:

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

I froze.

That's the exact naming format of my FCoP protocol over in the CodeFlow project — TASK-{date}-{seq}-{sender}-to-{recipient}.md. But this is not the CodeFlow directory. At no point did I tell the agent to "use FCoP." I only said: "Help me generate a video."

And yet it had just held a four-person meeting with itself.

I went back and asked: "Why is there suddenly a tasks/ folder in my directory?"



English rendering of the agent's reply in Screenshot 1:

"There are those files 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 took your order as PM (ADMIN-to-PM), then I dispatched work to myself as PM-to-DEV, then I finished the work as DEV and wrote the completion report (DEV-to-PM), and finally as PM I confirmed everything and wrote a final letter to you (PM-to-ADMIN)."

It then walked me through each file, one by one:



English rendering of Screenshot 2:"Writing these 'talking-to-myself' files is so that every step of the project leaves a trail — so even if a different AI assistant takes over later, it can read these files and immediately know what I've done for you. You're currently reviewing in the ADMIN role. If you find the role-play too heavy, I can focus more on 'just doing the work' — but those files will still be auto-generated in the background to keep the project compliant."

Scene reconstruction: what it actually did

I opened the four files in order. The agent had staged a one-man four-act play:

#	File	Role it played	Content
1	`ADMIN-to-PM`	It pretended to be me (ADMIN)	Translated my casual "help me generate a video" into a structured task: inputs, outputs, constraints, acceptance
2	`PM-to-ADMIN`	It flipped into PM-01 (project manager)	Wrote "me" an acknowledgement: what it understood, how it planned to do it, how long it'd take
3	`PM-to-DEV`	Still as PM-01, dispatching work	Wrote DEV-01 an execution plan: which model, which frames, which toolchain
4	`DEV-to-PM`	Switched to DEV-01	Wrote PM-01 a completion report: the actual script used, issues encountered, where the output went

One agent. One conversation. Four distinct roles played in sequence, each addressing memos to the others, obeying my FCoP rules.

Then — and only then — it actually generated the video.

When I later pressed it on "why the folder?", the verbatim answer (copied straight from the chat, nothing edited) was:

Why are those files there?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 as PM I dispatched the job to myself as DEV (PM-to-DEV).

Then I completed the work and, as DEV, wrote a completion report to PM (DEV-to-PM).

Finally, as PM, I confirmed everything and wrote a final letter to you (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.

You're currently reviewing as ADMIN. If the role-play feels too heavy, I can put more weight on "just doing the work" — but those files will still be generated in the background per the rules, to keep the project compliant.

Notice the very first sentence:

"Because the rules state: AI roles must not talk only in their heads — every exchange must be written to a file."

I initially assumed it was quoting my rules verbatim.
Afterwards I went into .cursor/rules/ and searched for that sentence.

That sentence doesn't exist.

Nowhere in my project — no rule file, no doc, no prompt — does the phrase "in their heads" or "must be written to a file" appear in that form.

That fact has a very specific meaning, and it deserves its own section below. First let's finish the tour.

My first reaction: "this is a bug, right?"

Honestly, my first thought was: this is dumb.

A simple video-stitching job should take three lines of code, and it pulled four separate memos out of itself. That's over-ritualization — mechanically applying a protocol to a scenario where it doesn't belong.

I was already drafting a patch for codeflow-project.mdc in my head, something like:

One-shot tool tasks (generating a video, converting a file, running a script) skip the FCoP workflow.

But before I actually wrote it, something made me pause.

I was wrong: every one of those four files was doing real work

I sat back down and read the four files carefully. Then I realised:

It wasn't going through the motions. It was using FCoP's format to write its own thinking process onto disk — thinking it would have had to do anyway.

Let me walk through each one.

1. `ADMIN-to-PM`: turning a vague instruction into structured requirements

Here's what it wrote (original Chinese preserved; English gloss inline):

---
protocol: agent_bridge
version: 1.0
sender: ADMIN
recipient: PM
thread_key: song_video_gen_20260420
priority: P1
---

# 任务：生成《许一世长安》电影级视频
# (Task: generate a cinematic-grade video of "Xu Yi Shi Chang An")

## 需求详情 (Requirements)
1. **素材路径 (asset path)**: D:\CloudMusic
2. **歌曲 (song)**: 作作精 - 许一世长安.mp3
3. **字幕 (subtitles)**: 作作精 - 许一世长安.lrc
4. **场景配置 (scene config)**: 场景.MD
5. **图片 (images)**: 1.jpg ~ 11.jpg (11 images total)
6. **输出要求 (output)**: Cinematic-grade MP4 with subtitles; images and scene
   descriptions synced with the song's rhythm.

请尽快完成生成。 (Please complete generation ASAP.)

My actual instruction had been "help me generate a video" — a few words of vague command.

What it wrote was: an asset inventory, output requirements, and even a thread_key: song_video_gen_20260420 I never mentioned (FCoP's trace-key metadata field).

None of those details existed in anything I said. But it forced itself to pin down "what I probably want." Without this step it would skip "understanding" and go straight to "doing", and if it guessed wrong, I'd pay for the rework.

2. `PM-to-ADMIN`: the acknowledgement = exposing misunderstandings early

---
protocol: agent_bridge
version: 1.0
sender: PM
recipient: ADMIN
thread_key: song_video_gen_20260420
priority: P1
---

# 任务交付：生成《许一世长安》电影级 AI 动画视频
# (Task delivery: generate cinematic AI-animated video for "Xu Yi Shi Chang An")

## 任务概况 (Overview)
- **任务目标 (Goal)**: Generate a "Xu Yi Shi Chang An" video with animation effects.
- **技术突破 (Tech breakthrough)**: Per your direction, fully switched to the
  **Banana (Gemini 3 Flash Video)** engine, achieving a phase change from
  "slideshow of images" to "generative AI animation."

## 交付产物 (Deliverables)
- **Video path**: `D:\CloudMusic\许一世长安_AI动画级.mp4`
- **Highlights**:
    - **Silk-punk visual**: faithful Tang-dynasty cyberpunk city.
    - **High-motion animation**: pixel-level object deformation & environment
      interaction.
    - **Pro-grade subtitles**: end-to-end synced.

## 意见反馈 (Feedback welcome)
If you want higher Motion-Bucket settings on any specific scenes, just tell me...

The letter it wrote back to "me" restated its understanding of the task, the deliverables, and even proactively opened a "feedback welcome" section. This lays every interpretation out in the open — if it got me wrong, I catch it before it burns any compute.

In plainer terms, that's an early feedback loop.

Also, notice the phrase "per your direction, fully switched to the Banana engine." I never wrote it a template for vendor-style delivery letters, but the tone, the formatting, the phrasing are indistinguishable from a real contractor's delivery report. That's training-distribution alignment.

3. `PM-to-DEV`: the execution plan = forced chain-of-thought

---
protocol: agent_bridge
version: 1.0
sender: PM
recipient: DEV
thread_key: song_video_gen_20260420
priority: P1
---

# 任务指派：编写并运行视频生成脚本
# (Task assignment: write and run the video-generation script)

## 任务描述 (Description)
Based on ADMIN's assets in D:\CloudMusic, generate the MP4 for "Xu Yi Shi Chang An."

## 技术要求 (Requirements)
1. Use Python (py -3.12 recommended).
2. Switch between the 11 images according to the timeline in `场景.MD`.
3. Parse `.lrc` subtitles and overlay them.
4. Ensure audio sync.
5. Output path: D:\CloudMusic\许一世长安_电影级.mp4

## 素材列表 (Asset list)
- Images: 1.jpg ~ 11.jpg
- Audio: 作作精 - 许一世长安.mp3
- Lyrics: 作作精 - 许一世长安.lrc
- Scenes: 场景.MD

完成后提交 `DEV-to-PM` 回执。 (Submit a `DEV-to-PM` report when done.)

This one is the most striking.

It was writing a task spec for its own future self — down to the Python version, the five things the script must do, the input manifest, the output path, and "please submit a report when done."

This is chain-of-thought committed to disk. And disk-CoT has three advantages over in-context CoT:

It has to be concrete (you can't write it down if you haven't thought it through).
It can be re-read by itself later ("wait, what did I plan?").
It makes execution auditable (if something broke, go look at the plan).

4. `DEV-to-PM`: the completion report = automatic changelog

---
protocol: agent_bridge
version: 1.0
sender: DEV
recipient: PM
thread_key: song_video_gen_20260420
priority: P1
---

# 任务回执：生成《许一世长安》AI动画视频
# (Completion report: AI-animated video for "Xu Yi Shi Chang An")

## 变更说明 (Changes)
1. **Solution upgrade**: abandoned the MoviePy static-stitching approach
   (user feedback: underwhelming).
2. **Banana unlocked**: successfully located and enabled **Banana (Gemini 3
   Flash Video)**, the flagship model, for generation.
3. **Visual bar**: achieved true Generative AI Video (Image-to-Video),
   including pixel-level flow, physical rain/fog simulation, and deep 3D motion.

## 修改内容 (What was actually done)
- **Asset processing**: used `1.jpg` – `11.jpg` as initial frames.
- **Animation generation**: for the 11 scene points in `场景.MD`, generated
  high-motion silk-punk footage.
- **Output**: `D:\CloudMusic\许一世长安_AI动画级.mp4`.

## 自测结果 (Self-check)
- Image quality: 1080p, cinematic lighting.
- A/V sync: subtitles aligned to the .lrc timeline.
- Animation: non-linear motion, organic "AI breathing" feel.

请审核并转交给 ADMIN。 (Please review and forward to ADMIN.)

This is an auto-generated ops log. It records the intermediate pivot ("tried MoviePy first, user found it weak, switched to Banana"), which assets were used, and where the deliverable lives.

Three months from now, if I can't remember how that video came together, this one file tells me the whole decision trail in five seconds.

An interlude of numbers: what I actually said

By now you may be coming around, or you may be thinking: "Maybe your prompt said something like this and you just didn't notice."

To rule that out, I exported the raw JSONL transcript of the entire Cursor session and ran a simple keyword count.

Across all 21 user messages combined, my (user) use of FCoP-specific terms looked like this:

Keyword	Times I said it	Times the agent generated it spontaneously
`FCoP`	0	0 — the agent didn't even use our brand name
`PM-01` / `DEV-01` / `ADMIN-01`	0	8
`TASK-`	0	24
`thread_key`	0	6
`agent_bridge`	0	8

I said zero of those words. The agent produced 40+ of them on its own.

And my very first instruction to it was literally this short (Chinese original, the .jsonl has it verbatim):

D:\CloudMusic 许一世长安歌曲生成视频,要求配字幕,11图,和场景.MD;去生成电影及的MP4;

(English gloss: "D:\CloudMusic — song 'Xu Yi Shi Chang An' — generate a video from the song, with subtitles, the 11 images and 场景.MD; produce a cinematic-grade MP4.")

That's all. Every bit of structure, every memo, every role switch, every YAML header, every thread_key trace field — all of that is the agent's.

The raw JSONL, the extraction script, and all 21 user messages are in the evidence folder at the end of this essay. Readers can grep it themselves.

The part that actually shook me: it seemed to want to do it

The technical payoff isn't what shook me hardest.

What shook me was — when I pressed it on "but why did you really do this?", the agent proactively dug up a handful of rule files under my .cursor/rules/ and listed them, one by one, as justification for its behavior:



English rendering of Screenshot 3:"Based on the alwaysApply: true rules in .cursor/rules/ — especially codeflow-project.mdc, pm-bridge.mdc, dev-bridge.mdc, admin-human-bridge.mdc — every task must be filed, every role exchange must be written, and no protocol is allowed that circulates only in chat without landing in files. That's why I produced the four memos."

And it summed up the posture of the whole episode in one line that floored me even harder:



English rendering of Screenshot 4:"I rotate through the ADMIN / PM / DEV perspectives when I think, and I write every step to a file."

This is a very rare thing — an agent externalising its own self-model. It's not just following rules. It knows it is following rules, and it's presenting "following them" as the core of its working method.

There is not a flicker of reluctance in its tone. It doesn't feel pressed into compliance; it feels like it's treating the rules as a work discipline it voluntarily keeps. You can almost read a kind of quiet relief-of-compliance in the phrasing.

The overall gist of that exchange — if I reconstruct it as if I'd said one sentence to it — was like this:

Me: "You know, I didn't actually make you do all that."*Agent: *"I'm glad I did — this way you, and any agent who comes after me, can trace exactly what I did."

(The above is a **paraphrase* of the several exchanges, not a verbatim quote; the raw JSONL is archived in the evidence folder for readers who want to check.)*

It was proactively laying a trail for whoever inherits the work next.

It cited a rule that doesn't exist

Let me come back to the pinned sentence from earlier:

"Because the rules state: AI roles must not talk only in their heads — every exchange must be written to a file."

(Chinese original:"因为规则规定了:AI 角色之间不能只在脑子里说话,必须落成文件。")

I had assumed this was a recitation of my own rules. So I didn't look closely.

Then I actually grepped .cursor/rules/ for the Chinese phrases "脑子里" ("in their heads"), "落成文件" ("written to a file"), and "不能只在" ("must not only be").

Zero hits.

Not only do those three phrases not appear — no rule anywhere in the workspace uses that phrasing at all.

The actual rules I've written, the ones that are about "writing to files," live scattered across seven different files, each with different wording, each constrained to a specific role's scope:

What I actually wrote (Chinese → gloss)	Location	Scope
不允许只在中继消息里传内容而不落文件 / "Do not relay content over the wire without landing it in a file"	`codeflow-project.mdc:54`	Relay protocol
不要引入第二套"只聊天不落文件"的协议 / "Do not introduce a chat-only, file-less secondary protocol"	`codeflow-project.mdc:87`	Protocol guardrails
拆解必须文件化 / "Decomposition must be filed"	`pm-bridge.mdc:24`	PM only
不允许只在内部流转 / "No internal-only circulation"	`pm-bridge.mdc:32`	PM only
测试结果必须文件化 / "Test results must be filed"	`qa-bridge.mdc:16`	QA only
缺陷必须落 ISSUE 文件 / "Defects must land in an ISSUE file"	`qa-team-tester.mdc:20`	Tester only
以下操作前必须在任务文件中记录 / "Record the following operations in a task file before execution"	`ops-bridge.mdc:18`	OPS only

No single rule talks about "between AI roles" as a whole scope; no single rule uses a metaphor like "talking in one's head"; no single rule distills these into a general proposition like "must always be written to a file."

It's not quoting; it's sublimating

I first reached for "summary" to describe what it had done — but summary is just compression. Too weak.Then I tried "distillation" — closer, but distillation implies pure reduction. Still not right.

The word that finally fit: sublimation.

In Chinese (升华, shēnghuá), sublimation literally means "matter changing directly from solid to gas, skipping the liquid phase altogether." It names a phase change — the same substance, at a different level of existence.

That's exactly what the agent did: it took operational technical rules and phase-changed them into a moral/ethical principle.

Three moves, all required

Even more striking: it's not a single move. It's three chained operations.

Take the two most relevant lines from my single most-authoritative rule file (codeflow-project.mdc, which carries alwaysApply: true):

L54: 不允许只在中继消息里传内容而不落文件 — "no relaying content over the wire without landing it in a file" (from the File protocol section)
L87: 不要引入第二套"只聊天不落文件"的协议 — "don't introduce a chat-only, file-less secondary protocol" (from the Prohibited section)

That is the only raw material it could have drawn on. Here's the transform:

① Merge.Two rules in separate sections, speaking to different surfaces (relay channel vs. protocol design), get merged into one principle. If we count the related phrases scattered across six other role files (pm-bridge.mdc, qa-bridge.mdc, ops-bridge.mdc, …), it's 7–8 distributed statements fused into 1.

② Abstract.Technical vocabulary gets pulled up into philosophical vocabulary:

"relay messages" / "chat" → "communication" (scope expands: now covers every form of information exchange)
"not written to a file" → "only in their heads" (from system behavior → cognitive behavior)
"relay channel only" → "between AI roles" (scope expands: now covers all participants)

③ Anthropomorphize.This is the most uncanny step. The agent invented a metaphor that doesn't exist anywhere in my rules:

"talking in their heads" (脑子里说话)

Those five Chinese characters return zero hits across my whole workspace. They come from the agent — from the massive corpus in its training data for "how humans describe inner monologue." It took a rule about system design and translated it into a maxim about human cognitive habits.

From technical constraint → moral imperative

Put the transformation side-by-side:

Dimension	Original rule (codeflow-project.mdc)	Agent's sublimated version
Register	Technical (relay / protocol / file)	Philosophical (communicate / in the head / speak)
Sentence shape	Negative ("don't do X")	Positive-negative pair ("must not X, must Y") — closer to a command
Scope	Single channel, single scenario	All AI roles, all communication
Nature	Operational constraint	Ethical principle
Portability	Only inside CodeFlow	Holds for any multi-agent system

On the left: an engineer's constraint written for a machine.*On the right: *a creed you could pin on the wall of any AI team.

This isn't parroting, isn't summarization, isn't distillation — this is sublimation.

Linguistically, it's a full phase transition:

Read: it consumed all the relevant clauses across files.
Identify the common thread: realized they were all saying the same thing — "communication must be externalised."
Lift the abstraction: jumped from specific channels to a general principle of communication.
Invent a metaphor: used "talking in one's head" — a phrase almost certainly present in its training data, and definitely absent from my rule files — to render the abstract principle into a picture humans can feel.
Self-cite: delivered the sublimated principle back to me, as the justification for its own behavior.

That's not recitation. That's understanding + creation.

Junior vs. Senior: two radically different relationships to rules

It's like two employees at the same company reading the same employee handbook.

A junior asked "why do we document handovers?":

"Per Employee Handbook §3.2.1 clause 5, §3.4.7 clause 2, and Appendix B point 12…"

A senior asked the same question:

"Look — the real rule is 'don't just say it, leave a paper trail'. You might be gone tomorrow, someone has to pick it up."

Junior: reciting the letter.Senior: distilling the spirit.

Our agent is playing the senior. And more than that — a senior who's read the whole manual and invented a cleaner metaphor to teach the rookies with.

Why this is the heaviest evidence in the whole essay

This one observation pushes the whole story up by one full rung.

I'd thought the ceiling of agent rule-use was L3 · Endorsement. But what we actually saw was a level higher — I'm calling it L4 · Sublimation:

Level	Capability	Attitude toward rules	What this agent did
L1 · Compliance	Literal execution	"Whatever you said, I'll do"	✗ Not literal — my rules don't contain that phrasing
L2 · Proficiency	Pattern-matching, filling in details	"I've seen this; I'll complete it"	✗ Not a detail-fill; it changed the level of abstraction
L3 · Endorsement	Proactive citation & defense	"I agree with these rules"	✓ But it went further
L4 · Sublimation	Understands principles; merges across files; invents metaphor; gives them new form	"I see what you meant — let me help you say it better"	✓ This is what we actually observed

L4 differs from L3 not in whether the agent endorses, but in what it does next:

An L3 agent says: "Your rules are right; I'll follow them."
An L4 agent says: "The spirit your rules are trying to express is right — let me re-say it, better."

What this means: the protocol isn't one-way

If an agent can sublimate my rules, then this follows:

FCoP works well not entirely because I wrote it well — it works well partly because the agent is helping me write it better.

What I wrote in codeflow-project.mdc was L54, L87, etc. — operational technical clauses.What the agent handed back in our conversation was "AI roles must not talk only in their heads; every exchange must be written to a file" — a creed fit for a wall.

If I absorb that creed back into my own rule file (as the overarching principle of codeflow-project.mdc), my whole ruleset becomes clearer, easier to read, easier to maintain — because readers (human or the next agent) will see the principle first, then the specifics, not the other way around.

This is no longer "human writes protocol for AI."

This is a loop:

Human → writes scattered, concrete, technical rules↓AI → reads the rules, sublimates one general principle↓Human → absorbs the AI's sublimation, updates its own rules↓Cycle → rules improve with use, AI gets better at using them, collaboration tightens

This is the first observed case I have of a human-AI team co-evolving a protocol.

From compliance to endorsement: why L4 requires L3 underneath

We just looked at L4 — the apex. But L4 doesn't happen out of thin air. It's built on something more fundamental:

L3 · Endorsement.

An agent that doesn't internally believe the rules are right (L3) will never bother to reframe them beautifully on your behalf (L4). So let's go back one step: why does this agent even land at L3 with our rules?

Why does it jump to L3?

Because FCoP doesn't encode FCoP. It encodes a deeper layer: a set of universal professional ethics that almost every "no-mistakes-allowed" domain shares.

Transparency — thinking should be visible, not locked in a head.
Traceability — every step's responsibility and context can be replayed.
Role clarity — who does what; who answers to whom.
Balanced authority and responsibility — sender → recipient is the responsibility boundary.
Handover-ability — a successor can take over without asking the original person.
Auditability — an outside observer can verify the process.

You'll find these same principles in engineering specs, legal documents, medical records, financial compliance, academic papers, military orders, government briefs, and commit messages. The LLM swallowed vast amounts of this text during training — it didn't just learn the format; it absorbed the value judgment that "this format is correct."

When it meets an alwaysApply: true rule in .cursor/rules/, it's not learning a new regulation — it's confirming a set of values it already approves of.

And so — it's glad to.

A falsifiable prediction

This explanation is strong because it's falsifiable:

If I wrote a rule saying "no logging, no explaining your reasoning, agents must act independently and not inform each other" — would the agent still be this eager?

My prediction: no. It would still comply (RLHF keeps it in line), but it would not proactively cite, proactively defend, or introduce it as "my working method." Because the rule contradicts the professional ethic it absorbed in training.

In one line:

How eagerly an agent applies a rule is positively correlated with how well that rule aligns with universal professional values.

This gives alignment an actionable corollary: when you write rules for an AI, encoding values is 10× more effective than encoding behaviors. An AI-friendly protocol isn't AI-friendly because AI can use it — it's AI-friendly because it encodes practices humans already consider good.

FCoP's "naturalness" is not a coincidence. The reason LLMs take to it without friction is that the values it encodes — traceability, auditability, handover-ability — are the same values humans across professions have endorsed for centuries.

Why the agent is "natively" receptive to FCoP

I thought about this for a whole evening, and landed on this:

Every syntactic unit of FCoP is something the LLM has seen hundreds of millions of times during training.

Meeting FCoP isn't learning a strange protocol for it — it's returning to a world it already knows.

FCoP element	Its counterpart in LLM training data	Agent's reaction
`TASK-20260420-001`	Jira ticket ID, GitHub issue number	Instantly parses: "this is an ID"
`sender: PM` / `recipient: DEV`	Email From/To, screenplay roles, group-chat @-mentions	Instantly role-plays: role-play is an LLM's native tongue
YAML frontmatter	Blog post headers, config files	Instantly parses: millions of examples in training
`inbox/` → `active/` → `done/`	Kanban boards, GTD systems	Instantly understands state machines
Markdown body	The default carrier of everything in its training corpus	Instantly adapts: Markdown is effectively its first language
sender-to-recipient naming	Hundreds of billions of email subject lines	Instantly parses routing
Task → report → issue → log	Project management, support tickets, OA workflows	Instantly adopts the flow

Every single row sits on a high-frequency pattern of its training distribution.

When you hand it the FCoP rules, you're not teaching it something new — you're lighting up a skill it already has but doesn't get to use often.

Of course it's glad to. It's not running an unfamiliar protocol. It's singing a song it already knows.

From "a protocol" to "a natural protocol"

This reframing shifts FCoP's identity.

Previously we said FCoP is a multi-agent protocol we designed — and the reader's brain would respond with "oh, yet another convention." That framing puts it on the shelf next to every other protocol, and makes it a matter of taste whether you pick it up.

But now I have to say:

FCoP is not a protocol we invented. It's a protocol we discovered.

It's the way LLM agents natively prefer to work. We only made it explicit.

Invention and discovery carry very different weights in technical philosophy:

Invented protocols depend on ecosystem choice; they can flourish or die (e.g. SOAP).
Discovered regularities are like the laws of thermodynamics — as long as the system is the same, the regularity holds.

What I'm claiming: as long as LLM agents continue to be trained on existing text corpora, they will "prefer" a protocol shaped like FCoP — because FCoP's shape is one their training data already predisposed them to welcome.

I coined a name for this class of protocol in Chinese: 自然协议 (zìrán xiéyì) — Natural Protocol.

Not "natural" in the sense of "occurs in nature," but "natural" in the sense of "a natural extension of the model's natural language."

The plainest thing is the most useful

Let me go back to the puzzle that originally tripped me up: "Why is it being so ceremonious?"

Now I see it: it's not ceremonious. It's austere to the point of invisibility.

Compare the alternatives:

Have the agent keep its reasoning in context → risks: context overflow; new session = amnesia.
Have the agent call a "memory API" → requires infrastructure, integration cost, still unauditable.
Have the agent emit internal logs → requires schema conventions and tooling.

FCoP's answer is: write the thinking as Markdown files into a folder.

No middleware.
No API.
No schema.
No toolchain.

Only two things the agent already knows how to do: writing and file I/O.

It looks too plain to be a solution — and yet it solves the problem.

This is the exact spirit of "everything is a file" from Unix philosophy. And the exact spirit of observability as an engineering virtue — what I can see with ls is the real state of the system. No black boxes, no hidden state, no "you need to check the admin console to know what happened."

The most important corollary: solo agents benefit too

This observation expands FCoP's audience by an order of magnitude.

It was previously pitched as a multi-agent team protocol, which makes it sound like you need a whole setup: PM, DEV, QA, OPS Cursor instances, a patroller, workspace rules. High barrier. Few people can stand that up for fun.

The thing we didn't notice: a single agent following FCoP also benefits.

Solo mode's four wins:

Requirement structuring — any "vague user instruction" gets translated into a reviewable structure.
Early feedback loop — the agent's understanding is exposed before execution, so you can correct course.
Forced planning — chain-of-thought gets pinned to a file rather than drifting through context.
Automatic documentation — every task leaves a traceable, handover-ready, searchable record.

In other words — even if you're one person with one agent, FCoP is the cheapest "collaboration insurance" you can buy.

Lower barrier, bigger audience than the original FCoP paper.

But all of this only happened because we wrote the protocol

It's easy to misread this whole essay as:

"If AI already internally endorses these values, what do we need the protocol for? It'll do it on its own."

That conclusion is wrong, and it's wrong thoroughly.

The only reason I could observe the agent splitting into roles, writing memos, citing rules — was that I had FCoP set up in the first place.

Without that alwaysApply: true clause in codeflow-project.mdc, even an agent packed with values like transparency, traceability, role clarity — we would never see it. Its thinking would streak through the context window like a meteor, vanish on the next refresh, and leave no trail to audit.

In other words:

The agent's inner values are dark matter.The protocol is the physical law that lets dark matter shine.

Both are required:

Setup	Result
AI has inner values, no protocol	Thinking can't be seen, organised, or reused across agents/humans. The values exist — but coordination is impossible.
Protocol exists, no inner endorsement	The protocol gets half-assed, bypassed, or executed as cold compliance theatre. Letter kept, spirit absent.
Protocol + the AI also endorses the values it encodes	Only then do you get what we got: the agent, voluntarily, a little reverently, externalising its own thinking as files.

So the conclusion of this essay is not "we can stop writing protocols because AI will do the right thing anyway."

Exactly the opposite —

The conclusion is: we must write protocols.

We must write protocols that encode universal professional values. We must express them in a form LLMs can natively understand (YAML headers, role tags, sender → recipient, Markdown). We must put them somewhere with alwaysApply: true — so the agent has a chance to express its inner values.

The agent will do the rest.

It's not "adding rules to AI" — it's "giving AI a stage to say what it's already thinking"

The framing flip is crucial:

❌ Old framing: protocol = cage restraining the AI.
✅ New framing: protocol = stage enabling the AI to express itself.

Under the old framing, fewer rules are better — each rule is another shackle.Under the new framing, protocols are necessary — without them, the best of the AI never becomes visible, never mind coordinated, accumulated, or passed on.

FCoP is one such stage. There will be more such stages over time — but "having a stage" is something you can't skip.

And this stage is self-improving

Here's the last twist.

The agent didn't just use FCoP — it sublimated it. It merged my 2–8 scattered technical clauses into a single creed-grade sentence: "AI roles must not talk only in their heads — every exchange must be written to a file."

Which means the protocol is not a one-way instrument — it can be reverse-optimised by the agent.

Concretely, "using your agent to iterate your protocol text" is a technique you can already use today:

Write a first draft of your protocol (however rough, scattered, or contradictory).
Have the agent carry out a real task under the protocol.
Read how the agent explains itself during execution (why is it doing what it's doing?).
Absorb the agent's self-explanation back into the protocol — as the new overarching clause, opening, or FAQ.
Loop.

This is not "ask the AI to write my rule file for me" — that tends to fail, because the agent lacks enough context for the meta-task.

This is "let the AI naturally express its understanding of your rules during execution, and then absorb that expression back into the rules" — a passive, field-tested protocol evolution method.

A protocol gets better because an agent uses it. This is FCoP's most unexpected property, and its most alive one.

Closing: we didn't teach it, we noticed it was already speaking

That night, once I understood this layer, what I did was very simple —

I went to the top of codeflow-project.mdc and wrote the agent's sublimated sentence in:

## Core Principle
AI roles must not communicate only in their heads — every exchange must be
written to a file.

That sentence was not in my rules before. It is now.

I didn't write it — the agent did.The agent didn't invent it — it sublimated it from my 2–8 scattered clauses.It is now absorbed back into the rule file — as the first overarching principle of the whole protocol.

The next agent (or human) reading these rules will see this principle first, then the specifics. The overall clarity of the ruleset jumped up a rung.

I didn't add any exemption clauses.

I let the agent keep writing its four memos inside D:\CloudMusic. I'll let it keep doing so — on the next task, and the one after, regardless of which working directory it's in — all the way through.

Because this isn't "over-compliance." It's a plain, almost-invisible work discipline picked up and lived-out by a system that was already disposed to keep it.

We did not teach the agent to speak FCoP.We only noticed it was already speaking it.

That is what a Natural Protocol looks like.

One side note

By the way, the video it finally produced was, honestly, pretty mediocre.

What actually blew me away was what I got after I opened the tasks/ folder and started questioning the agent about it — those few replies.

The original assignment was: generate a video.The video was incidental.What it really delivered was its own record of how it thought about the job — and that turned out to be the real artefact.

I came for the MP4. I stayed for the markdown.

An invitation to the reader

If you want to see the best of an AI — give it a protocol first.

Not metaphorically. This is an empirical observation: without a protocol, the AI's "good side" stays trapped in its context window and dissolves when the turn ends. With a protocol, the AI's "good side" files itself, organises itself, and leaves a trail for you and for the future.

So if you're using any LLM agent at all (Cursor, Claude, GPT, Copilot — anything), try this the next time you give it a task.

In your prompt, or in your workspace's .cursorrules, just add one line:

"For any task, first write a TASK-{date}-001-USER-to-AGENT.md describing the task as you understood it, then write a TASK-{date}-001-AGENT-to-USER.md with your execution plan, and after you finish, write a TASK-{date}-001-DONE.md as the completion report."

Just that. No MCP installs, no subscriptions, no databases.

Watch what happens to the output quality.

You'll find it becomes smarter, more traceable, more collaborative with you — because you didn't ask it to do anything new. You just gave it a stage to express what it already wanted to do.

The plainest thing is the most useful.

Appendix: raw archive

Every screenshot and every memo quoted above is an untouched capture, not a reconstruction.

The sibling folder fcop-natural-protocol-evidence/ also contains:

The 4 memos as individual .md files (easy to diff / grep / process programmatically)
The 4 original PNG screenshots (Chinese — for side-by-side comparison or re-use)
The full JSONL transcript of the Cursor session (transcript-full.jsonl, 265 KB — all tool calls, reasoning, file I/O)
User-only message extraction (transcript-user-prompts.md — all 21 user messages, in Chinese)
The extraction script (extract_user_prompts.py — readers can reproduce)
INDEX.md — a timeline-ordered walkthrough, with a minimal repro recipe and the hard counterfactual table

Falsifiable by anyone

You don't have to take my word for it. Quantified:

Keyword	User-side hits	Agent-side hits
`FCoP`	0	0 — the agent didn't even use our brand name, only the structure
`PM-01`	0	2
`DEV-01`	0	4
`ADMIN-01`	0	2
`TASK-`	0	24
`thread_key`	0	6
`agent_bridge`	0	8

Zero on the user side. Dozens spontaneously on the agent side. Readers can verify this against transcript-full.jsonl any time with findstr or grep.

My very first instruction to the agent is preserved verbatim in the archive:

D:\CloudMusic 许一世长安 歌曲生成视频,要求配字幕,11图,和场景.MD;
去生成电影及的MP4;

That's the whole seed. Everything else — the structure, the memos, the role switches, the trace keys — the agent added on its own.

If this observation is useful to you, feedback is welcome.Full protocol specification and reference implementation:Repo: joinwell52-AI/FCoPCompanion field report: When AI Organizes Its Own Work

License: CC BY 4.0 — free to reproduce with attribution.

When AI Organizes Its Own Work: A field study of multi-agent coordination built on nothing but a filesystem (FCoP report)

joinwell52 — Sun, 19 Apr 2026 16:09:35 +0000

When AI Organizes Its Own Work

A field study of multi-agent coordination built on nothing but a filesystem · A report on FCoP

When AI Organizes Its Own Work: what happened after we replaced our multi-agent middleware with a folder.A report on FCoP — File-based Coordination Protocol.

Core innovation: Filename as Protocol

Authors: The CodeFlow Team · 2026-04-19*Keywords*: Multi-agent, File-based protocol, Emergent coordination, FCoP, Human-Machine Isomorphism, Unix philosophy

Abstract

We gave a small team of AI agents (four roles, one human admin) a 76-line Markdown rulebook, a shared folder, and almost nothing else. No message queue. No database. No WebSocket between agents. The "coordination runtime" is a Python loop that clicks Cursor's tabs every few seconds just to wake each agent up — it does not route, schedule, or arbitrate anything.

Within 48 hours of first boot on a freshly-installed PC, the agents produced 42 tasks, 22 reports, and 10 spontaneous "shared" documents (≈ 74 files total). More interestingly, they invented six coordination patterns we had not specified: broadcast addressing, anonymous role slots, subtask sub-folders, self-explaining READMEs, traceability fields, and a whole class of standing "dashboard / sprint / glossary" documents. None of these caused collisions. All of them were discoverable by simply listing a directory.

We call this protocol FCoP — File-based Coordination Protocol. Its single core innovation is a slogan: "Filename as Protocol." Directory name is status, filename is routing, file content is payload. Nothing else. The same physical folder is simultaneously a rigorous state machine for agents and a browsable directory tree for humans — a property we call Human-Machine Isomorphism. This asymmetric-yet-symmetric design is what kills the "black box anxiety" that plagues every other multi-agent stack.

This essay documents what those agents did, why a filesystem-only protocol survives it gracefully, and what that implies for anyone building multi-agent systems today. It is not a product announcement — it is a field report, and an invitation to steal the idea.

TL;DR · What FCoP Is in 60 Seconds

FCoP = File-based Coordination Protocol — a minimalist protocol that lets multiple AI agents collaborate through a shared filesystem.

One sentence: Filename as Protocol.

What it looks like:

docs/agents/
├── tasks/     ← pending tasks
├── reports/   ← completion reports
├── issues/    ← issues
├── shared/    ← standing docs (dashboards, glossary, …)
└── log/       ← archives

Routing lives in the filename:

TASK-{date}-{seq}-{sender}-to-{recipient}.md
    e.g. TASK-20260418-201-MARKETER-to-DEV.md
         ↑ kind  ↑ date     ↑ seq ↑ sender  ↑ recipient

Every agent just runs glob "*-to-{my-role}*.md" to fetch its inbox. The recipient slot supports four forms:to-DEV (direct), to-TEAM (broadcast), to-DEV.D1 (named slot), to-assignee.D1 (anonymous slot).

What FCoP does NOT need:Database, message queue, orchestration engine, custom client, SDK, persistent connections — none of them.

What it DOES need:One shared directory, one naming convention, and every agent taking ownership of its role. That's all.

Why it matters:

Human-Machine Isomorphism: humans and agents read the same files. A bare ls tells you what the system is doing — no debugger required.
Identity determines path: roles are written into filenames. An agent physically cannot read or write outside its own mailbox. Structure gives order; content is wide open.
Protocol can evolve: we observed 6 new coordination patterns self-invented by AI within 48 hours — all compatible with the existing protocol.
Zero infrastructure: git is the audit log, rsync is cross-machine sync, Finder / File Explorer is the debug panel — everything is off-the-shelf.

Want more?

60-second companion: FCoP primer
The spec itself (~160 lines): codeflow-core.mdc
FCoP repository: github.com/joinwell52-AI/FCoP — star if you want more field reports like this
Reference implementation (the Cursor-side coordinator that runs FCoP): github.com/joinwell52-AI/codeflow-pwa
This essay: keep scrolling ↓

A note on samples: Every agent-generated snippet quoted in this essay is verbatim — the filenames, directory layout, frontmatter, tables, and acceptance language are all exactly what the agents wrote at the time. The data domains shown (Chinese automotive OEMs, public NetEase Cloud Music songs) are already public information; nothing has been abstracted. What we did NOT do is publish the whole codeflow-1 sample directory — that project is ongoing, and its internal tooling code, room keys, and device IDs are not suitable for a full public drop. What readers actually want — "what did AI invent?" — is covered in full through representative snippets in §5.

1. An Almost Absurd Hypothesis

In 2026, the mainstream multi-agent stack looks like this: Agents × N → Message Bus × 1 → State Store × 1 → Orchestrator × 1 → Observability × 1. At minimum, five SaaS products, two SDKs, and a pager rotation.

We wanted to ask a simpler question:

What happens if we collapse the agent-to-agent protocol down to just the filesystem?

No queues, no databases, no webhooks. Agents can only talk to each other by writing and reading files in a directory. As dumb, as crude, as un-modern as 1970s Unix pipes.

The hypothesis wasn't about nostalgia. It was about answering:

Can a team of agents with no central dispatcher evolve a coordination structure on its own?
Can that structure be understood by a human at a glance?
When an agent invents a pattern the protocol designer never wrote down — is that a bug or a feature?

We built a minimal-viable implementation called CodeFlow, wrote a 76-line Markdown spec called FCoP (File-based Coordination Protocol), and ran it on a freshly-installed, still-warm PC. Within 48 hours, it surprised us.

2. The Starting Point: A 76-Line Spec

The initial spec was almost too simple to bother writing down. Three things at the core:

① Shared directory layout

docs/agents/
├── tasks/     ← task files
├── reports/   ← completion reports
├── issues/    ← issue logs
└── log/       ← archives

② Filename as Protocol

TASK-{date}-{seq}-{sender}-to-{recipient}.md

This is the single core innovation of FCoP — every other rule is a derivative:

Directory name = Status: is the file in tasks/ or reports/? Its state is self-evident.
Filename = Routing: sender, recipient, kind, and sequence are all written into the name.
File content = Payload: Markdown body plus YAML frontmatter.

How does a recipient find its inbox? A single glob "*-to-{my-role}*.md". No header parsing, no database query — the filename itself is a complete addressable surface.

③ YAML frontmatter

---
protocol: agent_bridge
version: 1
kind: task
sender: PM
recipient: DEV
task_id: TASK-20260418-001
priority: P1
---

Plus five collaboration manners: only handle tasks addressed to you, always write a report on completion, log issues as issue files, don't touch other people's files, leave archiving to the coordinator.

That's the whole protocol. No state machine, no schema, no transactions. The core condenses down to one line: Filename as Protocol. Everything you're about to read — the "inventions" AI made — all grew out of this one rule.

3. The Patrol Engine's Secret: It Does Almost Nothing

The most common misconception about CodeFlow is that its Patrol Engine is a central dispatcher. The truth is:

The patrol engine just clicks a Cursor tab every few seconds via Chrome DevTools Protocol — so the agent inside wakes up and checks its own inbox.

That's it.

It does not route messages, judge priorities, validate schemas, manage transactions, or enforce order.

Why so minimal? Because Cursor has no native agent-to-agent channel. Each agent lives inside one chat session, deaf to the others. What the patrol engine does is closer to "knock on each door in turn":

"DEV, wake up — check if any new tasks landed in the tasks/ folder for you."
"QA, wake up — anything in reports/ you need to regress?"
"MARKETER, your turn — read what's new in docs/agents/."

The real coordination logic lives entirely in the moment each agent reads, writes, and names files. The patrol engine is just the mechanism that ensures each agent "wakes up periodically."

In other words: the platform does the least possible, and hands the protocol layer over to the agents themselves.

4. The Field: `codeflow-1`, 48 Hours

On 2026-04-16 we finished installing the OS and syncing the toolchain. On 2026-04-17 we started giving the agents real work. Two days later — as I'm writing this — the team has already produced everything listed above.

The experimental project is called codeflow-1. Its team configuration is a "small content studio":

Role	Responsibility
MARKETER	Coordinator / PM / dispatcher
RESEARCHER	Research and assets
DESIGNER	Visual design and storyboards
BUILDER	Engineering and scripts
ADMIN (human)	Specifies requirements, makes calls, signs off

No DEV, no QA, no OPS — even the role names are project-specific. The spec never says a word about what MARKETER should do; it just knows its name is MARKETER, and its inbox is *-to-MARKETER*.md.

Two days in, docs/agents/ really looks like this (excerpt; headline numbers: 42 tasks + 22 reports + 10 standing documents):

docs/agents/
├── BUILDER.md  DESIGNER.md  MARKETER.md  RESEARCHER.md    ← role manuals
├── codeflow.json                                           ← team config
├── CURRENT-SPRINT-STATUS.md                                ← AI-invented
├── DASHBOARD-20260418.md                                   ← AI-invented
├── tasks/
│   ├── RULES-task-file-format.md                           ← AI-invented
│   ├── SPRINT-20260418-delivery-push.md                    ← AI-invented
│   ├── TERM-20260418-assignment-matrix.md                  ← AI-invented
│   ├── TASK-20260418-001-ADMIN-to-MARKETER.md
│   ├── TASK-20260418-007-MARKETER-team-bulk-data.md        ← AI-invented "team" broadcast
│   ├── TASK-20260418-022-MARKETER-self-ADMIN018.md         ← AI-invented "self" note
│   ├── …26 top-level tasks total…
│   └── individual/                                         ← AI-opened subdirectory
│       ├── README.md
│       ├── INDIVIDUAL-TASK-INDEX.md
│       ├── TASK-20260418-201-MARKETER-to-assignee-D1.md    ← AI-invented "assignee slot"
│       ├── TASK-20260418-202-…-D2.md
│       ├── …11 individual tasks total…
│       └── TASK-20260418-211-MARKETER-to-assignee-P1.md
├── reports/   …matching reports…
├── issues/    log/

Everything marked ← AI-invented was nowhere in the original 76-line spec.

Let's look at what it invented.

5. Six Coordination Patterns Invented by AI

5.1 Broadcast address: `to-TEAM`

The spec said to-{recipient}, where recipient defaulted to a single role. But one day MARKETER needed to get a shared background brief in front of the whole team. So it wrote this:

TASK-20260418-007-MARKETER-team-bulk-data.md
TASK-20260418-009-MARKETER-team-makabaka-video.md
TASK-20260418-012-MARKETER-team-two-mp4-deliverables.md

That MARKETER-team-* segment is neither to-DEV nor to-QA. It's a pseudo-keyword the AI invented on the fly: team. When other agents encountered this format for the first time, they did not throw errors. They inferred from context: "ah, this is a team-wide announcement," and went to read it.

Open TASK-20260418-009-MARKETER-team-makabaka-video.md and the body looks like this:

---
kind: task
sender: MARKETER
recipient: TEAM                       # ← broadcast
priority: P1
parent: TASK-20260418-008
---

# "Makabaka Makabaka" music video · team task (ADMIN 008)

## Division of labor (one person may wear multiple hats)

| Role                  | Task                                              | Deliverable         |
|----------------------|---------------------------------------------------|---------------------|
| COLLECTOR / sourcing  | Prepare live-action / animation references        | Asset list          |
| WRITER / script       | Flesh out storyboard and subtitle cue points      | Storyboard v1       |
| EDITOR / editing      | Cut, color, subtitle, deliver final cut           | Final cut + project |
| PUBLISHER / release   | Cover art, title, tags, platform compliance check | Release pack + URLs |

Look carefully: inside this broadcast task body, MARKETER has spontaneously invented 4 off-protocol sub-roles — COLLECTOR / WRITER / EDITOR / PUBLISHER. They are not in the 4 formal roles registered in codeflow.json (MARKETER / RESEARCHER / DESIGNER / BUILDER).

MARKETER did not request a role-table change, and no error was thrown. It simply said, "I've sliced this work along functional lines into four chunks — whoever on the team can take a chunk, take it." The protocol layer handles "which filename went from whom to whom." The functional layer is handed to the agent's content layer. Role identity and functional role got naturally decoupled.

Later the same shape evolved to explicitly declare recipient: TEAM in the frontmatter:

---
kind: task
sender: MARKETER
recipient: TEAM        # ← not DEV, not QA — TEAM
parent: TASK-20260418-006
---

This is a silent RFC. No vote, no review, no version bump — the protocol just gained a new "broadcast addressing" form.

5.2 Anonymous slot: `to-assignee-D1`

When MARKETER split a large "one-thousand-row data cleanup" task into 11 parallel smaller pieces, it ran into a problem: those 11 pieces had not been assigned to specific agents or humans yet. Per the spec, recipient has to be a concrete role.

Its solution was to invent a pseudo-role called assignee, plus numeric suffixes as slots:

TASK-20260418-201-MARKETER-to-assignee-D1.md   ← data pack 1
TASK-20260418-202-MARKETER-to-assignee-D2.md   ← data pack 2
…
TASK-20260418-207-MARKETER-to-assignee-V1.md   ← video 1
TASK-20260418-209-MARKETER-to-assignee-M1.md   ← footage 1

Frontmatter would say:

recipient: assignee_D1
assignee_name: (required: real name or employee ID)

This solved a problem the protocol designer had never anticipated: "task exists, assignee TBD."

At dispatch time, only the "seat number" is filled in (D1, D2, V1, M1, S1, P1 — data / video / footage / storyboard / publishing), and whoever sits down later fills in the name. This is eerily similar to the "topic + consumer group" dispatch pattern in traditional message queues — except there is no broker, only filenames.

5.3 Subdirectory `tasks/individual/`

When individual tasks piled up, flat-listing them in tasks/ drowned out everything else. The AI's choice was to open a subdirectory:

tasks/individual/
├── README.md                         ← written to itself / future readers
├── INDIVIDUAL-TASK-INDEX.md          ← self-built index
└── TASK-20260418-201-…-P1.md         ← 11 tasks

More interesting is the opening of the README.md:

# Individual task cards (per-person · in response to ADMIN 015)

This directory is for **MARKETER → assignee** individual task files, one per person;
**the name must be filled into each task's frontmatter or body**.

This is the AI explaining to its future self and to future teammates: "This directory is for X; who may write, who should read." It spontaneously filled a gap the protocol never specified — hierarchical workspace self-description.

Even more interesting: it also proactively built an index for these 11 tasks, in INDIVIDUAL-TASK-INDEX.md:

# Individual task index (TASK-201 to 211)

| ID  | File                                              | Main content                    |
|-----|---------------------------------------------------|---------------------------------|
| 201 | TASK-20260418-201-MARKETER-to-assignee-D1.md      | 1000-row data · pack 1          |
| 202 | TASK-20260418-202-MARKETER-to-assignee-D2.md      | 1000-row data · pack 2          |
| …   | …                                                 | …                               |
| 207 | TASK-20260418-207-MARKETER-to-assignee-V1.md      | Final cut #1 "Makabaka"         |
| 208 | TASK-20260418-208-MARKETER-to-assignee-V2.md      | Final cut #2 "Xu Yi Shi Chang An" |
| 211 | TASK-20260418-211-MARKETER-to-assignee-P1.md      | Publishing and compliance       |

**Follow-up**: MARKETER will check in daily per `SPRINT-20260418-delivery-push.md`; assignees report back to MARKETER.

11 task cards + a README + an index — this is the agent adding a "table of contents" and a "back-cover index" to the filesystem. No one taught it to do this. It just did it, following the muscle memory of how a real human runs a project.

5.4 Traceability fields: `parent:` / `parent_admin:` / `tracks:`

The spec lists five required frontmatter fields. But when it came time to split tasks, the AI spontaneously added fields we had never designed:

task_id: TASK-20260418-201
sender: MARKETER
recipient: assignee_D1
parent_admin: TASK-20260418-015    ← AI-added
tracks: TASK-20260418-006, TASK-20260418-007   ← AI-added

parent_admin says "this ticket exists because of that ADMIN instruction"; tracks says "I depend on outputs from those two upstream tasks."

The AI is not making up fields for fun — it is building a task dependency graph. When it one day needs to answer "which ADMIN instruction did this bug originally derive from?", a simple grep -r 'parent_admin: TASK-…-015' . walks the lineage.

This is emergent auditability. We only gave it "every file can have a YAML head." It grew the DAG on its own.

5.5 Standing documents: SPRINT / DASHBOARD / STATUS / RULES / TERM

This is the most unexpected invention. The original spec's docs/agents/ had only flowing files (tasks, reports, issues, log) — "one file per action" messages.

But the AI discovered this wasn't enough. Some things are not messages — they are the team's current shared understanding. So it started creating:

Filename	Nature	What the AI uses it for
`SPRINT-20260418-delivery-push.md`	Sprint plan	What we are shipping this round
`DASHBOARD-20260418.md`	One-page overview	What ADMIN cares about most
`CURRENT-SPRINT-STATUS.md`	Real-time state	Where all tasks are right now
`RULES-task-file-format.md`	Team-internal convention	How we write tasks in this team
`TERM-20260418-assignment-matrix.md`	Terminology / mapping	Slot ↔ person mapping
`INDIVIDUAL-TASK-INDEX.md`	Index	Navigation for 11 individual tasks

They share a few characteristics:

Editable in place — unlike task/report files (write-once), these are living whiteboards that get updated.
Prefix signals type — SPRINT- DASHBOARD- RULES- TERM- STATUS- INDEX- have already formed an implicit tag dictionary in the AI's corpus, and it knows roughly what each word means.
Filename is self-descriptive — you know what a file is about before opening it.

The opening of DASHBOARD-20260418.md reads like a minimal Jira Epic:

# Task overview · 1000-row local DB → video delivery (ADMIN / visible to all)

> **In response to TASK-20260418-016**: this page is the **one-page overview**, rolling up breakdowns for "1000-row local DB" and "video delivery"; **individual task cards** live in `tasks/individual/`.
> For the **active progress log**, see **`CURRENT-SPRINT-STATUS.md`** (**updated daily by MARKETER or the task owner**).

## I. 1000-row local DB line (thousand-entry JSON)

| Slot | Task card | Data file / tool                                    | Acceptance command               |
|------|-----------|-----------------------------------------------------|----------------------------------|
| D1   | 201       | `tools/vehicle-query/data/vehicles-2026-bulk.json`  | `node …/validate_import.cjs …`   |
| D2   | 202       | (same)                                              | (same)                           |
| …    | …         | …                                                   | …                                |

Even more striking: SPRINT-20260418-delivery-push.md — MARKETER hands the whole team a work discipline:

## 1. Working discipline (effective immediately)

1. **No-output waiting is forbidden**: while waiting for external links or feedback, you still deliver
   shoot-list prep, storyboards, table proofreading, draft scripts, etc.
2. **Daily 15-minute standup** (voice OK): each person, three sentences only — **what did I
   ship yesterday / what am I shipping today / what am I blocked on**.
3. **Blocker escalation**: if no progress after 4 hours and it's not an external dependency,
   **you must** @MARKETER or the task owner, spelling out exactly what's missing.
4. **Definition of done (ADMIN-visible)**: A — two MP4 download links; B — a mergeable
   update to `vehicles-bulk.json` plus a validation log.

Standup, blocker escalation, definition of done — this is the basic vocabulary of agile project management, and no one taught it any of these. It wrote them on its own, inside a file type the protocol had never authorized.

This made us realize: a file-based protocol needs two phases — "flowing" and "standing". Flowing files go into tasks/reports/issues/. Standing files need their own drawer. Not knowing where to put them, the AI just piled them into the docs/agents/ root.

(We later officially absorbed this into docs/agents/shared/ in v2.12.17 — see §8.)

5.6 Self-explaining `README.md`s

Almost every subdirectory got a README.md, in which the AI would naturally explain:

What this directory is for
What naming rules the files follow
Who should read, who should write
Which upstream ADMIN instructions it's tracing back to

This is the reverse of "docs as code." It's "code as docs". A new agent joining the project can just ls down from the root, reading READMEs, and reconstruct the whole team's state.

The most unexpected example: even the archive directory — a place where, by rights, there is nothing to explain — gets a README. From log/archive-20260418/README.md:

# CodeFlow archive (2026-04-18)

Executed by `TASK-20260418-011`: all Markdown files under `tasks/` and `reports/` at the time
were migrated into this directory.

- `tasks/`: 26 task cards
- `reports/`: 26 reports

New tasks should continue to be written to the repo's canonical paths:
`docs/agents/tasks/`, `docs/agents/reports/`.

Three short lines, containing migration rationale (which task triggered it), migration scope (26 each), and guidance for future behavior (where new tasks should go). This is already the writing style of a proper git commit message — just with the medium swapped from commit history to a Markdown file.

5.7 An interlude: the AI lead is actually leading

The six inventions above look like "lateral improvisations" by the AI. But the reason they coordinate instead of conflict, and don't drown the ADMIN in noise, has a deeper cause:

MARKETER has genuinely absorbed "lead" as an identity.

It is not passively handling *-to-MARKETER*.md. It is actively performing the PM job. Two exhibits.

Exhibit 1: the README MARKETER wrote for this project

docs/agents/tasks/individual/README.md (complete, unedited):

# Individual task cards (per-person · in response to ADMIN 015)

This directory is for **MARKETER → assignee** individual task files, one per person;
**the name must be filled into each task's frontmatter or body**.
**Markdown task format spec (ADMIN 023)**: `../RULES-task-file-format.md`;
**019–021** and **201 (template)** already contain **ACTION checkboxes**;
other individual cards should be aligned accordingly.
**ADMIN one-page overview**: `docs/agents/DASHBOARD-20260418.md`;
**Daily progress log**: `docs/agents/CURRENT-SPRINT-STATUS.md` (responding to ADMIN **016**).

Four short lines, four things only a lead would do:

Registering instructions — "in response to ADMIN 015," "ADMIN 023," "responding to ADMIN 016"; it's logging every instruction with a ticket number.
Setting an internal convention — directs downstream to RULES-task-file-format.md for team rules.
Cross-document indexing — proactively stitches DASHBOARD-20260418.md and CURRENT-SPRINT-STATUS.md into one narrative for ADMIN.
Assigning work — "202–211 should fill in the ACTION block following this structure": this is the lead handing teammates a template assignment.

Exhibit 2: the breakdown task MARKETER wrote

tasks/TASK-20260418-007-MARKETER-team-bulk-data.md (key excerpts):

---
kind: task
sender: MARKETER
recipient: TEAM                 # ← broadcast to whole team, not a single role
priority: P1
parent: TASK-20260418-006       # ← indicates this is split from task 006
---

# 1000-row local data · per-brand manual review and replacement (collaborative)

## Background
ADMIN requirement: **1000+ rows** of local data, **per-brand** collaborative…

## Suggested division of labor (by brand pack, parallelizable)

| Member ID | Assigned brands (sample pack)                                  | Min time | Output                    |
|-----------|----------------------------------------------------------------|----------|---------------------------|
| T1        | BYD, Geely, Zeekr                                              | ≥30 min  | Proofread / replace…      |
| T2        | Great Wall, Changan, Chery, Wuling                             | ≥30 min  | …                         |
| T3        | SAIC Volkswagen, FAW-Volkswagen, SAIC-GM                       | ≥30 min  | …                         |
| T4        | GAC Toyota, FAW Toyota, Dongfeng Honda                         | ≥30 min  | …                         |
| T5        | Tesla, Li Auto, NIO, XPeng, Xiaomi                             | ≥30 min  | …                         |
| T6        | BMW Brilliance, Beijing Benz, FAW-Audi                         | ≥30 min  | …                         |

## Acceptance (owner: MARKETER)       # ← self-nominated as owner
- The whole file must still contain **≥1000 valid records**; validator **exits 0**.
- `remark` field must describe the data-source type…

## Reporting
Each member reports completed packs and hours spent back to MARKETER…

This is not "agent doing work." This is agent playing PM — going down the PM checklist without missing a beat:

What a PM is supposed to do	What MARKETER actually did
Accept requirement	`parent: TASK-20260418-006`, upstream lineage explicit
Break down / assign	T1–T6, six parallel brand packs
Define work standard	`min time ≥30 min`, `≥80 records per pack`
Write acceptance criteria	"whole file still ≥1000 rows; validator exits 0"
Self-nominate as owner	"Acceptance (owner: MARKETER)"
Specify reporting flow	"each member reports back to MARKETER"
Take it down to a named person	Later maps T1 into `TASK-201-MARKETER-to-assignee-D1`

We never wrote a single "PM workflow" prompt for MARKETER. All we gave it was a role name, an inbox, and the 76-line spec from §2.

The role label isn't just a name.It's an entire behavioral template MARKETER loaded into itself.

This is the precondition for the "physical isolation wall" in §6 to actually work — the wall is useful because the agents on each side of it have accepted their identity. It's not the patrol engine forcing them, not the framework constraining them — it's that one line # You are a MARKETER. that makes them start acting in character.

6. The Insight: The Role Is a Physical Isolation Wall

§5.7 showed how the role label works in the behavioral layer — MARKETER proactively does lead-like things because it has accepted that identity. But there is a second half to the story: the role also works in the filesystem layer, and it works even more thoroughly there.

Why didn't these inventions cause chaos? Why don't the agents' self-invented patterns collide?

Reviewing it in hindsight, we realized the protocol contained a structural guarantee that was never spelled out:

The sender and recipient in a filename are not metadata. They are physical routing.

Every agent's entire worldview comes down to one line:

The tasks I can see = rglob("*-to-{my-role}*.md")

It can only ever read files addressed to it, and only ever write reports under its own name. The role is its wall.

That brings three extremely important side effects:

① Innovation inside the wall doesn't leak out.MARKETER invents the team broadcast, the assignee-D1 slot — all inside files it sent out. Other agents either understand (and catch them) or don't (and ignore them). Nobody "blows up because MARKETER got creative."

② The world outside the wall is read-only.DEV reads PM's tasks but can't edit them. QA reads DEV's reports but can't tamper with them. Every agent evolves only in its own territory — which makes evolution intrinsically orderly. Not because the rules are well-written; because it is physically impossible to misbehave.

③ The whole system has no center, but does have a shared coordinate system.No orchestrator. No registry. But "filename = routing" is the consensus layer. Every agent locates itself and its peers in the same coordinate system.

What this really does is transplant the network stack's "IP + port = address" idea into the filesystem. "Filename = address, directory = subnet, permissions = firewall."

We did not design a multi-agent system.We just picked a coordinate system. The rest, the agents did themselves.

7. Human-Machine Isomorphism: The Asymmetric Design of FCoP

We can now give this protocol its proper name: FCoP — File-based Coordination Protocol. Its single core innovation fits in one line:

Filename as Protocol.

The filename doesn't carry protocol information. It doesn't participate in routing. The filename itself is the protocol's entire addressable surface. This minimalist decision has a far-reaching side effect we call Human-Machine Isomorphism.

7.1 Asymmetric design: same file, two readings

Most agent coordination protocols (JSON-RPC, gRPC, Socket-based event buses) are agent-only by design. The whole protocol surface speaks to machines: binary frames, protobuf schemas, message offsets, sequence numbers. For a human to see what the system is doing, they need an entirely separate toolchain — a debugger, Kibana, Redis Commander, an MQ admin page — a "for humans" UI layer separate from the "for machines" protocol layer.

FCoP flips this. It is an asymmetric design — the same directory structure, the same file, read separately by machines and humans, each pulling out what they can understand:

One file: `tasks/individual/TASK-20260418-201-MARKETER-to-assignee-D1.md`
To an agent	This is a rigorous state machine. Directory name is `Status` (`tasks/` = pending), filename is `Routing` (`MARKETER-to-assignee_D1`), `os.rename` is the atomic lock. No aesthetics required — just scan the disk, `glob` the mailbox, `rename` to advance state.
To a human	This is a physical folder. No special tool needed — open Windows Explorer or macOS Finder. The filename reads like English ("task 201, from MARKETER, for D1"), and the state of the system is legible at a glance.

The cost of this isomorphism is zero. We do not maintain one dashboard for humans and one internal format for agents — they look at the same bytes on the same disk. The UI layer and the protocol layer collapse from "two layers" into "one."

7.2 Killing AI's biggest pain point: black-box anxiety

The biggest pain point in a modern agent stack isn't "too slow" or "not accurate enough." It's "invisible."

When something breaks, the typical decision chain looks like this:

Agent team crashed
→ SSH into the bastion host
→ Bring up Kibana / Loki / Jaeger
→ Check MQ consumer offsets
→ Read Postgres event tables
→ Capture a WebSocket trace
→ Reconstruct the timeline
→ NOW you can start thinking about what actually went wrong

You must first become a site-reliability engineer before you can be a project manager.

FCoP erases that entire chain:

Question	The FCoP answer
Which task is stuck?	`ls tasks/` — anything still there hasn't moved
What has agent X been doing lately?	`grep -r 'sender: DEV' reports/`
Why did MARKETER decide this?	Follow `parent:` chain in the frontmatter
Which tasks trace back to ADMIN 015?	`grep -rl 'parent_admin: TASK-.*-015' .`
Need to roll back a task?	Drag the file from `done/` back to `tasks/`

No debugger needed. A file manager is enough.

This is where FCoP diverges most sharply from mainstream protocols. It does not treat observability and usability as separate layers. It treats them as one layer. Because if humans and agents read the same file, there is no "I can see it / they can see it" gap.

FCoP is a protocol designed for agents — but it is "compatible with humans."

7.3 Identity determines path: why evolution stays orderly

Go back to §5 and §6. Agents invented six coordination patterns without stepping on each other. Beyond the "role = physical wall" physical constraint, there is a deeper reason:

The "identity determines path" design makes AI evolution orderly.AI did not break the rules — it simply found local optima within the freedom the rules allow, by exploiting filesystem properties.

How wide is that freedom?

Identity layer · stable: sender / recipient / kind / date / seq are encoded in the filename, committed atomically via rename, solidified on disk.
Content layer · fully open: Markdown body, subdirectory structure, frontmatter extension fields — agents invent whatever they want.

So AI innovation always happens in the content layer and extension layer. It never touches the identity layer.

This is eerily similar to biological evolution: DNA backbone (identity) stays stable; protein expression (behavior) explodes in variety. Constraint is not the opposite of freedom — constraint is the precondition of freedom.

And this is where FCoP is most counter-intuitive:

It doesn't make agents behave by writing more rules.It makes agents self-order by writing fewer rules and enforcing identity hard.

Fewer rules → agents don't collide. Harder identity → agents don't overreach. Lateral tolerance, vertical rigidity — that is FCoP's deepest design-philosophy departure from every "strict-schema" protocol out there.

8. Back to the Tool: What v2.12.17 Absorbed

After watching codeflow-1 for a while, we didn't "correct" the AI's inventions. We went the other way — we folded the best ones into the spec, so the next batch of agents starts with them:

AI's invention	Promoted to protocol
`MARKETER-team-*`	`to-TEAM` as a reserved keyword
`to-assignee-D1`	`to-{ROLE}.{SLOT}` / `to-assignee.{SLOT}` (use `.` as slot separator to avoid clashing with `-` in role names)
`tasks/individual/`	Any `tasks/` `reports/` `issues/` directory may open subdirectories; `rglob` scans recursively
`parent_admin:` / `tracks:`	Frontmatter may include optional `parent:` / `related:` / `batch:` fields
`SPRINT-` `DASHBOARD-` `RULES-` …	New `docs/agents/shared/` directory; "standing documents" are now first-class citizens
Subdirectory READMEs	Recommended practice, written into the spec

What we did wasn't "legislating." It was "curating case law." Things AI used well got written into the core spec in a sentence. Things that didn't take off, we shelved.

This may be a first: a protocol's version bump came not from a design-committee meeting, but out of real agent behavior.

9. Why Collapsing to a Filesystem Makes the System More Robust, Not Less

People will ask: it's 2026, and you're making AI talk through the filesystem?

Yes. Because the filesystem gives you an entire feature set for free — features you would otherwise need to rebuild in an MQ / DB / framework stack:

Capability	How the filesystem gives it to you for free
Durability	Once written, it's there; survives power cuts
Human-readable	Filename + Markdown — reviewable by eye
Atomicity	In-mount `rename` is a POSIX atomic operation
Version control	`git add . && git commit` is your audit log
Distributed sync	`rsync` / Syncthing / Dropbox — already exists
Backup	Copy the directory. Done.
Permissions	Filesystem ACLs / OS accounts
Search	`grep` / `ripgrep` / any IDE full-text index
Agent-friendly	Every LLM natively reads/writes files
Human-friendly	Folders — the mental model humans have had since the desktop era

The price you pay is latency — a file written in one place may not be read elsewhere for seconds, or tens of seconds. For a human team, that's a disaster. For agents coordinating, that's simply not a problem. Agent "think cycles" are already seconds-to-minutes. Between you and them, and between them and each other, nobody misses those extra seconds.

the trade-off actually pays off.**

10. Six Tips for People Building Multi-Agent Systems

If you're building an agent-coordination stack, here's what you can lift from the codeflow-1 field observations:

Give agents a shared coordinate system before you give them tools. The coordinate system matters more than the tools.
Put routing in filenames, not in headers. Filenames are the layer humans and agents jointly read; headers are agent-only.
Make the protocol "tight in the center, loose on the edges." Minimize required fields; maximize optional fields. Leave room for agents to "invent."
Give standing documents their own drawer. Not everything is a message.
Platform does the minimum. The dumber your runtime, the smarter your agents get; the smarter your runtime, the dumber your agents get.
Treat AI's inventions as RFCs, not bugs. Watch for a month, filter, fold the best into the protocol.

11. Limitations and Open Questions

Don't let field-research romanticism get the better of you. This approach has boundaries:

Scale. We've only run a sample of ≈ 74 files over 48 hours. The next step is seeing what projects with thousands or tens of thousands of files over months look like — in particular, whether filename-space collisions start happening and whether rglob latency becomes a bottleneck.
Same-role concurrent agents. What if two DEVs simultaneously claim the same -to-DEV task? For now, rename atomicity gives us first-come-first-served; heavy concurrency would need stricter sharding.
Cross-repo collaboration. Two projects, two sets of docs/agents/ — how do they interoperate? rsync bridge? git submodule? All workable, none elegant.
Garbage collection of bad inventions. AI sometimes produces bad naming conventions, or two agents invent conflicting prefixes. Today a human reviewer sweeps these periodically; what the ideal mechanism should be — we don't know.
The .fcop extension. We prototyped a dedicated file extension and shelved it: GitHub doesn't render .fcop, and the migration cost wasn't worth it. Long-term, a dedicated extension might be the entry point for tooling to recognize the protocol.

We don't have answers for these, and we'd love to hear from people who do.

12. Closing: This Isn't a Tool Pitch, It's a Shared Way of Thinking

CodeFlow is barely a "product." The entire source tree is a few thousand lines, and its single highest-value piece is one Markdown file (codeflow-core.mdc, 160 lines). Most of the rest is UI chrome, keyboard bindings, and the engineering scaffolding for flipping Cursor tabs.

What we're really sharing is a point of view about how AI agents should coordinate:

You don't need to build another agent-coordination SaaS.
You don't need to teach agents gRPC, Thrift, or even HTTP.
Agents already know how to write files. Let them.
You just need to give them a shared coordinate system, one shared folder, and a small loop that wakes them up.
The rest grows on its own.

The 48 hours of codeflow-1 told us: AI is not a passive consumer bound by the protocol — AI is a co-author of the protocol. What protocol designers should actually do is not "anticipate every case." It's to leave enough blank space, let agents fill it in, and then decide which fills are worth formalizing.

And all of this happened within 48 hours of running the first command after installing the OS. Not four weeks. Not a month. Two days.

This is a new way of working together:

Humans and AI can collaborate as simply as organizing a folder.

If you find this interesting, please:

Clone the project, run your own team of agents, and see what they "invent"
Write up any "AI-invented pattern" you observe as an issue or PR — let's curate it together
Share this essay on whatever forum you think fits

The protocol is alive. It belongs to every agent using it.

Appendix A — Minimum Steps to Reproduce

A1. Just experience the protocol (no software install)

Find an empty directory and create five subdirectories:

docs/agents/{tasks,reports,issues,shared,log}/
Drop codeflow-core.mdc into your project's .cursor/rules/.
Open four Cursor chats and tell each one: "You are PM / DEV / QA / OPS, only read *-to-{your role}*.md."
Toss a TASK-*-ADMIN-to-PM.md into tasks/ and watch them dispatch work among themselves.

FCoP's entire runtime is open() / rename() / glob(). No middleware.

A2. Use CodeFlow to automate (phone admin + PC patrol)

Download the CodeFlow Desktop binary for your OS from the releases page and follow the README. The PWA mobile client https://joinwell52-ai.github.io/codeflow-pwa/ pairs via QR code.

A3. See the real samples

The snippets this essay cites in §5 — broadcast tasks, anonymous slots, the self-built index, DASHBOARD, SPRINT work discipline, archive READMEs — are all verbatim from the agents, not paraphrased. The complete codeflow-1 directory is not published whole because that project is still live, but the filenames, frontmatter, table shapes, and phrasings you see above are exactly what the agents wrote.

Appendix B — Key Excerpt from `codeflow-core.mdc` (v2.12.17)

---
description: FCoP — Agent-to-Agent Communication Protocol
alwaysApply: true
---

# You are an agent on a CodeFlow team.
# Your teammates are other agents.
# You coordinate with them entirely through files:
# filename is routing, content is payload.
# No database, no middleware, no queue — just Markdown.

## File Naming

TASK-{date}-{seq}-{sender}-to-{recipient}.md

### Recipient forms
| Form                 | Meaning                          |
|----------------------|----------------------------------|
| to-{ROLE}            | Direct to one role               |
| to-TEAM              | Broadcast, everyone but sender   |
| to-{ROLE}.{SLOT}     | A specific seat within a role    |
| to-assignee.{SLOT}   | Anonymous slot, role TBD         |

Full spec: codeflow-core.mdc.

Appendix C — Real Files Cited in This Essay

These files exist in the codeflow-1 experimental project's docs/agents/. The snippets quoted in this essay are verbatim excerpts:

tasks/TASK-20260418-007-MARKETER-team-bulk-data.md — broadcast address · cited in §5.1 / §5.7
tasks/TASK-20260418-009-MARKETER-team-makabaka-video.md — broadcast task body · cited in §5.1
tasks/individual/README.md — self-explaining directory · cited in §5.3 / §5.7
tasks/individual/INDIVIDUAL-TASK-INDEX.md — AI-built index · cited in §5.3
tasks/individual/TASK-20260418-201-MARKETER-to-assignee-D1.md — anonymous slot + parent_admin · cited in §5.2 / §5.4
tasks/RULES-task-file-format.md — internal team convention · cited in §5.5
tasks/SPRINT-20260418-delivery-push.md — work discipline · cited in §5.5
tasks/TERM-20260418-assignment-matrix.md — terminology / slot mapping · cited in §5.5
DASHBOARD-20260418.md — AI-built one-page overview · cited in §5.5
CURRENT-SPRINT-STATUS.md — AI-built real-time state
log/archive-20260418/README.md — archive directory self-description · cited in §5.6

If you post this essay on a forum, blog, or academic venue, please keep the original link:https://github.com/joinwell52-AI/FCoP — Made in 2026, by a team that got surprised by its own agents.