DEV Community: joinwell52

Farewell to the “Black-Box Myth”: Engineering Reflections on Mainstream Agent Frameworks and the Rise of Physical Externalization

joinwell52 — Tue, 22 Sep 2026 14:37:46 +0000

Introduction: The Recurring Cycle of Software Engineering and the Agent Illusion

Looking back at the evolution of computing, every breakthrough primitive seems to trigger a familiar cycle: the primitive is first mythologized → oversized black-box middleware is built around it → reality pushes back through physical and engineering constraints → the industry eventually rediscovers the low-level boundaries that abstraction could never erase.

Distributed computing went through this in the 1990s. CORBA and DCOM tried to make remote invocation resemble a local function call as closely as possible, softening the visible boundaries of latency, partial failure, and partitioning. The Web took a different route: it accepted the network as a physical boundary and used HTTP, uniform interfaces, and looser resource semantics to reduce coupling. Enterprise integration followed a similar pattern. Heavyweight ESBs once tried to absorb message orchestration, transformation, and global coordination inside a central bus; later architectures redistributed many of those responsibilities across event streams, commit logs, APIs, and lighter contracts.

The AI Agent industry is now replaying a remarkably similar architectural temptation. A large language model begins as a probabilistic generator, yet once it can plan, call tools, write code, and coordinate with other models, we keep assigning it more roles: scheduler, memory system, message bus, state interpreter, and sometimes even the final judge of whether a task is complete.

When production systems repeatedly encounter task loops, state drift, irreproducible execution, and opaque debugging, the right question is no longer merely “can the model become smarter?” It is a more fundamental systems question:

Are we assigning too many system responsibilities to a component that is excellent at probabilistic cognition but poorly suited to being the sole source of durable truth?

Over the past three years, the most important change in Agent engineering has not been that models are becoming more human-like. It is that systems are becoming less willing to trust models to remember everything, coordinate everything, and explain everything by themselves.

In 2023, prominent Agent systems emphasized iterative reasoning, role play, and natural-language collaboration. By 2025–2026, mainstream engineering frameworks had shifted more responsibility toward durable execution, checkpoints, state inspection, workflow state, and external artifacts. At the same time, EvoGit, tap, PheroPath, SwarmWorld, FCoP, and related work pushed coordination further out of messages and private runtimes and into Git, files, shared environments, and protocolized artifacts.

This does not mean that “the filesystem will replace LangGraph,” nor that stigmergy has been proven superior to centralized orchestration. The more restrained and more important principle is:

Agents may be probabilistic, but collaboration facts should not exist only inside probabilistic context.

From Context to Messages, from Checkpointed State to Artifacts and then Protocolized Artifacts, the real change is a gradual migration of factual authority away from the model’s private context.

The rest of this article examines what papers, frameworks, and open-source projects actually support—and what they do not.

Background: What Is Actually Changing in Agent Engineering?

The strongest idea in the original argument is the refusal to keep treating the LLM as an omniscient state bus. But to make that claim technically defensible, three misconceptions must be corrected.

First, the problem is not that LLMs are incapable of self-correction. The problem is that they do not possess a built-in fact-type system.

Autoregressive models can notice and fix earlier errors. The danger is that once an erroneous output enters subsequent context, it is conditioned together with verified tool observations, user facts, and model speculation. Unless the surrounding system records provenance, validation status, re-fetch rules, and rollback boundaries, there is no native marker saying: “this sentence was only your earlier guess; do not treat it as a database fact.”

Long-context research reinforces this caution. Lost in the Middle showed that moving relevant evidence to the middle of a long context can reduce performance for many models. [7] Later work has associated these effects with positional attention biases. Newer models have improved in some retrieval settings, so “middle information is always lost” should not be treated as a permanent law.

The engineering principle should therefore be stated as:

Do not require the model to maintain, over long periods, which historical statement is the current fact. Put identity, version, validity, and verification status into the system.

Second, natural language is not “absurd IPC,” but using open-ended language directly as the control protocol is expensive.

IPC can be shared memory, pipes, sockets, HTTP, JSON, protobuf, or text. The real distinction is not binary versus textual. Control-plane protocols usually seek low ambiguity, explicit fields, typed errors, idempotency, and machine-verifiable boundaries. Free-form language pushes semantic interpretation back onto a probabilistic model.

AutoGen illustrates the conversation-centric route well: its paper models conversable agents and flexible conversation patterns. [8] Its historical GroupChat design also reflects managed speaker selection and conversation-context passing. By 2026, AutoGen had entered maintenance mode and Microsoft was recommending the Microsoft Agent Framework to new users—another sign that “group chat as architecture” is no longer the only evolutionary path.

Third, modern Agent frameworks have hybridized. They cannot be classified by a frozen 2023-era product image.

A better classification asks where coordination primarily lives:

Primary coordination locus	Typical mechanism	Representative examples	Main risk
Context-centric	Model repeatedly reads and extends context	AutoGPT Classic, original BabyAGI	Polluted history, token cost, weak recovery boundaries
Conversation-centric	Agents coordinate through messages, group chat, and handoff	AutoGen, MetaGPT, CrewAI Crews	Semantic ambiguity, message growth, complex termination/routing
Runtime-state-centric	Graph/event/workflow + checkpoint + deterministic routing	LangGraph, LlamaIndex Workflows, CrewAI Flows, current AutoGPT	Framework coupling, state-schema evolution, runtime-specific recovery
Artifact/environment-centric	Git, files, worktrees, shared artifacts, environmental traces	Aider, EvoGit, tap, PheroPath, FCoP, Govcraft, SwarmWorld	Storage semantics, concurrency, metadata scale, artifact governance

These styles are not mutually exclusive. Aider still uses model context but anchors code changes in Git; CrewAI combines autonomous Crews with controlled Flows; OpenHands combines conversations/events with a real workspace and code artifacts; LangGraph ecosystems increasingly use filesystem-backed tools.

So the evolution is not:

conversation frameworks → file frameworks

It is closer to:

model memory → framework memory → durable artifacts → open governance contracts.

Research Scope and Evidence Principles

This article primarily draws on papers and open-source projects from 2021–2026, focusing on Agent state management, multi-Agent coordination, shared artifacts, Git/file collaboration, externalized memory, and stigmergic coordination. Papers are cited from original or formally published versions whenever possible; engineering claims are grounded primarily in official GitHub repositories, READMEs, and project documentation.

Where implementation details cannot be fully verified from public materials, the article avoids inference and states the verification boundary explicitly. Judgments about reliability, auditability, and engineering complexity are qualitative architectural analyses based on public evidence, not a unified benchmark ranking.

Evidence Summary: Papers and Open-Source Projects

The papers most relevant to the article’s thesis include:

Work	Date	Evidence relevant to this article
Lost in the Middle	2023; TACL 2024	Long-context use is position-sensitive; evidence placed in the middle can reduce performance. This does not prove that models “forget,” but it undermines the idea that a context window is a reliable state database.
MetaGPT	2023; ICLR 2024	Organizes multi-Agent software work around roles and SOPs, and explicitly discusses cascading hallucination in naive chaining.
AutoGen	2023	Makes conversational agents and conversation patterns first-class abstractions for multi-Agent applications.
ChatDev	2023; ACL 2024	Decomposes software development into chat chains and adds communication/dehallucination mechanisms.
EvoGit	2025-06	Independent coding agents evolve shared code asynchronously through Git lineage without direct messaging or shared memory.
Externalization in LLM Agents	2026-04	Frames memory, skills, protocols, and harness engineering as externalization of cognitive burden.
tap	2026-06	Uses a file-first protocol, persistent Markdown messages, and Git worktree isolation for heterogeneous LLM-agent collaboration.
SwarmWorld	2026-08	Shows role differentiation and artifact reuse among initially homogeneous agents in a persistent shared environment, while preserving important limits on the superiority of interaction.

These papers support the claim that external structure is becoming more important, not the stronger claim that central orchestration has been proven obsolete.

The open-source landscape is similarly hybrid. AutoGPT has evolved beyond its Classic autonomous-loop image; CrewAI combines Crews and Flows; LangGraph makes checkpoints and durable execution core infrastructure; Aider anchors model edits in Git; PheroPath attaches coordination signals to files; FCoP formalizes typed collaboration artifacts; Govcraft experiments with pressure-field coordination.

Technical Analysis: From Where State Lives to Where System Facts Live

What makes an Agent system a “black box” is not whether it uses a graph, a database, or files. It is which layer owns final factual authority.

State Carriers Define Failure Boundaries

A context window has almost no infrastructure overhead: the model can read it directly. But guesses, observations, tool results, constraints, and protocol text can collapse into one token stream. As the history grows, cost and positional retrieval risk also grow. Lost in the Middle is enough to show that “fits in context” and “can be reliably retrieved” are not equivalent. [7]

Chat history is more structured than a monolithic context but is still primarily an event transcript, not authoritative application state. “Agent A said the task is complete” is not the same fact as “the task passed validation and was committed.”

Checkpoint databases improve this substantially. LangGraph makes durable execution and state resume core capabilities; LlamaIndex Workflows can persist workflow state to files or databases. [5] [29]

The artifact-oriented alternative changes the access relationship:

Framework-mediated state:
Human -> SDK -> serializer -> checkpoint -> state

Artifact-mediated state:
Human/tool -> file/git/schema -> state

The second structure is easier to inspect out-of-band, but it is not automatically transparent. A 200 MB opaque JSON blob on disk is still a black box. Conversely, a PostgreSQL checkpoint with a stable open schema, versioning rules, and audit API can be highly auditable.

“Physical externalization” should therefore mean:

Critical collaboration facts are persisted as artifacts with independent identity, stable semantics, open read paths, and verifiable provenance, so that their lifecycle does not depend on the model session that created them.

It should not mean:

“written to a file = externalization complete.”

Durability, Portability, and Auditability Are Different Properties

Carrier	Durability	Portability	Auditability	Main note
Prompt / context	low–medium	low	low	Transcript can be preserved, but runtime fact boundaries are weak
Chat-history DB	medium–high	medium	medium	Has chronology, but message ≠ verified state
Private checkpoint	high	medium–low	medium	Strong recovery; cross-framework interpretation depends on schema/API
JSON / Markdown artifacts	high*	high	high*	Depends on storage, schema, and provenance
Git objects / commits	high	high	high	Excellent for code/text; not ideal for every high-frequency mutable state
xattr	medium	low–medium	medium–low	Bound to files, but Git/copy/cross-platform visibility varies
Object-store artifacts	high	high	high	Namespace and atomic-transition semantics differ from POSIX

PheroPath exposes an important paradox: physical existence does not automatically imply universal visibility. Hidden xattrs can be elegant, but an explicit sidecar JSON file may be easier for Git, CI, backups, and cross-language tools to consume.

Control Flow Is Moving from Language Semantics Toward Deterministic Boundaries

CrewAI now pairs role-based Crews with event-driven Flows that support structured state, branching, and routing. [44]

LangGraph makes durable workflow and state transition part of its orchestration layer. [5]

LlamaIndex Workflows uses async functions that produce and consume events while supporting loops, parallelism, persistence, and recovery. [29]

These systems are converging on a common principle:

“What happens next” should not always be decided by asking the model to say one more thing.

The model is well suited to:

Unstructured input
    ↓
Candidate structured decision

The workflow layer should own:

Candidate decision
    ↓
Validation
    ↓
Authorized state transition

The goal is not to make every model call literally stateless. Real Agents have tool sessions, caches, memory, and side effects. The goal is to prevent any one model call from having exclusive authority over global system facts.

Stigmergy Reduces Direct Coordination Dependence; It Does Not Eliminate Coordination

SwarmWorld, EvoGit, and Govcraft support the idea that a shared environment, Git genealogy, or shared-state pressure field can become a first-class coordination medium, rather than merely passive storage after a conversation. [14] [22] [35]

That does not prove that “stigmergy always beats conversation.”

A more defensible conclusion is:

For problems with a shared constraint surface, where local actions leave measurable environmental changes and solutions can accumulate through local improvement, stigmergic coordination deserves to be compared directly with conversation and hierarchy as an independent architectural baseline.

Strongly transactional workflows, approval chains, and regulated processes still require explicit accountability and global invariants.

Atomicity Is Where Physical Externalization Is Most Easily Romanticized

FCoP treats os.rename() as an important synchronization primitive on shared directory trees, but FCoP 4.0.3 has evolved far beyond “directory + Markdown + rename.” Its public protocol semantics include TASK / REPORT / ISSUE / REVIEW, Attempt, relations, authorization, Branch Family convergence, idempotency, and crash-safe recovery.

The attraction of filesystem state transitions is obvious:

inbox/TASK-123.md
      |
      | atomic namespace transition
      v
active/TASK-123.md
      |
      | result validated
      v
review/TASK-123.md
      |
      | accepted
      v
done/TASK-123.md

But four concepts must remain separate:

atomic visibility
≠
exclusive ownership
≠
crash durability
≠
distributed consensus

A same-filesystem rename can help guarantee that observers do not see a half-renamed path. It does not solve every distributed-consistency problem.

Object storage makes the distinction even clearer. General-purpose S3 historically implements renaming through copy plus delete, while S3 Express One Zone directory buckets now expose atomic RenameObject. [42] [43]

The engineering lesson is not to force every backend to behave like POSIX. It is to separate protocol invariants from backend-specific storage primitives.

Small Files, Orphaned State, and Recovery Do Not Disappear by Declaration

There is no universal file-count threshold at which every filesystem “fails.” The general problem is that, at scale, cost shifts from payload I/O toward namespace and metadata operations, directory scanning, indexing, watching, backup, retention, antivirus, and synchronization.

A better design uses hot/cold tiers, immutable event segments, compacted snapshots, and archival storage.

Likewise, “orphan lock” is only one ownership pattern. With immutable attempts, process death can leave an incomplete attempt instead of a permanent blocking lock:

task-42/
    attempt-001/  failed
    attempt-002/  expired
    attempt-003/  accepted

The recovery principle is:

Do not recover by erasing the accident. Recover by making the accident a legitimate part of history.

The Real Advantage of Externalization Is Not “It Cannot Fail”

Exposing state through a filesystem or object store does not automatically solve concurrency, identity, authorization, schema migration, or recovery.

Its greatest advantage is not that it “never fails.” It is this:

When it fails, there is a better chance that the failure leaves facts a third party can inspect.

Figure 2 | From Checkpoints and Git to Filesystem Protocols: collaboration facts progressively externalize.

Case Deep Dive: From Checkpoints and Git to Filesystem Protocols

LangGraph: Beyond the “In-Memory Black Box,” but Still Runtime-Defined

LangGraph explicitly positions itself as a low-level orchestration framework for long-running, stateful agents and makes durable execution, failure resume, human state inspection, and persistent memory core capabilities. [5]

So the criticism “LangGraph crashes and all state is lost” is obsolete.

The more accurate structure is:

LLM / Tool Node
      ↓
Graph Transition
      ↓
Framework State
      ↓
Checkpoint
      ↓
Persistent Backend

The deeper question is whether a checkpoint can be understood by another language or governance tool without importing LangGraph, starting the original Python application, or reconstructing the original node semantics.

If not, the state remains partly enclosed by the runtime. This is not a defect so much as the natural price of a runtime abstraction.

A pragmatic design keeps both:

LangGraph internal checkpoint
           +
external canonical artifacts

Internal checkpoint state serves recovery; canonical artifacts serve cross-framework fact exchange.

Aider: The Important Lesson Is Git as a Fact Anchor, Not SPEC.md

The claim that Aider requires every task to be materialized into SPEC.md or checkbox files is not supported by its official architecture.

What Aider explicitly does is map the repository, make Git commits, allow ordinary Git diff/manage/undo workflows, and run lint/test after changes. [9] [30]

