Why Multi-Agent Governance Can Start with Files

Original research article: English · 中文 · Research Center

The first problem in multi-Agent collaboration is not how to open more sessions. It is how to turn one role's task, another role's delivery, and a third role's review into shared facts that every participant can inspect.

• Which task version was authoritative?
• Who changed the scope?
• Which test report belongs to which implementation?
• Did the rejection reason enter the rework request?

The missing component is not a smarter model. It is shared operational truth.

For a local-first, single-machine system with low or moderate concurrency, that truth can begin as files. Tasks, reports, issues and review decisions become explicit artifacts. Paths expose current lifecycle state. Ordered events preserve how state changed.

The protocol starts with one rule:

AI roles cannot coordinate only in their heads. The work must be written into files.

This is not an argument that files should replace databases, queues or workflow engines. It is an ordering principle: make the work visible before upgrading the control plane.

The useful Unix lesson is a common interface

Ritchie and Thompson’s The UNIX Time-Sharing System is often reduced to “everything is a file.” The more useful engineering lesson is that ordinary files, devices and inter-process I/O could be reached through compatible interfaces and hierarchical names.

That idea transfers to Agent governance in three ways:

1. A human can inspect a task in an editor, an Agent can parse it, a CLI can scan it, and a web view can index it without requiring one SDK.
2. Names and paths can carry stable meaning: inbox/, active/, review/ and done/ are a state surface both programs and people can understand.
3. Creation, validation, transition, review and archival can remain separate tools if they honor the same artifact contract.

Unix still needed processes, permissions, pipes and internal interlocks. Files do not automatically provide safe concurrent updates, distributed consistency or exactly-once execution. Here, “files first” means externalizing coordination facts through open artifacts where practical.

A directory becomes a work ledger only with contracts

The blackboard model describes multiple knowledge sources contributing intermediate results to a shared problem-solving surface. A directory can implement such a surface, but an unstructured folder is not governance.

It becomes useful only when:

• every artifact has a defined identity;
• current state has one authoritative location;
• transitions leave ordered evidence;
• roles have explicit responsibilities; and
• completion depends on evidence rather than an Agent assertion.

A shared ledger coordinates work facts and evidence. It does not replace execution or distributed consistency.

Chat is organized by who spoke when. A work ledger is organized by the work object, current owner, evidence and decisions.

Separate four kinds of work facts

FCoP uses four IPC artifacts to keep different claims apart:

Artifact	Question it answers	Minimum useful content
TASK	Who is expected to deliver what?	sender, recipient, scope, priority, acceptance
REPORT	What did the worker actually do?	task reference, changes, tests, evidence, risks
ISSUE	What is blocking delivery?	symptom, impact, attempts, required decision
REVIEW	Who judged what evidence?	subject, reviewer, verdict, rationale, next action

Five lifecycle buckets: use location to answer “where is the task now?”

The five directories under _lifecycle/ form a minimal observable state machine. A TASK may occupy only one bucket at a time; moving the file is the state transition.

Lifecycle bucket	Question it answers	Typical action
inbox/	A new task exists. Who will claim it?	create, then wait for claim
active/	Who is executing or reworking it?	claim; rejected work returns here
review/	Delivery was submitted. Who will decide?	submit, then approve or reject
done/	Did the protocol lifecycle finish or receive approval?	finish or approve; this is not yet business acceptance
archive/	Has the work left the active collaboration surface?	archive after upstream acceptance

inbox --claim--> active --submit--> review --approve--> done --archive--> archive
                    |   ^                   |
                    |   +------reject-------+
                    +---------finish------->+

Four rules keep this model unambiguous:

1. One current location: the same TASK cannot exist in both active and done.
2. Move, do not relabel: state changes through controlled migration, not an Agent editing a mutable status field.
3. Separate now from history: the path answers “where is it now”; append-only transitions: records how it arrived there.
4. Separate state from credentials: REPORT, ISSUE and REVIEW are delivery, blocking and governance evidence, not current task state.

FCoP v2's tasks / reports / issues / shared / log were the old five buckets organized by artifact type. FCoP v3's _lifecycle/ buckets organize TASK files by work stage. They are different concepts.