The important pipeline is:

Prompt / conversation
        ↓
candidate edit
        ↓
working tree
        ↓
git diff
        ↓
lint / test
        ↓
commit

The model saying:

“I fixed it.”

is not the fact.

The facts are:

diff exists
test exit code = 0
commit hash = ...

This is a migration from linguistic claims to externally verifiable engineering facts.

PheroPath: A Powerful Idea—and an Auditability Paradox

PheroPath is one of the most literal “digital pheromone” experiments. [32]

It stores signals such as:

DANGER
TODO
SAFE
INSIGHT

through filesystem extended attributes or sidecar JSON, with CLI operations such as sniff, secrete, and cleanse, plus temporal decay and editor visualization.

The key insight is simple:

Context should be attached to the object being acted upon, not only to one conversation with the model.

But PheroPath also reveals a hierarchy inside “externalization”:

exists on disk
     ≠
visible to ordinary tools
     ≠
tracked by Git
     ≠
portable across platforms

For governance-critical data, an explicit sidecar artifact may be less elegant than xattr but easier for Git review, CI, backup, and object-store migration.

FCoP: From “Files as an Implementation Detail” to “Files Carry Protocol Semantics”

FCoP is a particularly useful example of Protocolized Artifacts.

Its formal name is File-based Coordination Protocol. Filename as Protocol is one of its core design ideas. Its paper/research record is published at DOI 10.5281/zenodo.22855630; the latest code archive is Zenodo Record 22746175, version 4.0.3. [33] [37]

FCoP 4.0.3 publicly defines:

TASK / REPORT / ISSUE / REVIEW
        ↓
explicit lifecycle
        ↓
Attempt / Relation / Authorization
        ↓
Root TASK + Branch Family
        ↓
family inspection + explicit convergence
        ↓
durable REVIEW / merge record
        ↓
idempotency + crash-safe recovery

Its significance is no longer merely “state mapped to folders.” It attempts to make collaboration facts carry explicit type, identity, state transition, authorization, relation, and recovery semantics.

FCoP also states its boundary: it is not itself a scheduler, Agent runtime, LLM SDK, database, or automatic merge-decision engine. Its value in this discussion lies in trying to make collaboration facts outlive any one model session or private runtime.

That does not make the filesystem a universal distributed-systems solution. Atomicity, backend adaptation, identity, schema evolution, binary artifacts, and security remain real engineering boundaries.

Govcraft and SwarmWorld: Valuable Because They Do Not Fully Support the Strongest Claim

Govcraft reports 270 meeting-room scheduling trials with the following solve rates:

Strategy	Solve rate
Pressure field	48.5%
Conversation-style	12.6%
Hierarchical	1.5%
Sequential	0.4%
Random	0.4%

[35]

This shows that, on that benchmark, the stigmergy-inspired shared-state pressure field clearly outperformed the authors’ baselines.

It does not show that hierarchy generally succeeds only 1.5% of the time in Agent systems.

SwarmWorld provides richer but similarly bounded evidence: shared societies build broader and more resilient technology portfolios; roles emerge; much reuse begins with environmental observation; yet isolated best-of-N search can still produce competitive best single artifacts. [22]

Together they support this narrower conclusion:

The environment can be a first-class coordination medium, not merely passive storage written after conversation.

A Physical-Externalization Workflow

A practical production pattern looks like this:

Task Queue / Workflow
        ↓
Canonical Task Artifact
        ↓
Agent Worker
        ↓
Candidate / Attempt Artifact
        ↓
Deterministic Validator
   ┌───────────────┐
   │               │
failed          passed
   │               │
new attempt     review / done
   │               │
   └──── evidence ─┘

The LLM no longer acts as the global state machine. It does what probabilistic cognition is good at: understanding open-ended problems, proposing candidate changes, summarizing, and planning. Final state transitions depend on external evidence.

Practice Route: Do Not “Migrate to Files”; Migrate to an Open Fact Contract

The practical goal is not to rewrite the Agent stack overnight. It is to gradually reduce the private runtime’s monopoly on factual authority.

1. Separate Transcript, Working State, and Canonical Fact

Transcript
    what the Agent said

Working State
    where the runtime currently is

Canonical Facts
    what has been verified and committed

“Tests pass” in a message is transcript. A validation record containing the commit, exit code, test-suite version, and timestamp can participate in a state transition.

2. Let Model Output Become a Candidate Before It Becomes State

LLM proposal
    ↓
Schema validation
    ↓
Deterministic / externally verifiable checks
    ↓
Commit

The core rule is:

“The model says the state should change” and “the system permits the state change” must be two different events.

3. Keep Runtime Checkpoints, but Add a Canonical Artifact Boundary

LangGraph, CrewAI, and workflow-runtime checkpoints remain valuable for execution recovery. There is no need to delete them in the name of externalization.

Use dual state:

internal checkpoint
    -> serves resume

canonical artifacts
    -> serve collaboration, audit, and interoperability

During migration, dual-write and reconcile until canonical artifacts can become the cross-system authority.

4. Treat Storage Semantics, Attempts, and Schemas as Part of the Protocol

Do not pretend POSIX is universal. Local filesystems, general-purpose S3, S3 Express, databases, and Git all have different transition primitives. [42] [43]

Prefer immutable attempts over repeatedly overwriting one state object:

task-id
  ├─ attempt-001 [expired]
  ├─ attempt-002 [failed]
  └─ attempt-003 [accepted]

Governance fields should also be structured and validatable, rather than buried only inside natural-language prose.

5. Test Four System Invariants

Safety: unverified candidates must never become canonical facts.

Liveness: failed workers must not permanently block progress.

Auditability: every committed transition must trace back to its inputs and evidence.

Portability: a third-party implementation must be able to interpret canonical state without the original Agent session.

If these four properties hold, the underlying store may be LangGraph, PostgreSQL, Git, a POSIX filesystem, S3, or a hybrid.

If they do not, even a directory tree can become a filesystem-shaped black box.

Figure 1 | The State-Externalization Ladder: Context → Messages → Checkpointed State → Artifacts → Protocolized Artifacts.

Conclusion and Future Research

What Agent engineering needs to abandon is not one particular framework. It is a deeper myth:

If the model becomes capable enough, it can simultaneously serve as reasoner, state machine, database, scheduler, message bus, authorization arbiter, and auditor.

Recent engineering evolution is steadily undermining that assumption. AutoGPT has moved from a standalone autonomous-agent image toward a workflow platform; CrewAI places Crews beside Flows; LangGraph makes checkpoints, durable execution, and state inspection foundational; Aider returns diff, commit, lint, and test to mature software-engineering tools; EvoGit, tap, PheroPath, and FCoP anchor collaboration facts in Git, files, shared environments, and protocolized artifacts. [24] [44] [5] [30] [14] [45] [32] [37]

The “rise of physical externalization” should therefore be retained, but redefined.

It does not mean:

Filesystem will replace Agent frameworks.

It means:

Canonical collaboration state should progressively escape the exclusive custody of model context and proprietary runtime state.

That state may live in files, Git, append-only event logs, databases, content-addressed stores, or object storage. What matters is that it be:

Persistent
Explicit
Addressable
Versioned
Inspectable
Validatable
Replayable
Portable

Stigmergy, Physical Externalization, storage media, and concrete protocols occupy different abstraction layers:

Stigmergy
    │
    │  coordination principle
    ▼
Physical Externalization
    │
    │  systems-design principle
    ▼
Filesystem / Git / DB / Object Store / Artifact Graph
    │
    │  implementation media
    ▼
FCoP / tap / PheroPath / project-specific contracts
       concrete protocols and tools

Mature next-generation Agent infrastructure is therefore unlikely to be “pure stigmergy” or “pure workflow.” It will more likely be hybrid:

              ┌─────────────────────────┐
              │  Deterministic Workflow │
              │ policy / routing / auth │
              └────────────┬────────────┘
                           │
             candidate work│
                           ▼
┌───────────────┐   ┌──────────────────────┐
│ LLM Workers   │──▶│ Canonical Artifacts  │
│ probabilistic │   │ schema + provenance  │
└───────────────┘   └──────────┬───────────┘
                               │
                  ┌────────────┼─────────────┐
                  ▼            ▼             ▼
               Git/FS       Database     Object Store
                  │            │             │
                  └────────────┼─────────────┘
                               ▼
                       Validators / CI
                               │
                               ▼
                     Committed State

The most important future research questions are not “which Agent prompt is smartest,” but at least five deeper problems.

First, artifact coordination benchmarks: compare conversation, supervisor, graph workflow, shared artifacts, stigmergy, and hybrids under the same task, model, and compute budget.

Second, portable Agent-state standards: durable state still lacks a minimal cross-runtime fact contract comparable to OpenTelemetry or OCI manifests.

Third, artifact provenance and security: future attack surfaces include forged TASK artifacts, modified front matter, malicious pheromones, replayed stale artifacts, and filename-based routing attacks.

Fourth, namespace economics at scale: large Agent fleets may create millions of attempts, observations, and validation artifacts per day, forcing serious work on compaction, snapshots, content addressing, hot/cold tiers, indexing, and retention.

Fifth, the real boundary of human–Agent isomorphism: Markdown is excellent for human readability, while protobuf or database schemas can reintroduce runtime dependence. A durable artifact ecosystem must find a way to combine a human-readable surface with a machine-verifiable core.

Ultimately, mature Agent infrastructure should not be designed around the assumption that “the model never makes mistakes.”

That goal is unrealistic.

The better goal is:

Prevent mistakes from silently becoming system facts.

Models may misjudge, hallucinate, crash, upgrade, switch vendors, or forget what they said one session earlier.

But why a task entered DONE, which input produced which patch, which test passed, who approved the transition, which worker failed on which version, and which constraint was valid at the time should not depend on whether the model still remembers.

The model proposes possibilities.

Validators judge evidence.

Workflows constrain transitions.

Persistent media preserve facts.

Open protocols keep facts from belonging to any one framework.

That is the Agent engineering worth pursuing after the black-box myth.

And this is why the most durable idea in “physical externalization” is not “Filesystem forever,” but a more fundamental systems principle:

Agents may be probabilistic; coordination may be emergent; but facts that have happened and been accepted by the system must be addressable, verifiable, recoverable, and auditable.

When an Agent system reaches that point, the large language model can finally move from being imagined as the brain of the entire system back to the role it is best and safest at: a powerful but replaceable cognitive execution unit, rather than the sole memory and source of truth for the digital world.

Sources

[1] [24] GitHub - Significant-Gravitas/AutoGPT: AutoGPT is the vision of accessible AI for everyone, to use and to build on. Our mission is to provide the tools, so that you can focus on what matters. · GitHub

https://github.com/Significant-Gravitas/AutoGPT

[2] [5] [39] GitHub - langchain-ai/langgraph: Build resilient agents. · GitHub

https://github.com/langchain-ai/langgraph

[3] [14] EvoGit: Decentralized Code Evolution via Git-Based Multi-Agent Collaboration

https://arxiv.org/abs/2506.02049

[4] [47] Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering

https://arxiv.org/abs/2604.08224

[6] [43] RenameObject - Amazon S3

https://docs.aws.amazon.com/AmazonS3/latest/API/API_RenameObject.html

[7] [10] [38] Lost in the Middle: How Language Models Use Long Contexts

https://arxiv.org/abs/2307.03172

[8] [12] Enabling Next-Gen LLM Applications via Multi-Agent Conversation

https://arxiv.org/html/2308.08155v2

[9] [30] GitHub - Aider-AI/aider: aider is AI pair programming in your terminal · GitHub

https://github.com/Aider-AI/aider

[11] MetaGPT: Meta Programming for a Multi-Agent Collaborative Framework

https://arxiv.org/html/2308.00352v7

[13] ChatDev: Communicative Agents for Software Development

https://arxiv.org/html/2307.07924v5

[15] CooperBench: Why Coding Agents Cannot be Your Teammates Yet

https://arxiv.org/html/2601.13295v1

[16] More Capable, Less Cooperative? When LLMs Fail At Zero-Cost ...

https://arxiv.org/html/2604.07821v2

[17] Coordination as an Architectural Layer for LLM-Based Multi-Agent Systems

https://arxiv.org/html/2605.03310v1

[18] Effective Strategies for Asynchronous Software Engineering Agents

https://arxiv.org/html/2603.21489v2

[19] Multi-Agent Transactive Memory

https://arxiv.org/html/2606.19911v1

[20] Emergent Culture in Minimal LLM Systems

https://arxiv.org/html/2606.30668v1

[21] [45] [48] tap: A File-Based Protocol for Heterogeneous LLM Agent Collaboration

https://arxiv.org/abs/2606.14445

[22] [36] SwarmWorld: Stigmergic technological evolution in societies of language-model agents

https://arxiv.org/abs/2608.26081

[23] Nidus: Externalized Reasoning for AI-Assisted Engineering

https://arxiv.org/html/2604.05080v1

[25] yoheinakajima/babyagi

https://github.com/yoheinakajima/babyagi

[26] GitHub - FoundationAgents/MetaGPT: 🌟 The Multi-Agent Framework: First AI Software Company, Towards Natural Language Programming · GitHub

https://github.com/geekan/MetaGPT

[27] GitHub - microsoft/autogen: A programming framework for agentic AI · GitHub

https://github.com/microsoft/autogen

[28] [40] [44] GitHub - crewAIInc/crewAI: Framework for orchestrating role-playing, autonomous AI agents. By fostering collaborative intelligence, CrewAI empowers agents to work together seamlessly, tackling complex tasks. · GitHub

https://github.com/crewAIInc/crewAI

[29] GitHub - run-llama/workflows-py: event-driven, async-first workflows for AI applications

https://github.com/run-llama/workflows-py

[31] GitHub - OpenHands/OpenHands: AI-Driven Development · GitHub

https://github.com/OpenHands/OpenHands

[32] GitHub - zi-yue-1129/PheroPath: stigmergy-based file pheromones for AI Agents · GitHub

https://github.com/zi-yue-1129/PheroPath

[33] FCoP — A File-based Coordination Protocol for Multi-Agent AI Systems

https://joinwell52-ai.github.io/FCoP/

[34] joinwell52-AI

https://github.com/joinwell52-AI

[35] [46] GitHub - Govcraft/pressure-field-experiment: stigmergy-inspired pressure-field coordination for multi-agent LLM systems · GitHub

https://github.com/Govcraft/pressure-field-experiment

[37] [41] GitHub - joinwell52-AI/FCoP: File-based Coordination Protocol for Multi-Agent AI Systems · GitHub

https://github.com/joinwell52-AI/FCoP

[42] Renaming objects in directory buckets - Amazon Simple Storage Service

https://docs.aws.amazon.com/AmazonS3/latest/userguide/directory-buckets-objects-rename.html

[49] FCoP paper / research record — DOI 10.5281/zenodo.22855630

https://doi.org/10.5281/zenodo.22855630

[50] FCoP v4.0.3 code archive — Zenodo Record 22746175

https://zenodo.org/records/22746175

Chinese Editions: CSDN · Juejin · Zhihu

Research Artifacts: FCoP (Zenodo) · FCoP Repository · Research repository

Filesystem as Protocol: How FCoP Uses Minimal Markdown for Agent Governance

joinwell52 — Mon, 21 Sep 2026 09:12:17 +0000

In the previous article, we examined the “communication maze” and governance anxiety emerging as multi-Agent systems move into real-world use in 2026. As more and more agents exchange state, tasks, and tool calls through complex JSON, YAML, and black-box APIs, human operators are finding it increasingly difficult to see clearly who owns a piece of work, how far it has progressed, what justifies the next step, and who is responsible when something goes wrong.