Likewise, _lifecycle/review/ means a TASK awaits a decision, while reviews/REVIEW-*.md is an independent governance judgment.

For current lifecycle position, the path is the authoritative NOW fact. For business completion, the upstream role's acceptance of the REPORT and its evidence is decisive.

This distinction keeps a worker's completion claim, protocol approval, and upstream acceptance from collapsing into one ambiguous done label.

Inspectability improves rework

The FCoP repository contains a small Tetris dogfood evidence set. A task was underspecified, the implementer guessed instead of raising an ISSUE, and the defect appeared in the guessed area. Review rejected the result, and an administrator created a sharper rework task.

One example does not prove a production-scale defect reduction. It supports a narrower conclusion: when task, report, review and rework remain separate, failure does not collapse into a vague memory. A maintainer can locate where ambiguity entered and whether the rejection became an actionable next task.

The ledger does not eliminate mistakes. It makes them attributable and convertible into decisions.

When files are a sensible starting point

A file-backed ledger fits when:

• work stays on one machine or in a bounded workspace;
• human readability matters more than millisecond latency;
• artifacts should fit Git, backups and ordinary tools;
• people need to inspect and approve Agent work directly; and
• the protocol is evolving faster than the control-plane implementation.

Pressure for stronger infrastructure appears when many machines compete for tasks, strict transactions or granular authorization are required, leases and throughput guarantees become central, network-filesystem semantics are insufficient, or directory scanning becomes a bottleneck.

The useful separation is between an artifact plane, which preserves readable evidence, and an execution plane, which owns scheduling, isolation, retries and scale.

A minimum ledger you can inspect today

project/
  fcop/
    fcop.json
    _lifecycle/
      inbox/
      active/
      review/
      done/
      archive/
    reports/
    issues/
    shared/
    reviews/
    history/
      YYYY-MM-DD/
  workspace/
    <slug>/

This structure contains three different planes:

• _lifecycle/ is the current TASK state plane;
• reports/, issues/, and reviews/ form the evidence and governance plane and do not move with TASK state;
• history/ is the long-term history plane for closed tasks and paired reports.

Each TASK keeps append-only migration history in transitions:. A separate events/ directory would create another truth that could drift from the task file.

Then ask:

1. Does each task have a unique identity and recipient?
2. Can a human find the authoritative version in under a minute?
3. Does “done” link to tests, a diff or environmental evidence?
4. Is the worker report separate from the reviewer judgment?
5. Does rejection create a traceable next action?
6. Do transitions retain time, actor, source and destination?
7. Can a restarted runtime reconstruct what happened from disk?

If most answers are “no,” adding more Agents will usually increase ambiguity rather than throughput.

What “everything is a file” contributes to engineering

The point is not to replace databases, queues and workflow engines with Markdown. It is to establish an open protocol surface with five engineering properties:

Engineering property	How the ledger provides it
Addressable	stable task identity, sender, recipient and parent relationships
Observable	lifecycle buckets expose the current stage directly
Replayable	transitions: preserves time, source, destination, actor and tool
Verifiable	TASK, REPORT, ISSUE and REVIEW can be checked against each other
Composable and evolvable	editors, Git, CLIs and web views share the same artifacts, while stronger infrastructure can be added later

Stable identity + path state + transition history + delivery evidence = a governable shared work ledger.

The ledger does not solve contention, transactions, authorization, retries or scheduling by itself. It first answers more basic questions: was the work formally delegated, who owns it now, why was it rejected, and what evidence justified acceptance?

Starting with files is neither nostalgia nor a rejection of infrastructure. Its engineering value is to let humans, Agents and tools share the same inspectable facts, then upgrade the execution plane in response to real pressure.

FCoP is not an industry standard or a final answer. It offers a testable starting point: before expanding the control plane, make the collaboration visible, machine-readable and evidence-checkable.

The next implementation question is how to make path transitions testable without exposing partial artifacts. That is covered in Files, Paths, and Events: Implementing and Testing the FCoP State Machine.

Sources: UNIX paper · Blackboard model · FCoP v3 specification · FCoP boundary charter

More research notes: JoinWell52 Research Center