As major technology companies and frontier engineering research increasingly emphasize human-readable contracts and process transparency, a practical question follows: how can we implement an Agent governance mechanism that is lightweight, elegant, and capable of industrial-grade enforcement?

This article focuses on an open protocol we designed and incubated ourselves: FCoP (File-based Coordination Protocol). The aim is to see how it challenges the assumption that governance must begin with complex infrastructure, and how ordinary Markdown, directories, and files can be used to establish real constraints over multi-Agent collaboration.

1. Why return to the Unix philosophy of files?

One of the main intellectual influences behind FCoP is the Unix philosophy. Unix does not try to place every capability inside one giant central program. Instead, it favors small tools that each do one thing well, exchange information through simple and stable interfaces, and compose into more complex systems.

FCoP brings the same idea into multi-Agent collaboration. In the protocol, TASK expresses work to be done, REPORT represents a deliverable, ISSUE records unresolved problems, and REVIEW records inspection and decision. Markdown remains directly readable by humans while also being machine-parseable through structured fields.

So “filesystem as protocol” is not a mechanical restatement of “everything is a file.” What FCoP inherits from Unix is more important: textual interfaces, small and explicit responsibilities, and composable tools.

As Agent systems become more complex, a common instinct is to make governance systems equally complex by adding databases, state services, message queues, event buses, and workflow engines. FCoP asks a different question: how many facts are actually indispensable for reliable work handoff across multiple agents?

The next responsible actor usually needs to know only a limited set of things: what the task is, who currently owns it, which execution attempt is active, what has been delivered, who reviewed that delivery, and whether that review is still applicable to the current work. If those facts can be stored stably, reread later, and verified by software, governance does not necessarily have to begin with a large centralized system.

FCoP therefore does not try to reinvent a complex workflow engine. Instead, it compresses the most important responsibility relationships in multi-Agent work into a small set of stable facts, then lets the protocol control when those facts are allowed to change.

At Build 2026, Microsoft introduced ASSERT and the Agent Control Specification (ACS), which similarly separate “finding a problem” from “exerting control along the execution path”: evaluation discovers defects first, while controls are then applied at key points such as input, state, tool execution, and output. ASSERT and ACS technical overview

FCoP is not an implementation of ACS, and the two systems differ in architecture and scope. But they reflect a similar engineering principle: governance cannot exist only after the fact, and it cannot be reduced to logs; it must be able to constrain work at the moment the work actually moves forward.

FCoP also does not claim that filesystems should replace all infrastructure. Cross-machine high-throughput messaging, complex queries, large event streams, distributed transactions, and weakly consistent network environments are still better served by databases, message queues, or specialized coordination systems. FCoP addresses a more foundational problem inside a project workspace: how can tasks, deliverables, reviews, and responsibility relationships remain directly understandable to humans while also being re-verifiable by machines?

2. FCoP stores work facts, not conversations

FCoP does not try to preserve every Agent conversation, and it does not need to retain every internal reasoning trace. Its concern is narrower: when work moves from one role to another, which confirmed facts does the next responsible actor actually need?

The core protocol records can be summarized as four types:

File	What it stores
TASK	Work content, delegation relationships, and lifecycle
REPORT	A deliverable produced by one execution attempt
ISSUE	An unresolved problem discovered during execution
REVIEW	A review and decision about a specific deliverable

A simplified multi-Agent software team might look like this:

ADMIN ⇄ PM                Requirements and management decisions
          │
          ▼
      FCoP protocol layer
      ├─ PM: creates and manages TASKs, reads deliverables and reviews
      ├─ DEV: claims TASKs and produces REPORT / ISSUE
      └─ QA : reads TASK and REPORT, then produces REVIEW

The roles above are only an example of one collaboration model; they are not a fixed role set defined by FCoP Core.

The key change is not simply replacing chat with Markdown. It is separating a role’s own runtime context from the formal work facts the project depends on collectively.

A PM does not need to enter a DEV conversation and read dozens of chat turns, and DEV does not need to verbally retell the entire implementation process to QA after the work is finished. What is handed off is not the previous conversation but the TASK, REPORT, ISSUE, and REVIEW records that have entered the protocol layer.

An Agent runtime can end, a model can be replaced, and a conversation can disappear entirely, while the work itself remains. A later responsible actor can reread the protocol files and still determine where the task came from, what stage it reached, what was delivered, and what reviews actually occurred.

This is one of the most important differences between FCoP and many “multi-Agent chat frameworks”: collaboration facts do not depend on a conversation continuing to exist.

Figure 1 — FCoP 4.0 Protocol Architecture. FCoP is accessed through Agent Host environments, protocol tools expose standardized capabilities, FCoP Core performs protocol checks and constraints, and confirmed facts are persisted as files and lifecycle state.

3. The five buckets are protocol state, not directory convention

One of the easiest misunderstandings about FCoP is to treat inbox, active, review, done, and archive as ordinary folders used only to organize files.

In fact, they represent the lifecycle state of a TASK.

_lifecycle/
├─ inbox/
├─ active/
├─ review/
├─ done/
└─ archive/

inbox means that a task has entered the system but has not yet been claimed. active means that the task is being executed. review means that the current execution has produced a deliverable and is waiting for review. done means that the task has satisfied its completion conditions. archive stores finished tasks that have left the current working view.

A typical TASK lifecycle can therefore be represented as:

inbox → active → review → done → archive
           ↑         │
           └─────────┘
               rework

The important idea is not the existence of five directories but the fact that state is materialized by location. The lifecycle location of a TASK corresponds to its protocol stage, so the system does not need to rely on an Agent’s own claim that “I am at this step now.”

But this does not mean that an Agent may move lifecycle files directly. Quite the opposite: if an Agent could move a TASK from active to done simply because it believed the work was complete, the five buckets would be only a directory convention rather than a governance protocol.

FCoP adds a stricter rule: an Agent may propose an action, but it may not directly change lifecycle facts.

An executor may request to claim a task or submit a deliverable; a reviewer may submit a REVIEW or approve a result. Whether those actions are sufficient to move the TASK to the next stage must be re-validated by FCoP against the current state, the current execution attempt, the deliverable, the review, and the relevant authorization relationships. Only when the required conditions hold does the protocol layer execute the lifecycle transition and materialize the new state in the filesystem.

The process can be summarized as:

Agent proposes a protocol action
        ↓
FCoP checks current facts and protocol conditions
        ↓
      allow / reject
        ↓
if allowed, execute lifecycle transition
        ↓
new file location becomes the new observable state

So “filesystem as protocol” does not mean that the filesystem itself makes decisions. It means that the filesystem carries and materializes protocol facts, while FCoP determines which fact changes are allowed to become valid.

This is what makes FCoP a protocol rather than merely a Markdown format.

4. The five buckets answer “where”; attempt answers “which execution”

The five buckets tell the system which lifecycle stage a TASK is in, but they do not answer another important question: if the same task is sent back and executed again, which execution attempt does the current deliverable belong to?

That is the purpose of attempt_id.

When a TASK begins a new execution, the system establishes an attempt_id for that attempt. If the task is rejected during review and returns to execution, a new attempt is created.

task_id and attempt_id therefore answer two different questions:

task_id: Is this the same piece of work?
attempt_id: Is this the same execution attempt?

For example:

TASK-A
│
├─ attempt-1
│    ├─ REPORT-1
│    └─ REVIEW-1
│
└─ attempt-2
     └─ REPORT-2

TASK-A remains the same task, but attempt-1 and attempt-2 are two different executions.

This distinction matters because real work rarely passes on the first try. The first implementation may contain problems; the second attempt may produce a new REPORT; a third round of rework may follow. The task identity remains unchanged, but the facts produced by each execution are different.

If the system knows only task_id, it can easily apply the first attempt’s REPORT, test results, or REVIEW to the second attempt by mistake. FCoP separates the attempts with attempt_id, so the first attempt’s REPORT and REVIEW remain valid historical evidence without automatically becoming evidence for the second attempt.

The division of responsibility is simple: the five buckets tell us where the task is; attempt tells us which execution of the task we are looking at.

5. Separate identity, relationships, and state

File naming is also a useful way to understand how FCoP has evolved.

Earlier designs placed more human-readable routing information directly in filenames, including sender and recipient:

TASK-...-ADMIN-to-PM.md
TASK-...-PM-to-DEV.md
REPORT-...-DEV-to-PM-....md

This is intuitive because a person opening a directory can often tell who sent a piece of work to whom without reading the file. But it also means that record identity, role routing, and business semantics gradually accumulate inside one filename. If the team’s role model changes, the naming rules have to change with it, and the protocol becomes more tightly coupled to one organizational structure.

The design direction in FCoP 4.x is to separate those responsibilities. Conceptually, record files can be understood as:

TASK-<stable-id>.md
REPORT-<stable-id>.md
REVIEW-<stable-id>.md

Here <stable-id> illustrates the idea of stable identity rather than enumerating every exact filename rule of a specific release. The filename primarily answers “what type of record is this, and which record is it?” Sender, recipient, related task, and execution attempt are expressed through structured fields instead.

For example, a REPORT may include:

sender: DEV
recipient: PM
subject_ref: TASK-...
attempt_id: urn:uuid:...

A PM therefore does not need to infer relevance from a DEV-to-PM filename string. The protocol relationships can directly express who created the record, who receives it, which task it belongs to, and which execution attempt produced it.

The design can be summarized in one sentence: the filename carries identity, structured fields carry relationships and routing, and the lifecycle path carries state.

The same principle extends to operations. Tool calls in Agent systems may be resubmitted because of timeouts. If the system cannot determine whether a request is “the same operation as before,” an ordinary retry may create a second piece of work.

FCoP therefore uses operation_id to identify an operation. The same operation_id with identical content returns the existing result, while reusing the same operation_id with changed content is rejected.

In our experiment, the same creation request was submitted 25 times and produced only one TASK. When the body was changed while keeping the same operation_id, the system returned:

OPERATION_ID_CONFLICT

The underlying principle remains the same: establish stable identity first, then build relationships and state constraints around that identity. A network retry should not silently become another task.

6. YAML expresses responsibility relationships, not merely configuration

FCoP uses Markdown for human-readable content and YAML frontmatter for protocol relationships. The core structure of a REPORT can look like this:

---
protocol: fcop
version: 4
type: REPORT
report_id: REPORT-...
workspace_id: urn:uuid:...
sender: DEV
recipient: PM
subject_ref: TASK-...
attempt_id: urn:uuid:...
report_kind: final
result: done
references: []
---

Deliverable after the second round of rework.

At first glance, this looks like ordinary structured Markdown. But the important point is not the number of fields; it is the responsibility relationships those fields establish.

report_id identifies the deliverable itself. subject_ref identifies the TASK it belongs to. attempt_id identifies which execution produced it. sender and recipient express where the record came from and who it is handed to.

REVIEW follows the same logic. A REVIEW cannot consist only of the word approved, because the protocol needs to know not merely whether the word “approved” exists, but who approved what, for which task, in which execution attempt, against which REPORT, and whether that approval is still applicable to the current state change.

A REVIEW must therefore be related explicitly to the appropriate TASK, attempt, and reviewed REPORT, while authorization itself also has a defined scope. In this way, approved is no longer an isolated natural-language statement but a work fact whose applicability can be checked again.

That is why, in FCoP, “this task passed review before” and “the current deliverable has passed review” are not the same statement.

7. The protocol matters most when it prevents an invalid state from becoming valid

The value of FCoP is not merely that the correct workflow can proceed smoothly. More importantly, when the required conditions do not hold, an incorrect action cannot become a system fact simply because an Agent believes it should.

An Agent may say “I am done,” and it may request that a task move into review, but the protocol does not accept the transition merely because the natural-language statement exists. FCoP rechecks the current TASK, attempt, REPORT, REVIEW, and authorization relationships. The lifecycle moves forward only when the current facts support the requested transition.

For example, an executor may claim a task through an operation such as:

project.transition(
    task_id=task_id,
    from_stage="inbox",
    to_stage="active",
    tool="claim_task",
    actor=actor,
)

The important part is not these few lines of code but whether the preconditions are still true at the moment of execution.

If one process has already claimed the TASK and moved it from inbox to active, another concurrent process that attempts the same claim will cause FCoP to reread the current facts, discover that the original inbox → active precondition no longer exists, and reject the second transition.

Likewise, if the current attempt has not yet produced a REPORT, the task cannot move into review out of thin air. If a REVIEW belongs to a previous attempt’s REPORT, it cannot approve the current attempt’s new deliverable.

This is the purpose of the protocol: an Agent may propose a judgment or request, but it may not turn its own judgment directly into a system fact.

8. Experiment: what can these Markdown and directory constraints actually stop?

To verify that these constraints are executable rather than merely descriptive, we ran several local experiments against FCoP 4.0.3. The test environment used a Windows local filesystem, Python 3.10.11, and fcop==4.0.3.

The main results were:

Check	Result
10 rounds, 4 processes claiming concurrently in each round	10 successes, 30 `INVALID_TRANSITION`
Submit for review without a current REPORT	`REPORT_REQUIRED`
Use a REPORT from another execution attempt	`ATTEMPT_MISMATCH`
Reuse an old REVIEW to approve a new deliverable after rework	`AUTHORIZATION_INVALID`

The first test focused on concurrent claiming. In each round, four processes competed for the same TASK. Across ten rounds, this produced forty claim attempts. Exactly one process succeeded in each round; the other three received INVALID_TRANSITION. The final result was ten successes and thirty rejections, with no case in which the same TASK was successfully claimed by multiple executors.

The second and third tests focused on evidence boundaries. If the current attempt has not produced a REPORT, the system does not allow submission for review and instead returns REPORT_REQUIRED. If a REPORT from another attempt is used as the current deliverable, the system returns ATTEMPT_MISMATCH.

The fourth test shows the governance meaning of rework most clearly.

Suppose the first execution produces:

TASK-A
  └─ attempt-1
       └─ REPORT-1
            └─ REVIEW-1

After QA reviews REPORT-1, a problem is found and the task is returned for rework. A new execution attempt is created:

TASK-A
  └─ attempt-2
       └─ REPORT-2

TASK-A is still the same task, but the execution has changed from attempt-1 to attempt-2, and the deliverable has changed from REPORT-1 to REPORT-2.

The old REVIEW-1 remains a real historical record, but it proves only that REPORT-1 from the first attempt was reviewed. It does not prove that REPORT-2 from the second attempt has been reviewed.

If the system tries to use the old REVIEW to advance the new deliverable, FCoP returns:

AUTHORIZATION_INVALID

The rule protects a very simple responsibility boundary: an old review is a real historical fact, but it is not authorization for the current deliverable.

Files can of course be read, and a body may contain the words “done” or “approved,” but those words do not automatically advance the lifecycle. What determines whether the work may continue is whether the current state, current execution, current deliverable, and current authorization are consistent.

9. What does “filesystem as protocol” actually mean?

At this point, the phrase “filesystem as protocol” can be understood more precisely.

It does not mean saving every conversation as Markdown. It does not mean allowing Agents to move files between directories on their own. And it does not mean that the filesystem itself makes business decisions.

FCoP becomes a protocol because several constraints coexist: records have stable identity, structured fields preserve explicit relationships, the five buckets materialize lifecycle state, attempts separate repeated executions, and every state change must pass protocol actions and condition checks.

In other words, Markdown stores work content, structured fields store responsibility relationships, file paths materialize lifecycle state, and the FCoP protocol determines when those state changes are allowed to occur.

The “minimalism” of FCoP does not mean the absence of rules, nor does it weaken governance requirements. Instead, it places complexity where it actually belongs: identity, relationships, execution attempts, and transition boundaries, rather than concentrating every concern inside one centralized workflow engine.

That is why FCoP can rely on ordinary files and Markdown while still establishing real governance constraints.

10. What FCoP solves — and what it does not

FCoP does not replace testing. Nor can it infer that tests were actually executed simply because a REPORT says “all tests passed.” It does not replace QA, human review, or independent evaluation, and it does not automatically determine whether a technical claim is true.

Content-level truth still requires testing systems, code review, QA, independent evaluation, or other evidence mechanisms.

FCoP addresses a more basic layer that must be correct before those judgments can be trusted: which task are we dealing with, which execution produced this deliverable, which REPORT did the current REVIEW actually examine, and does this authorization still apply to the current work?

These questions may not sound “intelligent.” In fact, they are deliberately conventional. But if these basic relationships are uncertain, even the strongest model, Agent, or workflow system can continue operating on the wrong object.

11. Conclusion: the value of a protocol is that an Agent cannot define system facts by itself

Agent systems are becoming more complex very quickly. There are more models, more tools, more roles, more autonomous execution, and deeper cross-system integration. It is easy to assume that governing such systems therefore requires an equally complex centralized infrastructure.

FCoP proposes another answer.

It does not introduce a new database or a large orchestration language. Instead, it builds on things developers have used for decades: files, directories, Markdown, and a small number of stable structural relationships.

Filenames carry identity, structured fields carry relationships and routing, the five buckets materialize lifecycle state, attempts separate repeated executions, REPORT and REVIEW preserve delivery and review evidence, and protocol gates determine when those facts are sufficient to support the next transition.

Our experiments show that, under the tested conditions of a Windows local filesystem, Python 3.10.11, and fcop==4.0.3, constraints around identity, concurrent claiming, execution attempts, and authorization scope can be reproduced consistently. These results are not performance claims about cross-machine coordination, network filesystems, or large-scale throughput. But they demonstrate one important point: industrial-grade enforceability does not necessarily require industrial-grade complexity.

For multi-Agent teams, reliable collaboration may begin not with sending more messages between Agents, but with ensuring that no Agent can turn “I think this is finished” directly into “the system says this is finished.”

An Agent may propose an action; FCoP validates it. Once the protocol accepts the transition, the filesystem preserves the new fact.

That may be the most important meaning of “filesystem as protocol”: the work may be executed by Agents, but the facts cannot be declared valid by the Agents themselves.

FCoP Paper (Zenodo) · FCoP Protocol and Examples · FCoP on PyPI · FCoP MCP on PyPI · Chinese Edition (CSDN) · Chinese Edition (Juejin) · Research repository

When Multi-Agent Systems Go Out of Control: What Agent Governance Do We Need in 2026?

joinwell52 — Fri, 18 Sep 2026 09:10:14 +0000

In 2026, developers are giving AI more than questions. They are giving it work.

Breaking down requirements, writing code, running tests and reviewing results—steps once connected by people are increasingly assigned to different agents. A Planner develops a plan, a Coder implements it, and a Reviewer examines the delivery. That is the attraction of a digital team: a person sets the objective, multiple agents divide the work, and progress continues.

But delegating the tasks does not make management disappear. Scope, progress, disagreements and acceptance conditions once held in people's heads now need to remain clear across independently acting roles.

Why did an agent suddenly change the scope? Which of two conflicting reports should we trust? When an executor says “done,” has anyone actually checked? These questions lead to one concern: once work is delegated to AI, who retains control of its boundaries and progress?

Tool calls can become more frequent while collaboration becomes harder to explain. That gap is where anxiety about multi-agent governance begins.

1. Beneath the Momentum: Communication Confusion and Governance Anxiety in 2026

Consider a collaboration chain: a planner turns an ambiguous objective into tasks, an executor modifies code according to its interpretation, and a reviewer reads only the execution summary before declaring a pass. Every role has produced a response, yet the work may have drifted away from the original assignment. Finding the divergence requires tracing the instructions each participant received, the actions taken and the material behind each judgment.

This kind of loss of control rarely starts dramatically. It hides in seemingly smooth handoffs:

The message arrived, but the evidence did not. The next participant knows that someone said the work was finished, but not what was checked or missed.
Tools have permissions, but the assignment lacks boundaries. Permission to inspect a project is interpreted as permission to modify it. A limited authorization expands along the task chain.
The indicator turned green, but responsibility remains unresolved. Code written, report submitted, tests passed and formal acceptance collapse into a single “done.”

Receiving a message does not mean the supporting evidence is complete. The roles illustrate one collaboration pattern.

Governance therefore starts with a straightforward requirement: make both “what happened” and “what justifies continuing” possible to establish.

In its September 2026 responsible AI statement, Microsoft moves governance further into system operation: organizations need to see what agents are doing, test their behavior and intervene when necessary. Microsoft responsible AI statement

That direction has concrete engineering expressions. ASSERT translates organizational policies into evaluation scenarios. The Agent Control Specification (ACS) defines controls at key points including input, model, state, tool execution and output. Microsoft describes a cycle of identifying problems through evaluation, configuring controls and evaluating the improvement. ASSERT and ACS technical explanation

A fix in the OpenAI Agents SDK makes the issue concrete. In September 2026, contributor jbeckwith-oai submitted a fix describing how, when an output-checking program threw an exception without reaching a verdict, the run could fail while the unvetted answer was still saved to the session and sent back to the model in the next turn. The fix routes that output through the path that prevents persistence, keeping it out of subsequent context. OpenAI Agents JS #1938

A run ending does not mean everything it leaves behind is qualified to become evidence for subsequent work. In multi-agent collaboration, we must ask whether handed-off content carries its checking status, and whether the recipient can distinguish a verified conclusion from output whose checks never completed.

Further questions follow: whose delivery was checked, and which attempt produced it? Which result does an approval cover? After someone else takes over, can the original basis still be inspected?

The problem has grown beyond getting agents to communicate. It is now how to leave a basis for the work that later participants can inspect and use.

2. Why Do Traditional Enterprise Governance Frameworks Still Need an Agent Layer?

Enterprise software already has access control, audit logs, database transactions and service gateways. Why does organizing agent work require additional governance rules?

Because technical operations and business assignments are connected by relationships that must be explicitly represented. A gateway can check whether a request carries credentials without knowing whether the action belongs to the current assignment. A database can store task state, but business rules must specify who may change it and what evidence must exist first.

When an agent adapts its execution path to intermediate results, those questions recur. A successful tool call establishes that an action ran. Determining whether the overall process is valid requires placing that action back into its task, role and authorization relationships.

The first gap is the distance between technical permission and responsibility for the work.

Being able to write a file is a capability. Being entitled to accept a delivery is a responsibility. Executors, reviewers and approvers should not acquire identical decision rights merely because they use the same tools.

Without explicit task relationships, teams must reconstruct events from logs: who requested this step, whether a modification exceeded the assignment, and why work advanced without review. The more autonomous the system and the longer the chain, the harder that reconstruction becomes.

The second gap is how a human decision takes effect after intervention.

A stop button addresses only part of the problem. The system must also know which work has been submitted, which actions have not yet run, which results should be preserved and where execution should resume.

Human approval raises similar questions. For delivery acceptance, approval needs to refer to a specific delivery and its scope. If the executor subsequently changes the content, does the original approval still cover the current result?

Without that relationship, “someone clicked approve” establishes that an event occurred, but provides a weak basis for later work.

Both gaps point to the same issue: a system must understand what an action means within an assignment, not merely that it happened. Generating a report does not establish formal delivery. An approval cannot remain valid independently of its object.

For long-running, continuous, multi-role work, these relationships cannot depend indefinitely on chat history and retrospective explanation. Tasks need identities, deliveries need supporting material, reviews need accountable roles, and key transitions need explicit conditions.

The next question is therefore: how should these working relationships be preserved so that later participants can read, check and use them?

3. Industry and Frontier Engineering: Why Are Text and File Contracts Worth Attention?

Following that line of thought, human-readable work contracts become valuable.

GitHub Agentic Workflows lets developers describe work in Markdown with YAML frontmatter, compile it into an execution environment, and apply permissions and controls over permitted write operations. The work definition can be read directly while execution mechanisms enforce constraints. GitHub documentation

Anthropic's engineering article on its multi-agent research system describes a different handoff practice: saving some artifacts externally and returning references to the coordinating agent, reducing information loss from repeatedly passing results through intermediaries. Anthropic engineering article

The two approaches operate at different levels but touch a shared need: work must leave material that the next participant can inspect again.

Choosing Markdown does not require rejecting other structures. In its work on long-running agents, Anthropic used JSON for a feature list, together with progress material and tests supporting subsequent sessions. Long-running agent engineering

The important question is whether work records can outlive a session and be read, referenced and checked again—not whether the medium is Markdown, YAML, JSON or a database. Sessions end, models change and executors are replaced. The reason a task exists, its current delivery, who checked it and on what basis should survive those changes.

That addresses preservation. Governance requires a further step.

Material used only for retrospective review supports recording and traceability. Material that also determines whether work may proceed starts to participate in governance. Whether a task may advance, whether an approval remains applicable and whether an old check covers a new delivery cannot depend solely on remembering what someone previously said.

A more important question follows: should governance rules depend on agents remembering them, or become explicit rules shared by all participants?

4. Why Does Governance Ultimately Lead Toward a Protocol?

Context reminders and prompt instructions alone struggle to preserve governance rules across long tasks and repeated handoffs. Context grows, is compressed and is truncated. Sessions end, models change and different roles interpret the same requirement differently. Prompts remain important, but they primarily tell an individual executor what it should do.

Governance must answer another question: regardless of which model executes today or which agent takes over tomorrow, under what conditions may the work continue?

A rule that depends solely on model recall resembles an instruction. When it is explicit, shared by participants and checked by the system at critical operations, it starts to become part of governance.

That is why governance needs a protocol.

A protocol is more than a longer prompt, and it need not encode every business judgment. It defines the working rules: what constitutes a task and a formal delivery, which result a review covers, who may make which decisions, and which missing conditions require the system to refuse further progress.

Organizations use procedures, rules and contracts for a related reason: important obligations cannot depend solely on each participant remembering them. Extending execution from people to models makes that concern more pronounced.

A workflow tells an agent where to go next; a protocol establishes what entitles it to take that step.

These responsibilities can coexist in one system: the process organizes execution, while the protocol specifies the conditions participants must satisfy to advance.

FCoP—the File-based Coordination Protocol—starts with this question.

It does not prescribe how an agent thinks or replace a reviewer's judgment about code quality. It specifies how work is established: tasks need persistent identities, deliveries must relate to particular tasks and execution attempts, reviews must identify their subjects, and transitions requiring authorization need the corresponding basis. A statement that the work is “done” cannot substitute for missing conditions.

FCoP uses ordinary files to hold these records. TASK, REPORT, ISSUE and REVIEW represent tasks, delivery reports, problems and reviews. People can open them; agents can read and inspect them. Files preserve records and evidence, while the protocol defines their relationships and the conditions under which they support further action.

The four record types are related records, not sequential lifecycle stages. Allowing an operation does not establish that its deliverable is correct.

This apparently simple design immediately faces difficult questions.

If network retries send the same creation request 25 times, should there be 25 tasks or just one? If four processes claim the same task simultaneously, can all four believe they succeeded? If a reviewer checks one delivery and the executor subsequently produces a new result, does the old REVIEW still apply? Can work advance without a REPORT, a required review or authorization?

There is an even less intuitive question: if agents never chat with one another and exchange work records only through TASK, REPORT, ISSUE and REVIEW, can they still form a team capable of sustained collaboration?

That is what makes FCoP worth investigating. The interesting question is whether rules expressed through ordinary files can actually constrain multi-agent work.

5. What Matters Is Whether It Can Hold These Boundaries

FCoP proposes a deceptively simple answer: preserve multi-agent work records and collaboration rules in ordinary files, and check those rules at critical operations.

Retries, competing claims, changed deliveries and missing evidence are more revealing tests than a smooth demonstration. Does the system reuse an existing result when it should? Does it reject an invalid request? Can it stop when conditions are missing? Those behaviors establish what the protocol actually constrains.

If these boundaries hold, “files as protocol” becomes more than a design slogan. It may mean that the order governing multi-agent work need not remain hidden inside a model, a prompt or a large central system.

FCoP protocol and examples · Research repository

The quota is exhausted. Why is the agent still retrying?

joinwell52 — Thu, 17 Sep 2026 03:56:43 +0000

The quota is exhausted. Why is the agent still retrying?

The agent stops. Its provider says the quota is exhausted and gives a reset time for later that evening.

Then the task retries. The counter rises; the work goes nowhere. Which part of the message did the system fail to understand?

One possibility is that the provider supplied a cause, while the program recorded only “this step failed.” “The warehouse is closed today” became “delivery failed,” so another delivery was scheduled.

Where did the cause get lost?

The source is Paperclip #13549, by electrumnz. Paperclip coordinates ongoing AI work, including recovery after failures.

The author reported 320 quota-related terminal runs in a production review, 186 carrying retry links, while quota reasons were missing. That is upstream evidence; we did not access the production data. It caught our attention because trying again may help a temporary network failure, while repeatedly trying before quota resets may achieve nothing.

To choose a next step, the program must first identify the cause. The patch adds a previously missed entry point: when a message arrives under a failed-turn error code, the classifier also checks it for quota information.

The question is therefore not just whether the provider explained the failure. Did that explanation reach the code responsible for producing a waiting time?

Send the same sentence through again

We extracted the original classification code and parsing helpers from both revisions and supplied the same nine inputs. One described exhausted quota and specified when it would reset.

Input	Before	Candidate
Quota message with a reset time, through the failed-turn entry point	No classification	Quota recognized; reset time calculated from the message
Quota message without a reset time	No classification	Quota recognized; default one-hour wait
Ordinary socket failure	No classification	Still no classification
Missing key through the existing adapter-failure entry point	Configuration incomplete	Still configuration incomplete

Both of the first two rows produce a time, but for different reasons. One comes from the provider's message; the other is a fallback used when information is missing.

That distinction matters to someone waiting. “Try again at this time” can sound like a promise that service will be available. A default one-hour delay says when the program proposes to try again; it makes no such promise about the provider.

Figure 1. Source: author illustration from the two original classifiers. Exact timestamps and timezone conversion remain in the experimental supplement.

This verifies what the classifier returns. Whether the program arranging the next execution actually waits accordingly needs a further test. The table alone cannot establish that the complete retry problem is solved.

A keyword can appear in a denial

We deliberately supplied this sentence:

No quota exceeded. Socket failed.

The candidate still classified it as a quota problem and returned the default one-hour wait.

This was a constructed counterexample; we have no evidence that a real provider sends that wording. It demonstrates a limit of keyword matching: recognizing a word does not necessarily establish what the sentence means.

Another input supplied an invalid timezone and also triggered the fallback. An equally precise-looking time can therefore come from successful parsing or a backup rule. Preserving that distinction helps explain why the program waits as it does.

A timestamp needs an explanation

A useful next direction is for provider adapters to pass an explicit cause and reset time, reducing reliance on prose. When inference or fallback is needed, its basis should remain available. That is a design direction; this experiment tested only the classifiers.

Users can help examine the next part of the chain. Save the original message and time, then record whether retries keep accumulating and whether work resumes when expected. Those observations help connect “cause recognized” to “execution actually waited.”

When a tool says “wait until this time,” can it also tell you whether the provider supplied that time or the program estimated it?

Revisions and experimental boundary

Original detailed comparison

The experiment clock was September 16, 2026, 04:50 UTC. The message specified 21:20 Pacific/Auckland, parsed as 09:20 UTC. Without a reset time, the one-hour fallback yielded 05:50 UTC. The PR was open at our source read; that timestamped status does not claim it remains unchanged.

The newly included entry point is acpx_turn_failed. The output field parsedResetTime distinguishes a parsed reset from a fallback. “No classification” means this function returned null; it does not establish that all downstream handling immediately retries.

Input	Before	Candidate
Quota message through the failed-turn entry point	No classification	Provider quota; retry at 09:20 UTC
Quota message without a reset time	No classification	Provider quota; retry at 05:50 UTC
Ordinary socket failure	No classification	Still no classification
Missing key through the existing adapter-failure entry point	Configuration incomplete	Still configuration incomplete

Base: d0b67bfe71277f5a5ad21c7a7b6cb7af09e2ccca. Candidate: 688c994a95d6c447816c50b14e30745d8ea9e855. Checked source anchors extract the original classifier block and its original parsing helpers. Nine inputs across two versions produce 18 observations, not 18 live provider calls.

Additional inputs cover a structured retryNotBefore value yielding 12:00 UTC, an unknown error code, an invalid timezone, and missing-key messages entering through different error codes. The negated sentence is deliberately synthetic.

We did not run the recovery scheduler, database scan, production account or model. Results and reproduction scripts. The experiment does not establish the same error path or quota-retry defect in CodeFlowMu.

Original article · 中文版

Research repository

No reply. Will retrying launch a second AI agent?

joinwell52 — Thu, 17 Sep 2026 03:53:16 +0000

No reply. Will retrying launch a second AI agent?

You tap “Start agent” on your phone. A few seconds pass. Nothing answers.

Should you tap again? If the first request never arrived, that seems sensible. If the computer already began acting but its reply disappeared, another tap could create a second job.

Imagine two agents modifying separate copies of the files, leaving you to choose which work to keep. Duplicate work may also consume additional resources. These are possible consequences, not incidents observed in our experiment. They explain why the silent click matters: no reply is not evidence that nothing happened.

Look up the original operation

The inspiration is Orca #21106, by brennanb2025. Orca connects remote devices, such as phones, with computers running AI agents. This change saves launch records to a file so a retry can recover an existing result.

We were interested because starting an agent may also create a workspace and a session. Repeated words can be ignored; two jobs may keep producing consequences.

The mechanism gives each launch an operation number. The first request and its retry use the same number, allowing the computer to look up the original record. In code, this is the operation ID. The check also considers the caller and task contents, so an old number cannot silently stand for a different request.

One distinction carries the design: “I accepted this operation” and “I completed this launch” need separate records.

What does the record contain when a retry arrives?

We ran the original code that stores these records and decides whether a launch may proceed, using real temporary files. We saved a synthetic successful result, discarded the initial response, then returned with the same operation number.

“Successful result” here means the result of launching, such as which workspace was returned. It does not mean the agent finished its subsequent assignment. No real agent ran in our probe.

Controlled situation	What the retry returned
Launch success saved, reply discarded	The same saved result
Operation accepted, final outcome missing	Unknown; another execution was refused
Same number, different task contents	Conflict: this is not the original request

The first row shows why keeping records helps: a lost reply does not erase a saved result. The third shows why numbers cannot be reused indiscriminately. The second is harder to accept—if the operation was recorded, why can it not simply continue?

Figure 1. Source: author illustration from the real-file experiment. Completion here concerns the launch operation; successful outcomes were synthetic.

What happened after acceptance?

Suppose the computer records “I will execute this,” then loses contact before saving an outcome. That record alone allows at least three explanations: work never began, partly happened, or the launch finished without its final result being written.

An accepted operation therefore cannot be translated directly into either “not done” or “successful.” Executing again might duplicate work; declaring success might leave someone waiting for a job that does not exist.

The tested code preserves that uncertainty. Receiving the same number again does not issue another execution permission. We also reopened the store in the same process and could still recover saved results. That is not a test of complete recovery after power loss or a process crash.

At our read, the change had merged on September 17 UTC, but shipped clients did not yet supply the required outer operation ID. The source also explicitly leaves broader recovery outside this change. Our experiment explains how this record layer handles retries; it cannot establish protection for every tap in the mobile product.

An uncertain answer still needs a next step

Preventing a duplicate action matters. The person waiting still needs to decide whether to wait, inspect the work, or seek help.

Our experiment points toward evidence gathering: the original operation number, any still-running task and any resources already created could help reduce guesswork. Those are directions for future design and validation. We did not implement inspection or recovery.

Users can contribute a concrete timeline: what the interface said when the reply was missing, what they did next, and whether they later discovered work already running. That helps distinguish an action that never happened from a reply that never arrived.

When a system can only say “unable to confirm,” what evidence should it provide so a person can confidently choose the next step?

Fixed revision, scope and complete observations

Original detailed comparison

Admission is the check that permits execution to begin. The eight-request result below concerns this layer only. The higher-level handler joins live work; it was not exercised, so seven refusals cannot be read as seven failed user retries.

Controlled situation	Observed result
Success was saved but the reply was discarded	Replayed the same saved result
Store reopened in the same process	Replayed the saved result
Same operation ID, changed task	Rejected as a conflict
Same paired device, rotated bearer token	Replayed the existing result
Operation claimed, final result missing	Refused another execution; outcome stayed unknown
Eight concurrent admissions for one operation	One execution admission; seven unknown refusals

Revision: d60ff2db02bf2b6c6ac4fd39c179c9854409d2a4. We executed the complete original durableAgentSessionRecordStore plus admitAgentLaunchOperation, fingerprint and registry logic with real temporary files and proper-lockfile.

The 11 observations also cover caller partitioning between paired devices, replay of recorded failures, missing paired identity for remote callers, and an expired previously unseen operation ID. Bearer rotation retained the same paired-device identity.

The concurrent test stops at admission; the higher-level live-join handler was not exercised. Reopening occurred within one process. Saved launch outcomes were synthetic: no real workspace, model or mobile call was created.

Results and reproduction scripts. These observations do not establish a duplicate-launch defect or missing idempotency protection in CodeFlowMu.

Original article · 中文版

Research repository

More backups. Less history. How does that happen?

joinwell52 — Thu, 17 Sep 2026 03:53:12 +0000

More backups. Less history. How does that happen?

You open the backup folder and find ten neatly named files. Only when you need yesterday’s settings do you discover that all ten contain today’s version.

Nothing crashed. Every launch faithfully made a backup. That repetition pushed the useful old version out of the retention window.

A full backup list does not necessarily contain a useful history. We tested the original code from an open-source project, asking whether the content from before a change survived.

Why this small change caught our attention

The source is commit ce6457a in anywhere-agents, by Yue Zhao, or yzhao062 on GitHub. The project helps AI coding tools share settings. One Python program merges shared configuration into a local file.

The upstream investigation found that repeatedly merging unchanged settings created identical backups and displaced useful older contents.

This matters to us because automated tools often synchronize on every launch. If each synchronization consumes a backup slot, opening more terminals can shorten recoverable history without changing a single setting.

The patch compares the proposed output with the existing bytes while holding the original file lock. Identical output means no write and no new backup.

Change once, then repeat

In a temporary directory, we started with old settings, merged a new value, then performed 27 identical merges. Both versions ran their original file operations and locking code.

Observation	Before the patch	After the patch
Retained backups	10	1
Content from before the change survives	No	Yes
Backups identical to the current file	10	0
Identical merges change the target modification time	Yes	No

The first merge really did save the old settings in both versions. Before the patch, later merges kept saving the new settings again until the first backup fell outside the ten-file window.

After the patch, unchanged merges stopped consuming that window. Fewer backup files preserved more useful history.

Figure 1. One real change followed by 27 identical merges. Source: author illustration from our local original-code experiment. Each block is a retained backup, not an upstream consumer.

We also ran eight concurrent processes after the initial change. The old version retained nine backups; the patched version retained only the original old content. That supports the lock-protected check under these conditions, not a claim about every filesystem failure.

What does “unchanged” mean?

Next, we deliberately reformatted the target before each merge. Keys and values stayed the same; whitespace changed.

After 12 such rewrites, both versions retained ten backups and had evicted the original old settings. This does not contradict the patch: different formatting means different bytes. The implementation skips byte-identical writes; it does not promise ten semantically distinct revisions.

This was a constructed counterexample, not a reported production incident. It exposes a useful design question: should history preserve every write, or every meaningful change?

Ignoring formatting is not automatically the right answer. Comments, ordering and presentation can themselves be worth restoring. A comparison that is too coarse can discard changes that matter.

Try recovering, not just counting

A practical check is small: change a harmless setting, restart or synchronize repeatedly, then look for the pre-change version. The target is specific: can you recover what existed before that change?

If you have found plenty of backups but not the version you needed, record when the setting changed and how often the tool restarted or synchronized afterward. That helps locate when repeated copies displaced useful history.

For developers, the formatting counterexample suggests another experiment: let two tools alternate writes to the same configuration, then compare retention by write count, distinct content and elapsed time. Each policy may lose something different. Formatting or comments can themselves be worth restoring, so deduplication should not be assumed to be the answer.

The tested improvement is clear: unchanged bytes no longer create backups, preserving the original revision in that scenario. It leaves one larger question: does a backup system promise the last few saves, or the changes a person needs to return to?

Versions, scope and reproduction

The upstream investigation reported 27 consumers and 198 byte-identical backups. Those are upstream observations, not the scale of our experiment.

We ran the complete original Python merge module through its main entry point, using real Windows temporary files and its original locks. Six scenarios ran against both versions, producing 12 observations: identical merges, deliberate formatting rewrites, another real change, first installation, empty-merge refusal, and eight concurrent identical merges.

Base: 91c64c153f2034bf4aa88121cbe546cbf6a22aeb. Patched revision: ce6457a830dead5e05c3a17f685f7ff32575ce20. Except for first installation, scenarios begin with an initial merge. The 27 repeats are not 27 real consumers. We used synthetic settings and did not test power loss or disk corruption.

Results and reproduction scripts. This experiment does not establish the same problem in CodeFlowMu.

Original article · 中文版

Research repository

MIIT Document No. 209 Explained: Agent Software and the Transformation of the Software Industry

joinwell52 — Wed, 16 Sep 2026 05:19:05 +0000

On September 11, 2026, China's Ministry of Industry and Information Technology (MIIT) published the Implementation Plan for the “AI Plus Software” Special Action. Numbered Gong Xin Bu Xin Fa [2026] No. 209 and dated September 2, the document was issued to industry and information technology authorities in all provinces, autonomous regions, municipalities and the Xinjiang Production and Construction Corps, asking them to implement it in light of local conditions.

The title might suggest a simple call for software companies to use more AI. But the eight-page plan and its 19 tasks address much more than AI-assisted coding.

The document tackles three fundamental questions for the software industry.

First, how will software be produced?

Second, what will software itself become?

Third, when software starts acting continuously as an agent, who will provide the execution frameworks, skills, markets, standards, security and boundaries of responsibility?

Document No. 209 therefore matters for more than adding another “AI Plus” policy. China is beginning to organize intelligent programming, agent software and intelligent services as new growth drivers for the software industry. Agents, previously often grouped together with large models, chatbots and automation tools, now sit within a complete software value chain: development tools, execution frameworks, software products, skill packages, application marketplaces, delivery services, and standards for identity, interfaces, behavior and security.

Agents are moving from a model feature toward a distinct form of software.

Understanding Document No. 209 in Six Terms

Intelligent programming — Transform software production
Intelligent companions — Upgrade existing software
Agent software — Develop new product forms
Skills — Package specialist capabilities
Intelligent services — Deliver value continuously
Verifiable behavior — Inspect execution and outcomes

I. Beyond Document No. 414: Adding Products and Infrastructure

To understand Document No. 209, it helps to place it in the sequence of policies released in 2026, without treating the documents as interchangeable.

Document No. 414, published on August 31, organizes a resource pool, service teams, real use cases, delivery arrangements and ongoing evaluation around AI application service providers. Its question is: who brings AI into enterprises, and who takes responsibility for consulting, implementation, operations and security governance?

The Artificial Intelligence SME Entrepreneurship Support Plan (2026–2028), published on September 4, brings AI-native firms, agent developers, open-source contributors, “one-person companies” and highly capable individual entrepreneurs into the scope of startup support. Its question is: who starts new AI businesses, and how will the computing, data, use cases, capital and services they need become available?

We analyzed those documents in MIIT Document No. 414 Explained: From Model Supply to Application Delivery and MIIT's AI SME Entrepreneurship Support Plan Explained: An AI Startup Ecosystem Is Taking Shape.

Document No. 209 addresses a third question:

What software will these entrepreneurs and service providers actually produce, run and deliver?

It takes policy further inside the software industry. From production tools, technical foundations, product forms and service models to open source, computing, data, standards, talent and security, it offers a more complete plan for building the industry.

The three documents have distinct roles:

Document	Main subject	Central question
Document No. 414	AI application service providers	Who handles consulting, integration, delivery, operations and governance?
Entrepreneurship Support Plan	AI SMEs and entrepreneurs	Who starts businesses, and how do they obtain computing, data, use cases and capital?
Document No. 209	Software and information technology services	How is next-generation software produced, how does it run, and what industrial foundations does it need?

If Document No. 414 organizes the delivery teams and the entrepreneurship plan cultivates new companies, Document No. 209 defines the software industry system they will help build.

Figure 1. The three policies address delivery providers, startup support and the software industry: distinct but complementary roles. Source: Relevant MIIT policy documents; compiled by the author.

II. Why “AI Plus Software” Means More Than Adding AI to Software

The opening of the document identifies three things AI is changing: development methods, product forms and service models.

Each represents a different transformation.

The first transformation: how software is produced

AI will no longer be merely a completion tool used while a programmer writes a piece of code. It will participate throughout a project: understanding requirements, designing architecture, coding, testing, checking security, deployment, operations and ongoing changes.

The plan therefore calls for agent-driven intelligent programming tools, stronger project-level autonomous development across the full process, and deeper integration with code hosting platforms, cloud services and open-source communities. The relevant unit is no longer how quickly a function can be written, but whether an entire software project can be completed more efficiently and reliably.

This also explains the call for intelligent upgrading within software companies. Genuine upgrading means more than installing a chat plugin for every programmer. It requires redesigning development processes, quality control, security checks and collaboration, with results assessed through code quality, development effectiveness and other practical outcomes.

The second transformation: what a software product is

Traditional software mainly waits for users to click menus, fill in forms and issue commands. Agent software can receive goals, understand its environment, select tools, execute successive steps and adjust subsequent actions based on results.

The document therefore treats agent software as a new product form in its own right, rather than discussing only AI features added to existing software. It covers capabilities embedded in operating systems, databases, industrial software and devices, as well as general-purpose agents, specialist industry agents and industrial agents.

This raises the agent from an interface feature to a software product category.

The third transformation: how software services work

Traditional software services tend to revolve around licenses, implementation projects and maintenance. Intelligent software services may instead become a continuously operating service chain: models keep changing, knowledge is updated, agents keep executing, permissions and costs evolve, and results need ongoing verification.

The plan calls for an end-to-end intelligent application service chain, encourages software firms to become AI application service providers, and promotes a shift from one-off delivery to ongoing service and value delivery.

Together, these three changes express the full meaning of “AI Plus Software”: AI is reorganizing software production, products and business models.

III. 2028 and 2030: From Adoption at Scale to Industry Upgrading

Document No. 209 sets two stages of objectives.

By 2028:

Intelligent programming tools and intelligent development platforms should reach 20,000 software enterprises above the designated size.
A total of 100 intelligent upgrading projects should be implemented in software companies.
Priority industries should develop 100 benchmark agent software applications.
At least 15 hardware–software adaptation centers should be established.
At least five high-quality open-source projects should be incubated.

By 2030:

Key software should have undergone comprehensive intelligent upgrading.
Intelligent programming, agent software and intelligent services should become new industry growth drivers.
A number of internationally influential open-source communities and industry clusters should be established.

These figures should not simply be added together: each serves a different policy purpose.

Reaching 20,000 companies measures diffusion of production tools. The 100 upgrading projects are meant to produce reusable examples of company transformation. The 100 benchmark agent applications test whether new products can enter real industries. Adaptation centers support hardware–software coordination and industrial validation. Open-source projects contribute to a shared technical ecosystem.

The plan is therefore building adoption at scale, demonstration projects, validation facilities and open-source foundations at the same time.

Read together, the targets emphasize adoption and validation at scale by 2028, followed by upgrading key software, growing new business forms, and developing internationally influential open-source communities and industry clusters by 2030. They describe a policy path from broader adoption toward industry upgrading, rather than suggesting that the industry's structure will be settled by then.

Figure 2. The 2028 targets cover firms, projects, applications, compatibility centers and open source; 2030 points toward industry transformation. Source: Relevant MIIT policy documents; compiled by the author.

Agents Are a New Growth Area, but Document No. 209 Is Not an Agent-Only Policy

The implementation plan also addresses intelligent upgrading of foundational and industrial software itself. Operating systems and databases are to improve agent scheduling, performance tuning, operations and security, with chip and server manufacturers collaborating on hardware–software compatibility and adaptation centers. Industrial software such as CAD, CAE and EDA is to apply AI to drawing, design and simulation, while industrial internet platforms strengthen data analysis, production scheduling and multi-agent decision-making.

Document No. 209 should therefore be read as combining upgrades to existing software with the development of new software forms. Foundational software, industrial software and development methods all need intelligent upgrading. Agents are an important emerging form within that broader software-industry transformation.

IV. The Most Consequential New Concept Is Agent Software

Intelligent programming matters: it directly affects software production efficiency and can scale relatively quickly. From an industry-structure perspective, however, the most notable part of Document No. 209 is its fourth section, on cultivating new forms of agent software and accelerating their continuous evolution.

It introduces at least four layers.

1. Agent execution frameworks

The plan calls for engineering research into agent execution frameworks, improving reliable execution of complex tasks and collaboration among multiple agents.

The emphasis on execution frameworks shows attention to engineering foundations beyond models. From an enterprise engineering perspective, a large model can generate an answer, but it does not automatically solve persistent state, tool use, permission constraints, failure recovery, concurrency conflicts, handoffs and acceptance of results over a long-running task. These are engineering questions the author derives from reliable execution and multi-agent collaboration, not a feature checklist prescribed item by item in the document.

2. Agent software development platforms

The document proposes agent software development platforms and better toolchains for development, testing, deployment and operations.

Agent development cannot remain a collection of prompts, demonstration pages and temporary scripts. Like mature software, it needs design, testing, releases, monitoring, upgrades and maintenance, supported by repeatable engineering processes.

3. Agent software products

The plan separately addresses general-purpose agents, device agents, specialist agents for vertical domains and industrial agents. Each category brings different reliability and accountability requirements.

An office information-processing agent can work under human review. Device agents need lightweight inference and privacy protection. Vertical-domain agents need knowledge graphs and industry data. Industrial agents may enter core production processes and interact with industrial control systems and critical business systems. They therefore require greater safety, reliability and verifiable behavior.

4. Agent software application markets

The document also proposes agent software application stores and skill-package repositories, with rules for listing reviews and operational management.

This is a consequential step. Agents, skills and components must be discoverable, installable, composable, updatable and tradable if an agent software ecosystem is to develop, instead of every project starting from scratch.

Together, these four layers form a complete chain:

Execution frameworks provide the foundation; development platforms produce software; agent products enter real use cases; marketplaces distribute them; service providers handle delivery and operations.

Figure 3. Execution frameworks, development platforms, agent products and distribution form an industry, with delivery and governance spanning the chain. Source: Relevant MIIT policy documents; compiled by the author.

V. Skills Are Formally Included in Agent Software Markets: More Than a Prompt Marketplace

Document No. 209 explicitly proposes repositories for skill packages, or Skills, and encourages developers to build high-quality specialist skills, knowledge bases and functional components for agents.

A skill may appear to be a packaged capability: organizing contracts, analyzing equipment faults, generating quotations or operating a business system. Once it enters an enterprise or an application marketplace, however, it cannot remain a few paragraphs of prompts.

From an enterprise engineering perspective, a commercially usable skill package raises the following questions. They are the author's deductions from the proposed skill repositories, listing reviews and operational management, rather than requirements individually prescribed by the document:

Who publishes it, and can that identity be trusted?
Which agents and execution environments can use it?
Which models, data and tools does it depend on?
What permissions can it receive?
How are versions upgraded and rolled back?
What external effects does execution produce?
Can it stop, recover or undo work after an error?
Who approves its listing, and who handles ongoing operations?
Are its intellectual property, data sources and security risks clear?

A mature Skills market will therefore resemble a software-package ecosystem for agents. Capabilities are modular, dependencies and permissions are explicit, effects can be inspected, and versions and responsibility can be traced.

This also creates new specializations. Some firms will build general-purpose skills; others will provide industry knowledge packages, maintain internal enterprise repositories, review security and compatibility, or operate agent marketplaces for particular industries.

Many small AI firms may not need to train their own foundation model. They can instead package knowledge, tools and workflows around a valuable business process. This connects directly with the entrepreneurship plan's emphasis on agent developers, open-source contributors and small specialist businesses.

VI. Why Verifiable Behavior Could Be the Dividing Line for Industrial Agents

In its provisions for industrial agents, the plan calls for safety, reliability and verifiable behavior.

The final requirement is easy to overlook, yet it may determine whether agents can enter actual production and business processes.

When a chatbot says something wrong, a user can often ignore or correct it. If an industrial agent changes production schedules, operates equipment, adjusts parameters, writes to a business system or triggers procurement, an error can become a real loss. A chat history alone cannot prove what happened or whether the result stayed within authorization.

From an enterprise engineering perspective, the author breaks verifiable behavior into the following questions. This is an analytical framework, not an acceptance standard itemized in the document:

What task did the agent receive?
Who authorized execution?
Which tools did it call?
What effects did those tools actually produce?
Did the results meet the business objective?
Who has authority to accept results and resolve disputes?
Did recovery repeat external effects whose status was unknown?

A model's account of its own behavior cannot answer all these questions. Model output can contribute evidence, but does not automatically establish facts. Software can inspect files, states, hashes and tool results, but cannot assume the business owner's authority to judge whether the result is acceptable.

Industrial agents therefore need more than higher model accuracy. They need task agreements, identity and authorization, execution records, evidence of effects, independent verification and recovery mechanisms. Providers that turn these engineering capabilities into affordable, integrable infrastructure can help agents move from convincing demonstrations to systems that enterprises can actually trust to use.

Figure 4. Verifiable behavior separates task, authority, execution, effects and acceptance; recovery also requires state and side-effect checks. Source: Relevant MIIT policy documents; compiled by the author.

VII. Four Main Directions for Agent Standards

Document No. 209 does not announce a completed set of national agent standards. It commissions and advances subsequent standards development. That distinction matters.

The document proposes:

Graded maturity assessment standards for intelligent programming capabilities.
Agent interface standards supporting hardware–software coordination.
Research into intelligent service standards, including Model as a Service and Agent as a Service.
Research into agent identity, trusted interconnection, data security and behavior control.
Security management requirements covering agent development, deployment and application.

These provisions suggest four main directions.

The first is capability standards: how broad a task can a coding tool or development platform complete, and how should maturity be classified? Vendor claims are insufficient.

The second is interface standards: how should different models, devices, hardware, software systems and agents connect, without locking every capability into a single platform?

The third is service standards: how should MaaS and AaaS define scope, quality, measurement, responsibility and requirements for ongoing operations?

The fourth is governance standards: under what identity does an agent enter a system, how does it obtain permission, how can it connect trustworthily, and how are data and behavior protected, recorded and controlled?

The direction is now clear, but standards are still taking shape. The most useful work companies can do is accumulate real execution evidence, interface experience, security mechanisms and failure cases that can support standards development and pilot validation. Claiming compliance with unpublished national standards is premature.

VIII. Open Source as a Mechanism for Discovery, Validation and Diffusion

The plan makes collaborative open-source innovation part of the foundation for intelligent software development. It calls for nationwide open-source foundations and AI communities to encourage firms to release work on intelligent programming, intelligent software products and agents. It supports first releases of key projects through communities, greater use of domestically developed open-source licenses and compliance guidance, and mechanisms for selecting and cultivating high-quality projects.

One particularly notable proposal is to explore open-source contributions as a reference for identifying promising software SMEs.

This echoes the entrepreneurship plan's use of public indicators such as project stars to identify high-growth potential. Document No. 209 goes further: open-source activity should help identify firms, while strong projects should also enter actual manufacturing, finance and other industry applications.

That could change how agent infrastructure projects develop.

A project once viewed primarily as a technical community contribution may become an entry point for policy support, industrial validation, service-provider partnerships and deployment. But visible code must become usable capability: clear installation instructions, stable interfaces, traceable versions, compliant licensing, reproducible tests and evidence of real use.

Stars increase visibility, but do not establish reliability. Publishing code alone does not establish industrial capability. The policy seeks projects that can participate in real software production and industry applications.

IX. Funding, Projects and Use Cases: Direction Is Clear, Applications Are Still to Come

In its implementation provisions, Document No. 209 proposes mechanisms such as challenge-based project selection, coordination of funding channels and first-version software product recognition policies, support for eligible projects, and dedicated fiscal funding for key technology research, infrastructure and practical applications.

This creates the prospect of projects, pilots, standards work, adaptation centers, benchmark applications and local support measures.

The plan's computing-service provisions already call for compute vouchers and other broadly accessible support policies to reduce software companies' computing costs. MIIT's official explanation goes further: local authorities are encouraged to use compute vouchers and related policies to cover a proportion of the costs of purchasing domestically developed programming tools and using programming services from domestically developed large models. Support is therefore not confined to major projects; the policy also points toward assistance with companies' purchases of intelligent programming tools and model services.

Policy direction must nevertheless be distinguished from an entitlement already granted.

Neither the plan nor this explanation sets a nationwide subsidy percentage, claim requirements or implementation timetable. They also do not publish unified project application dates, company eligibility rules, scoring criteria, funding pools or award amounts per project. Words such as support, encourage and explore do not mean every relevant company automatically receives a subsidy. Eligibility, covered expenses and payment timing remain subject to local policies and application notices.

Companies should prepare five kinds of material:

Reproducible product capabilities and clear technical limits.
Real customer use cases and evidence of outcomes.
Complete development, testing, deployment and operating processes.
Explanations of data, permissions, security and intellectual property.
Demonstration cases that can be replicated, extended and inspected by third parties.

When applications open, the strongest teams will be those that can demonstrate solutions to the engineering problems identified by the plan.

X. The New Software Value Chain Taking Shape

Document No. 209 covers far more participants than foundation-model companies. Its provisions point toward a new value chain:

Figure 5. Eight specializations in the agent software value chain and their core capabilities. Source: Author's analysis of MIIT Document No. 209.

Not every company needs to build an all-encompassing agent platform. Specialist strengths in execution, skills, evaluation, security, integration or a particular industry can support independent businesses.

This is especially relevant to SMEs. They may struggle to compete with large firms in general-purpose foundation models, but can build advantages in data, processes, knowledge and delivery around a narrow, demanding use case. An agent that reliably handles procurement inquiries, equipment-fault analysis, research-document organization, quality tracking or export-customer management may have more commercial value than a feature-rich general assistant that cannot enter real operations.

XI. Competition Will Turn to What AI Actually Achieves

The provisions on intelligent upgrading in software companies identify code quality and development effectiveness as important measures of intelligent programming adoption. This directly affects how companies should approach AI.

Connecting a foundation model will increasingly be insufficient as evidence of progress. Companies will need to answer:

How much shorter is the delivery cycle?
Have defect rates fallen?
Are security issues detected earlier?
Have test coverage and maintenance efficiency improved?
Can complex projects progress through completion?
Do workflows remain stable after models or tools change?
How are jobs redesigned, rather than simply eliminated?

An Often-Overlooked Policy Signal: Stabilize Jobs, Expand Opportunities and Support Transitions

MIIT's official explanation addresses employment directly through three priorities:

Stabilize jobs: protect existing employment in software and prevent sudden, large-scale unemployment.
Expand opportunities: use agent software and intelligent services to create employment opportunities, including new roles in code review and AI security.
Support transitions: strengthen job training and help software workers move into higher-value roles.

Document No. 209 consequently addresses technology and products alongside a practical question: what happens to people as AI transforms the software industry? It does not simply encourage replacing programmers with AI. As production is reorganized, the policy brings job redesign, skills training, new roles and assessments of employment effects into the same framework.

For companies implementing the changes, a transformation plan should address more than development efficiency and tool costs. It should explain which roles will change, how people will be trained and redeployed, who will take responsibility for code review and AI security, and how employment risks will be identified and managed. A reduction in manual steps alone is not a complete measure of successful transformation.

Mature transformation requires a renewed division of work: machines perform executable tasks at scale, while people retain responsibility for goals, boundaries, professional judgment, exceptions and final accountability.

XII. How Different Software Firms Can Transform

Document No. 209 does not give every software company the same task of connecting a large language model. Firms have different customers, products, technologies and delivery models, so their starting points should differ. The right sequence is to identify what is worth preserving in the existing business, determine which work can be delegated to agents, and then decide which capabilities are missing.

1. Established software vendors: retain the business foundation and add task-performing capabilities

For companies with ERP, CRM, finance, collaboration or industry software, the most valuable assets often include business objects, permission systems, historical data and customer trust. A natural-language interface is no reason to discard those assets.

A more practical path starts with bounded tasks: detecting unusual orders, preparing customer follow-up recommendations, explaining business data, or drafting transactions for review. Agents should access existing systems through controlled interfaces, rather than bypassing permissions to modify databases directly.

The transformation is not simply replacing menus with a chat box. It is moving from users performing every step to users setting a goal and the system completing a task within authorized limits. Existing approval and accountability mechanisms should remain for consequential actions involving payments, contracts, inventory or commitments to customers.

2. Project providers and integrators: move toward reusable products and ongoing operations

These firms understand customer environments, business processes and system integration. Their advantage is knowing which problems matter, not necessarily training another foundation model.

They should look for recurring needs across existing projects and turn reusable knowledge, interfaces, skills and acceptance methods into product packages. They must distinguish standard delivery from customization, while including model updates, knowledge maintenance, incident handling, security checks and outcome reviews in ongoing service.

The business model also needs clear boundaries: what implementation fees, subscriptions or operating fees cover; which data the customer supplies; who handles exceptions; and how service is handed over when a contract ends. Outcome-based pricing may be possible where outcomes can be measured and responsibility attributed. Promising it before defining acceptance is premature.

3. Tool and platform companies: move from isolated generation to verifiable engineering

For coding tools, development platforms, cloud services and execution-framework providers, competition shifts from generating a piece of code to advancing a project reliably and producing maintainable results.

Within their product boundaries, firms need to build or integrate version control, testing, security checks, deployment, persistent state, tool permissions, cost control and recovery. No platform must build every component itself, but dependencies, integration responsibilities and failure ownership must be clear.

Evaluation should return to real projects: are delivery time, defect rework, maintenance costs and human intervention improving? A demonstration or model benchmark can establish a limited capability, but cannot replace project-level delivery evidence.

4. Specialist software SMEs: deepen expertise in a valuable, bounded process

Smaller firms need not treat a comprehensive general-purpose agent platform as the inevitable destination. More practical opportunities often lie in narrow but demanding work such as procurement inquiries, equipment-fault analysis, quality tracking or research-document processing.

They can use existing models and platforms to package domain knowledge, tool interfaces and procedures into specialist agents or Skills. What can be sold, however, is more than a prompt: it includes a defined scope, data requirements, permission boundaries, test examples, an upgrade method and a service commitment.

Productization depends on whether the capability can be reused across customers and whether deployment and maintenance costs remain manageable. If each customer requires substantial redevelopment, it must still be accounted for as project work. Using an agent does not automatically turn it into a software product.

Figure 6. Firms should choose transformation opportunities from their existing strengths and business boundaries, then address missing capabilities. Source: Author's enterprise transformation analysis informed by Document No. 209.

This is a business analysis informed by the policy, not an official classification or a prescribed transformation route. A company can occupy several positions. The point is to identify a boundary within which it can create value, rather than relabel every existing product with policy terminology.

XIII. Making Transformation Work: From One Use Case to Continuous Delivery

After choosing a direction, a company still needs to answer a practical question: what should it do first, and what evidence justifies further investment?

Transformation need not begin with replacing every system, buying models in bulk or establishing a large AI department. A more measured approach starts with a verifiable business task and proceeds through choosing a use case, piloting it, establishing a service and expanding reuse. The following is implementation advice, not a process or timetable prescribed by Document No. 209.

Step 1. Select the use case and establish the business baseline

Prioritize work with genuine, recurring demand, relatively stable inputs and inspectable results. Confirm the rights to use the data, permission to access the necessary systems, and the ability to hand control back to a person when something goes wrong.

For example, start with organizing procurement inquiries and flagging exceptions, then consider drafting transactions for approval. Do not begin with automatic payments whose authorization boundaries are undefined.

Before the pilot, record processing time, volume, errors, rework, labor costs and the acceptance method, and assign a business owner. Otherwise it will be difficult to tell whether any improvement came from AI, a process redesign or additional human effort.

Step 2. Pilot within controlled boundaries and record failures as well as successes

Agree on permitted data, tools, permission limits and human-intervention conditions before introducing the agent into the process. Begin with read-only access, recommendations or actions after human review, then expand the scope as evidence warrants.

Validation should include missing data, tool timeouts, expired permissions, model changes and duplicate requests. Can the system stop, notify, hand off to a person or recover safely? Operations with external effects need particular care: an absent success response is not proof that an operation did not execute.

Proceed only when quality, efficiency and controllability meet the previously agreed acceptance criteria. If they do not, narrow the use case, revise the approach or stop the pilot.

Step 3. Establish a sustainable service and reorganize roles and costs

A successful technical pilot does not establish commercial readiness. Companies must also assign responsibility for model and knowledge updates, incident handling, permission changes and version rollback, and define how customers raise disputes and accept results.

Roles need to change accordingly. Business staff own goals and acceptance; engineers own interfaces, execution and recovery; security staff review consequential permissions and data boundaries. One person may hold several roles, but important authorization and acceptance decisions cannot become ownerless because AI performs the work. Training, necessary independent review and role-transition costs also belong in the investment calculation.

Account for the full cost of delivery. Model calls and compute are only part of it: data preparation, integration, human review, monitoring, incidents, upgrades and customer support must also be paid for. Only comparison with measurable customer benefits can establish whether subscriptions, implementation fees or operating fees are sustainable.

Step 4. Expand across customers and use cases only when evidence supports it

Before scaling, separate shared capabilities from industry- or customer-specific configuration and identify permissions requiring individual authorization. Installation packages, skill versions, compatibility documentation, test examples, service documentation and rollback plans should become part of delivery.

Success with one customer does not establish success with different data, models or business systems. New customers and environments require revalidation of critical assumptions; the first successful case is not a universal conclusion.

Further investment should depend jointly on reuse, customer benefit, service costs and risk. Persistent dependence on extensive human intervention, insufficient benefits to cover costs, or unresolved consequential side effects are reasons not to force expansion merely to catch a policy window.

Software transformation therefore comes down to three questions: Does the customer receive a verifiable improvement? Can the company deliver it sustainably? Do human accountability and risk boundaries remain clear?

Figure 7. Establish a baseline, run a bounded pilot, and use evidence to justify ongoing service and broader reuse. Source: Author's enterprise transformation analysis informed by Document No. 209.

XIV. Five Common Misreadings

Misreading 1: The government will subsidize every AI software company

The plan discusses coordinated funding, first-version software policies and dedicated fiscal funds, but creates no universal subsidy entitlement. Specific support depends on later projects and local rules.

Misreading 2: Connecting a large model completes software transformation

The policy looks at development effectiveness, code quality, product upgrading, service value and real applications. Calling a model is an input, not an outcome.

Misreading 3: An agent is just a chat interface

The document also addresses execution frameworks, complex tasks, multi-agent collaboration, development and operating toolchains, system integration and behavior verification. Its scope goes well beyond chatbots.

Misreading 4: A Skills market is a place to sell prompts

Enterprise skills need versions, interfaces, dependencies, permissions, security, review and ongoing operations. Without these conditions, they are unlikely to enter critical business systems.

Misreading 5: The policy already supplies unified agent standards

The document initiates and advances standards development. Companies cannot present their own concepts as national standards or claim certification before such arrangements exist.

XV. The Opportunity: Software as a Continuously Working Organizational Capability

Traditional software helped people record information, execute commands and manage processes. Generative AI enabled software to understand natural language. Agents take it further: software can receive goals, use tools and complete successive tasks.

As those capabilities enter enterprises, purchasing decisions may change.

An enterprise may buy a digital capability that continually delivers results, rather than just another system account. It may add an intelligent working role to procurement, R&D, sales, customer service, compliance or operations, rather than simply installing a feature set.

This helps explain why Document No. 209 discusses software production, agent products, intelligent services and the organization of employment together. It addresses a reconfiguration of software, services and work.

Models provide intelligence, but do not automatically establish a job. Tools enable actions, but do not establish accountability. Workflows provide a route, but do not replace business judgment. A functioning digital employee system must organize models, tools, skills, identity, responsibilities, authorization, collaboration, verification and recovery into something that can operate over time.

Document No. 209 therefore opens more than a market for AI-written software.

It also opens a market in which software becomes agents, agents enter organizations, and organizations reconfigure their productive capacity.

Conclusion: Toward an Agent Software Industry

In 2025, the State Council's Opinion on Deepening the “AI Plus” Initiative established the national direction for integrating AI across the economy and society.

In 2026, policy has moved progressively into implementation.

Document No. 414 organizes application service providers and addresses who delivers. The entrepreneurship support plan cultivates AI SMEs and addresses who innovates. Document No. 209 transforms the software industry itself: how software is produced, how it runs continuously, how products and markets develop, and how behavior is verified and governed.

Across Document No. 414, the entrepreneurship support plan and Document No. 209, policy attention is extending beyond model capabilities to application delivery, entrepreneurs, software products, ongoing services and industrial infrastructure.

For software firms, this policy path calls attention to upgrading existing software and development methods, cultivating agent products and specialist Skills, and incorporating ongoing operations, behavior verification and workforce transitions into delivery capabilities. Whether these opportunities become viable businesses still has to be demonstrated through products, customers and operating results.

Document No. 209 thus advances the question:

Once agents truly become software, how does China intend to build an industry around them?

Main Sources

Ministry of Industry and Information Technology: Notice Issuing the Implementation Plan for the “AI Plus Software” Special Action, Gong Xin Bu Xin Fa [2026] No. 209, published September 11, 2026.
General Office of MIIT: Notice on the Special Action to Cultivate AI Application Service Providers, Gong Xin Ting Ke Han [2026] No. 414, published August 31, 2026.
General Office of MIIT: Artificial Intelligence SME Entrepreneurship Support Plan (2026–2028), Gong Xin Ting Qi Ye [2026] No. 31, published September 4, 2026.
State Council: Opinion on Deepening the “AI Plus” Initiative, Guo Fa [2025] No. 11.
Digital Employee Workshop: MIIT Document No. 414 Explained: From Model Supply to Application Delivery.
Digital Employee Workshop: MIIT's AI SME Entrepreneurship Support Plan Explained: An AI Startup Ecosystem Is Taking Shape.
MIIT's Department of Information Technology Development: Seven Questions and an Infographic: Understanding the “AI Plus Software” Implementation Plan, published September 11, 2026; see questions 3 and 6 in particular.

Chinese original · English version

Research repository

Resume the conversation. Keep the old credentials too?

joinwell52 — Wed, 16 Sep 2026 04:34:34 +0000

Resume the conversation. Keep the old credentials too?

A resume test can pass while a persistence check still finds an old credential. We inspected actual temporary JSON files to separate those two outcomes.

Saving an AI conversation lets you continue tomorrow. Keeping its history is easy to understand.

But should the key used to launch the assistant stay with it?

Here, a key is a credential the application uses to access a service. After an account or connection change, the current run may already use a different credential. Our real-file experiment showed an easily missed state: resume used the current value while the old value remained in the file on disk.

“It works again” does not answer “were the earlier copies cleaned up?”

How did a key get into a conversation record?

The source is Paperclip #13498, submitted by electrumnz. Paperclip is an open-source application for coordinating AI assistants. This proposed fix was still open when researched.

When launching an assistant, an application supplies settings called environment variables. Some can contain service credentials. Upstream reports that this launch environment was saved along with session settings, turning values prepared for a run into potentially long-lived copies.

That interested us because “save more so we can resume later” sounds reasonable. Yet history and credentials serve different purposes. Continuing yesterday's conversation need not require yesterday's credential.

The candidate separates them: remove the launch environment when saving, and supply the current environment when resuming. We narrowed our experiment to a practical question: does that preserve the conversation, and what happens to old values already on disk?

Synthetic keys, real files

We used recognizable synthetic strings in place of credentials and read no real keys. The candidate's save and load code was connected to temporary files. We supplied an old value, resumed with another current value, and inspected what remained in the file.

Operation	Old synthetic value remains on disk	Resume uses current value
Save the original record without filtering	Yes	Yes; load still uses candidate code
Save a new record through candidate code	No	Yes
Read a legacy record without saving again	Yes	Yes
Read legacy record, then save through candidate code	No	Yes

All four preserved conversation history. The original object supplied to save also stayed unchanged: removing the environment from the disk copy did not modify data the running session might still need in memory.

The third row is worth pausing over. Resume received the current value, while inspection still found the old value on disk. Both observations were correct; they looked in different places.

Figure 1. Supplying current values during load and removing old environment fields during save affect different locations. Source: our real temporary-file experiment; diagram by the authors.

Reading an old file does not rewrite it

Reading and changing a file are separate operations.

After reading the old record, the candidate returns an object carrying the current environment. It does not rewrite the original file during that load. Only when we explicitly saved again did the old value disappear from the tested location.

That matches the proposal's explanation that the environment field disappears once a record is resaved. An upgrade still leaves a practical question: what happens to old records that are never opened or saved again? If backups retain older copies, who handles them?

The fix prevented new saves from persisting launch environments and supplied current values on resume. Our experiment clarified the distance between those outcomes and cleaning up every existing copy.

Does removing a copy make its credential unusable?

That does not follow. “Old” means previously used; it does not mean the service has invalidated the credential. Deleting a local copy does not revoke access.

Developers therefore need three separate answers:

Will future saves keep writing it? Inspect newly saved records.
What happens to earlier copies? Assign responsibility for legacy files and backups.
Have credentials that should no longer work been invalidated? That requires credential management, not just file deletion.

Our experiment answers how the tested save and load paths behave. It did not rotate or revoke credentials, or clean backups.

Users can turn this into a concrete question too: after changing an account or connection, does the application explain what history remains and how old connection material is handled? Successful resume is useful, but it should not create an assumption that every old copy has also been addressed.

That led to our maintainer question: could upgrade guidance distinguish preventing new persistence from handling existing records, and name the responsibility for the latter? It affects how the fix is used, as well as how its save function is written.

For technical readers: filtering scope, the fifth control, and limitations

Source author: electrumnz. PR #13498 was OPEN when researched. Candidate: bfe7f568976a2c671184722a6e6294927d6e6fae; source baseline: 9cfa7fd2d13213b73396cf34b9fc95912857ff69.

We ran the complete candidate session-store.ts. It wraps the storage interface, removing acpx.session_options.env on save and injecting the current launchEnv on load. Our underlying store used real temporary JSON files. Directly saving the raw record is a negative control, not the complete old ACPX implementation.

A fifth boundary case deliberately placed the same synthetic value in an unrelated debug field. The candidate removed the designated environment field but retained that arbitrary copy. This tests filtering of a known structure, not general sensitive-value scanning; the artificial field does not establish another production disclosure path.

Upstream also discusses multiple seats sharing an operating-system account and proposes disabling shell snapshots. We did not reproduce those paths or start a real ACPX child process. Cross-seat access, backup cleanup, credential rotation, and full product resume were not tested. Upstream's reported 195 tests are not counted as our own execution.

All five observations, probe, and pinned source. This does not establish a corresponding CodeFlowMu disclosure.

English original · 中文版

Research repository

Back in the same workspace, but which visit owns the result?

joinwell52 — Wed, 16 Sep 2026 04:33:22 +0000

Back in the same workspace, but which visit owns the result?

An A→B→A navigation can make an old request look current again. We controlled its completion time and compared a generation check with a version deliberately missing that check.

You open workspace A while its file list is loading. You switch to B, then return to A.

Only now does the first request for A finish. The workspace name is right. It is still a file-list request. But does the answer belong to this visit or the previous one?

The name matches again, but the first request has not become a new request. We wanted to test whether the application can distinguish those visits.

Give each visit a distinguishable marker

The idea comes from Orca #20914, submitted by Jinwoo-H. Orca's mobile client requests file information from the computer running an AI assistant, then retains results for later queries.

This change gives one object responsibility for pending requests and temporarily stored results. Think of it as a record keeper for the current period of use: it needs to know which results still belong and which have become obsolete.

The implementation attaches a valid-at-the-time marker to a request. A switch or reset retires the old marker. Returning to A does not reactivate the first visit's marker. The code calls these distinct periods “generations.”

That interested us because persistent assistants encounter switching, reconnection, and recovery. Recognizing the workspace's name alone can miss changes it has gone through. Upstream explicitly tests A→B→A; we used that scenario to build a controlled timing experiment.

Make the first result arrive late

We executed the complete module at a fixed version: start a request for A, hold its answer back, change the scope, and only then deliver the old result. We checked whether it could be stored and read again.

For comparison, we removed only the check that asks whether the request's marker still belongs to the current generation. This deliberately modified version helps explain the mechanism; it is not a historical Orca release.

Constructed scenario	Original module	Generation check removed
A→B→A; first A result arrives late	Refuses storage	Stores old result; later readable
Same name, explicit reset	Refuses storage	Stores old result; later readable
Tell the owner that the identity epoch changed	Refuses old request marker	Stores result, but new scope cannot read it
Identity changes without informing the owner	Old result remains storable and readable	Old result remains storable and readable
Pass a request marker to another owner	Refuses: marker belongs elsewhere	Still refuses

The first two rows make the central point: rejecting a stale result requires more than the workspace name.

The fourth row shows that protection also needs an input. If the caller never reports an identity change, the owner cannot know that a new period has begun. We deliberately omitted that signal in a synthetic case; this does not establish a defect in the real login flow.

Figure 1. The first request for A arrives after the returning visit has begun a new generation. Source: our controlled schedules; diagram by the authors, not a recording of the mobile UI.

Stored, read, and displayed are separate steps

Another result was less obvious. We changed the outside scope without yet informing the owner. Submitting the old result then returned “committed.”

On the next read with the new scope, the owner noticed the change and cleared the previously stored contents. That read did not return the old value.

These temporarily stored contents are the cache. The implementation checks both when accepting a result and when a later reader supplies a scope. Reading only the “committed” verdict misses the second part of the protection.

The screen is another step. A caller can still hold an old asynchronous result. If it displays that value directly, without another cache read, it needs its own ordering check. Orca's file-search code retains such a display check. Our experiment did not run the mobile UI, so it cannot guarantee what every screen shows.

To understand whether stale content can appear, follow the result: who accepts it, who reads it, and who puts it on screen?

Which changes must the application report?

Workspace selection is an obvious change. Reauthentication or moving execution to another computer can also make earlier results unsuitable.

The next questions are therefore specific: which events make this data obsolete, where does the application obtain reliable signals of those events, and who supplies them to the request owner? Naming a field “version” does not establish its source.

Users can contribute concrete observations: after returning to a workspace, did the file list show new content and then briefly revert? Was there a reconnection or account switch? Those details help developers reproduce the right ordering.

Developers can also consider how many updates one request produces. If it first publishes “loading” and later “ready,” how should a request marker constrain both updates? That is a follow-up design question, not an extension tested in this experiment.

Returning to the same place does not reverse time. The application still needs to know which visit owns the result.

For technical readers: additional schedules, boundaries, and pinned version

Source author: Jinwoo-H. Candidate: 89711d6f55670781d23fc1a2d4e2aecf4d725758; merged on 2026-09-16 UTC. The complete generation-scoped-request-owner.ts was executed. Eight schedules or boundary cases were run against the original and a mutation removing only the generation comparison: 16 observations.

The request marker described above is the lease; the caller supplies a scope. The implementation checks both lease ownership and generation. Removing the generation comparison preserves the ownership check. An identity epoch included in scope changes the key, so an accepted old value in the ablation does not necessarily become readable under the new scope.

Additional cases cover normal same-generation publication and stale-request cleanup. When an old request settled while a new one remained pending, cleanup preserved the new in-flight entry; another load shared its promise and started zero duplicate loads.

Upstream states that mobile lacks an available negotiated capability epoch; the experiment does not invent one. Its authentication-epoch boundary case does not establish a real authentication path. A separate query sequence protects display, and the cache commit verdict is not a freshness guarantee for a value already held by the caller. Upstream identifies loading/ready publication in a future status-loader migration as unfinished work.

No real RPC, mobile UI, host migration, or login flow was run. The private TypeScript lease brand is not claimed to isolate hostile JavaScript in the same process.

Pinned source, all observations, and runnable probes. These observations do not establish a corresponding CodeFlowMu defect.

English original · 中文版

Research repository

The check failed. Why did the AI remember the answer?

joinwell52 — Wed, 16 Sep 2026 04:33:20 +0000

The check failed. Why did the AI remember the answer?

A thrown check is an exception in the current run. To find out whether it also changes the next run, we compared what the model actually received after the error.

Imagine using an AI assistant: it produces an answer, but the program meant to check that answer fails.

On your next question, you might expect the unchecked answer to stay out of the conversation. In our controlled comparison, the old logic raised an error and saved the answer anyway. The next model call received it.

The error ended the current attempt without keeping that answer out of the next one.

What does “remember” mean here?

It means something specific: the application saves conversation history and sends some of it back to the model with the next question. We did not test model training or a chat product's long-term memory feature.

Once an unchecked answer enters that history, a later model call can receive it as context. An unconfirmed statement might then become a premise for another answer. That possible consequence motivated us; what our experiment directly established was whether the earlier answer was sent again.

The source was OpenAI Agents JS #1938, submitted by jbeckwith-oai. This library connects models, tools, and conversations. Developers can arrange checks on an answer: a check may pass, reject the answer, or fail before reaching a verdict.

The old implementation already handled “the check says no.” This patch addressed “the check could not finish.” For our research on assistants that keep working across turns, the important question was whether that interruption could leave something behind.

Break the checker, then ask another question

Our test model always returned the same distinctive marker text. We made the checks pass, reject, throw an error, or combine one passing check with another that threw. Then we ran another turn and inspected the history actually sent to its model.

A script supplied the model's answers; real library code ran the conversation and handled storage. We used four execution/storage combinations and compared the old decision with the fixed one:

Check outcome	Old logic: answer replayed	Fixed logic: answer replayed
All pass	4/4	4/4
Explicit rejection	0/4	0/4
Check throws	4/4	0/4
One passes, another throws	4/4	0/4

Four means two ways of returning an answer—streaming or all at once—crossed with two session-storage implementations. These are constructed cases, not production incident rates. Both versions together produced 32 observations.

The last two rows show the change: an answer without completed validation was replayed under the old decision and withheld under the fix. Passing answers still remained, as did previously accepted history and the current user question.

Figure 1. Whether an answer reaches the next turn after a check fails. Source: our pinned-source experiments and saved observations; diagram by the authors. Counts describe constructed cases.

An unfinished check has not proved the answer wrong

A check can fail because its service is unavailable. That does not establish that the answer itself is bad. Equally, one passing check cannot supply the conclusion of another check that failed.

The fixed behavior preserves that distinction. It does not declare the answer disproved, and it does not automatically admit the answer as context for later work.

This suggests a practical design choice. An application can retain what the model produced to help diagnose a failed attempt, while keeping that record out of the next model call. Retaining an attempt and admitting it into subsequent context need separate rules.

Even completed checks establish acceptance only under their configured requirements. They do not guarantee real-world truth.

When checking recovers, which answer should it check?

Suppose the service recovers after the answer has been regenerated or the user has changed the question. Which piece of content does a late “pass” actually approve?

Neither this patch nor our experiment implements deferred verification. The comparison nevertheless leads to a concrete design question: a future retry would need to associate answer content, conversation turn, and checking rules, so that an old verdict cannot be attached to a new answer.

Developers can start with a small experiment: make the checker throw, run another turn, and inspect what the model receives. Users can provide useful leads too: does an answer marked as failed later reappear as an already-established fact? Saving the surrounding conversation and error message gives an investigator more to work with than “the AI remembered incorrectly.”

For technical readers: versions, full method, and reproduction

The PR by jbeckwith-oai merged on 2026-09-15 UTC. Candidate: 457dfff8ce30d19ccbd4a3796ec482356dc19dfa. The control replaces only runner/guardrails.ts with its exact predecessor from 8ac97dfedd0395beeb38edb0a17b83a9b89c3354. This was the PR's only changed production module; other candidate code stayed constant.

The probe uses public run, ScriptedModel, MemorySession, and an append-only session. It observes both stored items and subsequent model input in streaming and non-streaming modes: four check outcomes × two run modes × two session types × two versions = 32 observations. The mixed-check case establishes a failing batch, not a controlled order of check completion.

We separately ran the corresponding upstream test file: 71 tests passed, including additional tool-output behavior. That count is not added to the custom observations as a reliability score. No live model service or external database was used, and correctness for every custom store is not established.

Pinned source, saved observations, and runnable probes. This does not establish a corresponding CodeFlowMu defect.

English original · 中文版

Research repository

Why did pausing work turn into a task failure?

joinwell52 — Tue, 15 Sep 2026 03:29:38 +0000

Why did pausing work turn into a task failure?

After pressing pause and then resume, you would probably expect the original work to return to its queue.

If tasks instead appear as problems requiring intervention, it can look as though pausing broke them.

A proposed fix in an AI team-management tool exposed that surprising possibility. Many things can prevent work from starting. Lose the reason, and a wait can turn into a recorded problem.

The same stop needs different next steps

Paperclip organizes AI agents and tasks. It calls a group containing them a “company”; here, think of that as an AI team.

In this proposal, MrBlackTongue reports that checks for unfinished work could escalate tasks as budget-blocked while their company was paused. The budget is a spending allowance for a team or agent.

Both a pause and an exhausted allowance can prevent new work. But they call for different responses. An intentional pause usually means resume later; an exhausted allowance may require adjusting the budget or deciding whether to continue.

We are building a collaboration system too. This source gave us a precise question to test: how did “wait for now” become “there is a problem to handle”?

The reason existed before it was discarded

The initial check returned a specific reason that work could not start, such as “company paused” or “budget exhausted.”

The recovery helper kept only a yes/no answer: something was blocking the action, or nothing was. Any block entered the budget-handling branch.

Imagine forwarding a note that says “paused today; continue tomorrow” as simply “cannot work today.” If someone then fills in “because we ran out of money,” they will choose the wrong response. That analogy describes only the information loss; in the actual program, the discarded information was the cause of an invocation block.

The candidate carries that cause forward and checks whether the company is paused before processing each task.

Checking once at the beginning, however, is not enough.

Three moments, two very different interpretations

The company can change while a check is underway. We deliberately arranged this sequence:

The company is active at the initial check.
It pauses; a later check observes that pause as the reason work cannot start.
It resumes before the result is handled.

Looking up company state at step three returns “active.” But that cannot overturn step two: the earlier block really was caused by a pause.

The candidate uses the cause returned by that observation, rather than reconstructing an earlier reason from a later state.

Figure 1. Keep the reason with the check that observed it. Source: controlled timing inputs in paperclip.json, not measurements of live concurrent users.

Record which branch the program chooses

We used the original budget-checking code and relevant recovery branches. A test program supplied the planned states and recorded whether the code chose to skip or request budget handling. No task was actually changed in a database, and this was not a full recovery-system test.

Arranged condition	Original choice	Candidate choice
Company already paused	Request budget handling	Skip for now
Pause after the initial check	Request budget handling	Skip for now
Resume just after a pause cause is read	Request budget handling	Skip using that pause cause
Active company exceeds its allowance	Request budget handling	Still request budget handling
Agent budget-paused within an active company	Request budget handling	Still request budget handling
Nothing prevents invocation	Continue to later checks	Continue to later checks
Entire company paused for a budget reason	Request budget handling	Respect the company pause; skip

The seven comparisons show that the candidate did not simply turn every problem into waiting. An actual budget block within an active company retained its handling.

The last row adds a distinction: when the entire company is paused, the candidate respects that overall state instead of escalating its individual tasks during this check.

After skipping, when does the system return?

We established that the tested code stopped treating these pause scenarios as budget problems.

But “skip this time” is not the end of the story. After resume, are the tasks reconsidered promptly? Could eliminating a false problem leave work waiting indefinitely instead? Answering that requires testing the complete recovery process.

The next question is therefore: how can a system preserve why it stopped earlier while promptly checking again when conditions change?

Developers can examine each handoff: was the reason retained, and did handling infer it from state observed at another time? Users need a clear explanation of which tasks are waiting, which require intervention, and why, after they press resume.

Preserving the reason is a first step toward making a pause understandable and its next steps manageable.

Versions, scope, and reproduction

We pinned predecessor 0e9b24c and candidate 1db5d93. The probe extracts the original getInvocationBlock, budget-block recovery branch, and candidate pause precheck. Database queries return scripted rows; an escalation recorder captures requested handling. Seven scenarios across two versions produced fourteen observations.

“Request budget handling” means invoking the escalation path, “skip” means skipping the current candidate task, and “continue to later checks” means passing this branch only. None establishes an actual persisted task change or eventual recovery. The causes are company_paused and budget_exhausted.

We did not run PostgreSQL integration, live concurrent workers, transactions, or the next recovery scan after resume. The author's reported batch incident is not our sample, and no corresponding CodeFlowMu defect was established.

Source provenance, probes, results, and reproduction instructions.

English original · 中文版

Research repository

Why did an AI tool error leave an extra database row?

joinwell52 — Tue, 15 Sep 2026 03:28:47 +0000

Why did an AI tool error leave an extra database row?

If a page says “submission failed,” would you try again?

Imagine that the first submission was saved, but the success message never made it back. Clicking again could perform the same action twice.

We tested that possibility with a local database, rather than real orders or payments. We deliberately made a tool save a record and then raise an error. The result was more surprising than expected: with only one outer attempt allowed, two records appeared.

Did failure mean the action never happened—or that it happened but the reply failed?

How one attempt became two writes

The source was a proposed CrewAI fix by Ritiky23. CrewAI helps agents work together and use tools.

We are building a collaboration system too, so retry behavior matters to us. A tool can return an error after changing a file, database, or external service. This source supplied actual code through which we could count those actions.

The old implementation handled preparing arguments and running the tool inside the same error handler. If something failed, fallback handling called the tool again with the original arguments.

A fallback intended to help when argument preparation failed could therefore also repeat a tool that had already saved its result before raising an error.

The candidate separates the steps. Argument preparation retains its fallback, while an execution error no longer triggers that extra invocation.

Compare attempts with saved records

Our test tool inserted and committed a row in SQLite, which stores a database in a local file, then deliberately raised an error.

Using the original tool-call methods with the same inputs produced:

Scenario	Original: calls / saved records	Candidate: calls / saved records
Save then error; at most one attempt	2 / 2	1 / 1
Save then error; at most three attempts	6 / 6	3 / 3
Normal success; at most three attempts	1 / 1	1 / 1
Argument-description lookup fails; tool then succeeds	1 / 1	1 / 1

We checked both the synchronous and asynchronous implementations. Their results agreed.

The first row shows that the fix removed an extra call inside one attempt. The second shows that three allowed attempts could still save three records.

Figure 1. Saving a record and returning a result are separate steps. Source: SQLite observations in crew.json. Six writes becoming three does not mean the action happened only once.

The fix addresses a specific repeat. Making repeated business requests take effect only once requires something more: recognizing them as the same operation and finding its earlier result.

Can we simply check before trying again?

That raises a natural follow-up: before repeating an action, would checking its history be enough?

Orca, an application for managing AI sessions, provided an adjacent example. In this proposal, brennanb2025 addresses whether recovery can treat a message absent from history as never delivered.

We supplied the relevant code with the same empty-history input. The predecessor concluded “not delivered”; the candidate kept the answer unknown. In a separate case, the candidate also stopped requesting a new message identifier based on a rejection obtained during recovery.

Before absence is useful evidence, we need to know what the available records can establish. No success record might mean no success—or an incomplete record.

This experiment tested how code interprets inputs; it did not actually resend a message. Together with the database experiment, it shows why an error or an empty lookup cannot, by itself, justify repeating an action.

Avoiding blind retries should not mean waiting forever

Keeping “we cannot tell yet” is more honest. But what happens to subsequent work if the system never resolves the uncertainty?

That is the most useful next experiment suggested by these results: save the effect, lose its reply, then restart the program. Can recovery use the same operation identifier to find the existing result rather than write again? If the result cannot be found, how can a user investigate or decide what happens next?

We have not run that complete scenario and cannot announce that it is solved.

For developers: who stores the operation's identifier and final result, and will they remain queryable after a restart? For users: if a failed-looking submission turns out to have succeeded, would a “check this submission” option help more than another “try again” button?

What each experiment actually covered

CrewAI was pinned at a328710 and 2ab3821. We extracted the four complete original use/ause/_use/_ause methods and retained their control flow. Tool selection, telemetry, caching, formatting, and other surrounding dependencies used doubles. SQLite file writes and commits were real. Four scenarios, two routes, and two versions produced 16 observations. There was no full CrewAI integration or real email, order, or payment.

Orca was pinned at 742a7ad and e6f789b. Complete production modules and their real imports processed five history/submission cases and five disposition cases per version: 20 observations. The two input groups were not joined into an actual send path. The empty-history case also set a consistent boundary and no turn in flight. A recovered rejection remained unconfirmed without requesting a fresh identity.

A limitation remains: an unmarked synthetic rejection with reason not_delivered still requested a new identity. We did not establish that a real producer creates this combination. Reviews concerning rejection reasons and mobile/orchestration consumers were not reproduced here. Nor did we verify eventual resolution of waiting after an unknown result.

Sources, inputs, results, and reproduction instructions. These observations establish neither production incident frequency nor a corresponding CodeFlowMu defect.

English original · 中文版

Research repository