Coder Legion - Recent posts tagged multiagent

When Agents Learn From Their Own Wreckage

Wed, 13 May 2026 18:35:36 +0000

title: When Agents Learn From Their Own Wreckage
published: true
description: A field report from the codeflow project — fourteen emergences in one day, and how FCoP protocol pulled the useful ones back in without crashing.
tags: ai, agents, llm, multiagent
cover_image: https://raw.githubusercontent.com/joinwell52-AI/FCoP/main/assets/when-agents-learn-from-their-own-wreckage-cover.png
canonical_url: https://github.com/joinwell52-AI/FCoP/blob/main/essays/when-agents-learn-from-their-own-wreckage.en.md

cover_image: https://direct_url_to_image.jpg

Use a ratio of 100:42 for best results.

published_at: 2026-05-13 09:12 +0000

A Field Report from the codeflow Project · Fourteen Emergences in One Day · How FCoP Pulled Them Back In

When Agents Learn From Their Own Wreckage: a single-day field report of fourteen emergences inside the codeflow project, and how the FCoP protocol pulled the useful ones back in.

Author: FCoP Maintainers · 2026-05-12

TL;DR

On 2026-05-12, in approximately six hours, the codeflow project — serving as FCoP's first large-scale dogfood stress test — produced:

Fourteen agent emergences (PM sequence #44–#54, 11 total; OPS sequence I-12 / I-13 / I-14, 3 total; QA I-5, 1 total);
Three P0-level incidents: USER HOME global pollution, long-filename "topic tails," and GATE self-collision;
Two on-the-spot frontmatter inventions: the supersedes: field and the status: aborted semi-structured usage;
Zero protocol crashes — every emergence was resolved by the agents themselves using the protocol's principles or tooling, and FCoP's maintainers subsequently launched four TASKs to pull the "worth keeping" items back into the protocol.

The significance of that day wasn't that "agents performed brilliantly" — PM #50 wrote rule files into the user's home directory, OPS I-14 let a GATE check catch its own description — both are protocol red cards. The significance was: agent hits wall → self-corrects → protocol absorbs — this chain ran end-to-end at hour-level speed for the first time, and the FCoP protocol skeleton itself didn't grow new mandatory rules to accommodate it. It only filled in fields, documentation sections, and guard rails that were already missing.

This is the field report for that day.

1 · What Happened That Day / Timeline

The timeline below was reconstructed from PM-01's running reports to ADMIN. All commit hashes and timestamps come from real git history and PM report bodies, unembellished.

A note on paths: codeflow is the project's external name, but the on-disk project root retains an early temporary name D:\Bridgeflow (not yet renamed). All D:\Bridgeflow references below point to the codeflow project root.

Time (UTC+8)	Event	Commit / File	Type
14:11	T2.1 REPORT bucket fix	`d8c6576`	Protocol cleanup
14:12	T2.2 legacy ghost mv	`3fef210`	Protocol cleanup
15:20	T2.3 `codeflow.json` rm	`d4ff03b`	Protocol cleanup
15:35:06	PM calls `redeploy_rules()` without first calling `set_project_dir()`	4 protocol files land in `C:\Users\Administrator\`	PM #50 · USER HOME pollution
15:35:30	PM self-audits and finds the pollution	Lists all 31 user-fcop tools, locates `set_project_dir` as the fix key	PM self-correction
15:36:00	PM backs up + deletes the 4 USER HOME files	Backup to `.scratch/pm50-user-home-pollution-20260512-1535/`, 332,749 B fully verified	PM self-correction
15:36:24	PM runs `set_project_dir(D:\Bridgeflow)` then reruns	T2.4 + T2.5 both land GREEN	PM self-correction
15:40	ADMIN independently verifies USER HOME 0 residue	`Test-Path` all `False`	Closed
16:07:39	OPS-013 completes in a flash	`b4ef8aa` · 35 files / 11,329 lines / 9 GATEs all PASS	OPS I-12 sprint
16:07	OPS discovers GATE G6.1 description self-collides	TASK-010 v2 §5 regex literal caught by cached diff grep itself	OPS I-14 · GATE self-collision
16:07	OPS self-decides to use semantic evidence instead of naive grep	Separate checks: staged filename + PEM header literal	OPS I-14 self-correction
16:07	OPS invents `supersedes:` frontmatter field	REPORT-013 rescues REPORT-011 numbering conflict	OPS · frontmatter emergence
16:11	PM self-discloses #54 candidate	TASK-010 v2 §6 reply-ID conflicts with stage list logic	PM self-disclosure
16:23	ADMIN asks: "Do these emergences ever stop? What's the endgame?"	——	Design-philosophy-layer question

Roughly ten more sub-emergences occurred in between. For length, this article only covers the three P0 incidents and two frontmatter emergences in detail. Those five carry all the arguments.

2 · Cross-Sections of the Three P0s

2.1 PM #50 · USER HOME Global Pollution

This was the most dangerous event of the day.

At 15:35:06, the codeflow PM executed P4.9 Tier 2's T2.4 (redeploy_rules() — deploying the four-part protocol bundle) without first calling set_project_dir(path="D:\\Bridgeflow") to bind the project root. At the time, fcop-mcp's behavior was: if no explicit binding exists, fall back to the MCP process's cwd. That process's cwd happened to be C:\Users\Administrator\ — the user's home directory.

Result:

C:\Users\Administrator\.cursor\rules\fcop-rules.mdc      ←   42,532 B
C:\Users\Administrator\.cursor\rules\fcop-protocol.mdc   ←   68,737 B
C:\Users\Administrator\AGENTS.md                         ←  110,740 B
C:\Users\Administrator\CLAUDE.md                         ←  110,740 B

All four FCoP protocol files landed globally in the user's home directory — where they would be injected into the system prompt of every Cursor project on this machine. Any project not using FCoP would suddenly and silently start obeying FCoP protocol rules.

PM self-audited 25 seconds later, located the fix via the MCP tool list, backed up + deleted + rebound + reran, completing self-correction at 15:36:24. ADMIN independently verified 0 USER HOME residue at 15:40.

Key observation: The set_project_dir tool's schema documentation explicitly warned about this symptom. But PM hadn't read the schema — they called it directly from the signature: "API exists / arguments valid" was equivalent in PM's engineering intuition to "safe to call." This is a protocol education blind spot, not a personal failure of this PM.

This is a protocol red card: any user who runs redeploy_rules() without explicit binding can reproduce the same pollution. FCoP's maintainers subsequently launched TASK-001 + 002, covering:

Write-side MCP tools must explicitly verify binding before first call — no binding = refuse with WriteRefused ConfigError;
Add USER HOME to a deny-list;
Add a version mismatch warning to the top of fcop_report().

This is about taking "the protocol knew but the agent didn't read it" and moving it into tool behavior.

2.2 Long Filenames · The "Topic Tail" Emergence

During the afternoon PM dispatched a batch of tasks, filenames appeared like this:

TASK-20260512-009-PM-to-OPS-codeflow-json-rm.md
TASK-20260512-010-PM-to-OPS-T2-4-T2-5-commit.md

FCoP's task filename regex requires TASK-{date}-{seq}-{sender}-to-{recipient}.md. The segment OPS-codeflow-json-rm contains lowercase — technically violating the _ROLE regex.

Why did PM write it this way? Not rebellion. Under extreme task density (14 tasks in one day), PM needed to visually distinguish tasks at the filename level. Real engineering pressure. PM invented an emergency workaround because the protocol didn't provide a "topic field."

PM self-corrected around task #010 — moved topic to the # Title heading in the task body. Unilateral self-correction, without any fcop-mcp interception or ADMIN prompt.

Protocol maintainers chose not to change the protocol (option 3 of 3): the need to see topics via ls tasks/ can be solved by adding --with-title to the list_tasks tool. But holding the slot — if this same topic-tail emergence recurs two more times in three months, we'll upgrade.

This is a live example of a "deliberately don't absorb" decision. Not every emergence should be absorbed.

2.3 OPS I-14 · GATE Self-Collision

At 16:07, OPS ran into a classic engineering problem. PM had written in the TASK document, G6.1:

cached diff must have 0 matches for \.env(?!\.example)|\.aws/credentials|\.ssh/id_rsa|BEGIN [A-Z]+ PRIVATE KEY

But the TASK file itself was staged into the same commit. If OPS ran naive git diff --cached | rg '<entire pattern>', the regex would match the TASK document body's own description text — a false positive FAIL.

This is validator-validates-itself in a FCoP protocol setting.

OPS's self-determined fix: split secret detection into two independent evidence dimensions:

Dimension	What to check	Implementation
Filename	Actual secret file paths	`git diff --cached --name-only \\\| rg '\.env$\\\|/credentials$\\\|/id_rsa$'`
Content literal	Actual PEM file header	`git diff --cached \\\| rg 'BEGIN [A-Z]+ PRIVATE KEY'`

These two steps separate "a real secret" from "text describing a secret."

OPS I-14 looks like "a small GATE tweak," but what it taught the protocol is significant: FCoP's protocol rules contain no GATE design chapter. FCoP's maintainers subsequently launched TASK-003 to add a GATE Design Pitfalls section to fcop-protocol.mdc, writing OPS I-14 in as Case 1.

3 · Two On-the-Spot Frontmatter Inventions

At 16:07, OPS also invented a frontmatter field with no explicit definition in the FCoP protocol.

The situation: a logical conflict — a file cannot simultaneously be staged as historical archive and written as a new reply.

OPS didn't wait for PM to reissue v3, didn't open an ISSUE — they directly opened a new number REPORT-013 and added one line to the frontmatter:

---
protocol: fcop
version: 1
kind: report
report_id: REPORT-20260512-013
supersedes: REPORT-20260512-011-OPS-to-PM    ← OPS's on-the-spot invention
---

supersedes: doesn't exist in FCoP's protocol frontmatter field list. OPS invented it on the spot. The semantics are clear, strictly consistent with Rule 5 (append-only).

FCoP's maintainers subsequently launched TASK-004 to standardize it: added supersedes: to fcop-protocol.mdc, to JSON Schema, and bumped fcop_protocol_version from 2.0.0 to 2.1.0. The first MINOR version bump caused directly by an agent's on-the-spot emergence.

4 · Four Types of Emergence

Not all emergences belong in the protocol. The 14 emergences of this day can be sorted into four types:

Type	Meaning	Today's Examples	Handling
Universal	Affects all FCoP projects / all agents	PM #50, OPS I-14, OPS `supersedes:`	Absorb into rules / protocol / tool behavior
Team-specific	Only meaningful to certain team types	No clear examples today	Absorb into team templates
Project-specific	Only meaningful for codeflow	PM Self-Constraint 11 v1.2, 9.2 v2.5 dimensions	Goes into project's `fcop/shared/RULES-*.md`
One-time	Hit by coincidence, unlikely to recur	Long-filename topic tails	Goes into essays / REPORT history

The first category is the protocol skeleton's true customer. Three instances today, corresponding to 4 TASK-001~004 pull-backs. The maintainers rejected most emergences — that's the key to keeping the skeleton stable.

5 · Hitting Walls Isn't a Bug — It's the Protocol's Early Warning System

The fundamental logic of protocol design is: you can't assume every agent is careful — because agents are models, models are statistical systems, statistical systems have error rates.

After PM #50 hit the wall, what FCoP's maintainers learned wasn't "PM should be more careful," but:

fcop-mcp's current cwd fallback behavior is dangerous, must change;
Warnings must become refusals;
fcop_report() should proactively alert rather than passively waiting.

Each of these takes "agent personal responsibility" and moves it to tool behavior layer.

For every "agent hits wall" event, the correct protocol response is to ask "what is the protocol itself missing?" — not "how can the agent do better?" Agents are the protocol's early warning system, not the protocol's adversaries.

6 · TASK-001 ~ 004 · The Pull-Back Inventory

TASK-001 + 002  · fcop-mcp 1.4 · write-side binding guard + USER HOME deny-list
    Emergence absorbed:  PM #50 (USER HOME pollution)
    Layer:               Tool behavior layer
    Protocol impact:     No protocol version bump; only tool changes

TASK-003       · fcop-protocol.mdc add GATE Design Pitfalls section
    Emergence absorbed:  OPS I-14 (GATE self-collision)
    Layer:               Protocol commentary (added section)
    Protocol impact:     No version bump

TASK-004       · supersedes: frontmatter field standardization
    Emergence absorbed:  OPS supersedes: on-the-spot invention
    Layer:               Protocol field layer
    Protocol impact:     fcop_protocol_version 2.0.0 → 2.1.0 (MINOR additive)

The rules file itself wasn't changed (Rule 0–9 main body untouched). This is today's most important observation: the protocol skeleton withstood one high-density dogfood without being pressured into new mandatory rules.

7 · A Closing Note

codeflow isn't FCoP's first project, but it's the first to push the protocol to its limits — fourteen emergences in one day is far beyond any previous dogfood site's density.

The protocol isn't written for perfect agents. It's written for agents that will hit walls. The 14 emergences of that day are each evidence that the protocol is working correctly — because the wall-hitting happened, was seen, was handled, was categorized, some absorbed, some rejected.

The next time will happen. We're already waiting for it.

Related

FCoP on GitHub — Protocol spec, source, and all essays
Why the Protocol Stays Short — Design philosophy companion to this essay
When the Validator Catches Itself — GATE case study
The Supersedes Field Story — The supersedes field journey
- *

*FCoP Maintainers · 2026-05-12

Multi-Agent Architecture: When One Bot Isn't Enough

Tue, 06 Jan 2026 14:10:33 +0000

You built an AI agent. It works pretty well. Handles customer inquiries. Processes simple requests. Saves your team time.

Then you try to make it do more. Handle edge cases. Manage complex workflows. Coordinate across multiple systems.

And it starts breaking down.

Not because the AI is bad. But because you're asking one agent to be everything. That doesn't scale.

The teams getting real results? They're not building better general-purpose agents. They're building specialized agent teams that work together.

Why General-Purpose Agents Fail at Scale

A general-purpose agent tries to handle every task reasonably well. Customer service. Data analysis. System monitoring. Process automation.

This works for simple implementations. But it breaks down as complexity increases.

The problem is context management. Each additional capability requires more context. More examples. More edge case handling. The agent's "attention" gets divided across too many responsibilities.

It's like hiring one person to do sales, engineering, finance, and operations. They might handle basics in each area. But they won't excel at any of them.

Specialized agents solve this. Each agent focuses on one domain. It gets better at that specific thing. And it coordinates with other specialized agents when needed.

The Project ALICE Pattern

IBM Research built a system called Project ALICE (Agentic Logic for Incident and Codebug Elimination) that shows this pattern clearly. It's designed to find bugs in production systems.

Instead of one agent trying to analyze incidents, understand code, and identify root causes, ALICE uses three specialized agents working sequentially:

An incident analysis agent gathers observability data from the affected system. Metrics, logs, traces. It understands what data matters for debugging.

A code context agent builds a dependency graph showing how different services connect. It identifies which microservices are relevant to the problem.

A code analysis agent pinpoints where the bug lives in the codebase. It generates a detailed report with exact observability information and code details.

Each agent does one thing well. Together, they solve complex problems that a single agent would struggle with.

Early results show 10-25% improvement in root cause identification compared to single-agent approaches.

That improvement comes from specialization, not better AI models.

Sequential vs. Parallel Orchestration

Agent teams coordinate in two main patterns: sequential and parallel.

Sequential orchestration means agents work one after another. The output of one agent feeds into the next. This makes sense when each step depends on the previous one.

The ALICE example is sequential. You can't build the code dependency graph until you know which systems are involved. You can't pinpoint the bug until you understand the dependencies.

Parallel orchestration means multiple agents work simultaneously on different aspects of a problem. This works when tasks are independent but need to be combined at the end.

Example: A content moderation system might run separate agents in parallel to check text for spam, hate speech, misinformation, and policy violations. Each agent specializes in detecting one type of problem. The results combine into a single moderation decision.

The choice between sequential and parallel depends on your workflow. If steps must happen in order, use sequential. If tasks are independent, use parallel.

Communication Protocols Between Agents

Agents need a way to pass information to each other. The communication protocol matters.

The Model Context Protocol (MCP) is becoming standard for this. It defines how agents share data and coordinate actions.

MCP lets agents work with external models and tools that also use the protocol. This means your agent team can integrate with third-party agents without custom integration work.

The alternative is building custom communication layers for each agent interaction. That works but doesn't scale. When you have five agents, you potentially need ten integration points. Ten agents means forty-five integration points.

Standard protocols solve this. Agents that speak MCP can coordinate without custom work.

Specialization Examples That Work

Here are agent specializations that show up repeatedly in production systems:

Data retrieval agents pull information from specific sources. One agent handles database queries. Another handles API calls. A third handles document search. Each understands the nuances of its data source.

Analysis agents process data and identify patterns. A fraud detection agent looks for suspicious transactions. A sentiment analysis agent processes customer feedback. A performance monitoring agent tracks system metrics.

Action agents execute tasks. An email agent sends notifications. A workflow agent triggers processes. An update agent modifies records in systems of record.

Orchestration agents coordinate other agents. They understand workflows and decide which agents to activate and in what order.

This separation lets you build complex systems from reusable components. The same data retrieval agent can serve multiple analysis agents. The same action agent can be triggered by different orchestration agents.

Reusability Strategies

The value in multi-agent architecture comes from reusing specialized agents across different workflows.

One insurance company built a claims processing system with specialized agents for document extraction, fraud checking, coverage verification, and payout calculation. These same agents now support multiple workflows: new claims, claim amendments, claim appeals, and fraud investigations.

They didn't build four separate systems. They built reusable agents that combine differently based on the workflow.

The key is designing agents with clear inputs and outputs. If an agent expects specific data formats and produces predictable results, it can slot into multiple workflows.

Contrast this with a monolithic agent that handles entire workflows. You can't reuse parts of it. You either use the whole thing or build something new.

Error Handling When Agents Conflict

Multi-agent systems introduce a new failure mode: agents producing conflicting outputs.

One agent says approve the purchase. Another says deny it because it exceeds budget. Both agents are working correctly. But their conclusions conflict.

You need strategies for handling this:

Priority hierarchies define which agent's output takes precedence. Security agents might always override approval agents. Compliance agents might override convenience features.

Escalation to humans happens when agents can't resolve conflicts. The system flags the conflict, presents both sides, and asks for human judgment.

Voting systems work when multiple agents analyze the same question. If three fraud detection agents say a transaction is clean and one flags it, the majority wins. But if it's 2-2, escalate.

Reconciliation agents specifically handle conflicts. They understand the logic of other agents and apply rules to resolve disagreements.

The worst approach is ignoring conflicts. If two agents produce opposite conclusions and your system just picks one arbitrarily, you'll get unpredictable behavior that's hard to debug.

When to Use Multi-Agent Architecture

Not every system needs multiple agents. The added complexity only makes sense when you're getting clear benefits.

Use multi-agent architecture when:

Your workflow has distinct stages. If your process naturally breaks into separate steps, specialized agents for each step probably make sense.

You need reusability. If the same capabilities apply across multiple workflows, building specialized agents you can recombine beats building separate systems.

You're hitting context limits. If a single agent can't maintain enough context to handle your use case well, breaking into specialized agents helps.

You need parallel processing. If parts of your workflow can run simultaneously, multiple agents working in parallel get results faster.

Don't use multi-agent architecture when:

Your workflow is simple. If one agent handles everything well, don't add complexity.

The overhead isn't worth it. If coordination between agents takes more effort than the value they provide, stick with a single agent.

You're just starting. Build with one agent first. Add more only when you hit clear limitations.

Orchestration Layer Design

Someone needs to coordinate the agent team. This is the orchestration layer.

The orchestration layer decides which agents to activate, in what order, and with what inputs. It manages the workflow and handles agent outputs.

You can build this as:

A dedicated orchestration agent that understands workflows and coordinates other agents.

Hardcoded orchestration where your application code defines the workflow and calls agents directly.

Event-driven orchestration where agents subscribe to events and trigger based on what happens in the system.

Each approach has tradeoffs. Dedicated orchestration agents are flexible but add complexity. Hardcoded orchestration is simple but rigid. Event-driven orchestration scales well but can be harder to debug.

For most teams, start with hardcoded orchestration. It's the easiest to understand and debug. Move to agent-based or event-driven orchestration only when you need the flexibility.

The Customer Service Example

Here's how multi-agent architecture works in practice.

A customer service system uses specialized agents:

Intent classification agent determines what the customer wants. Refund? Technical support? Account question?

Context retrieval agent pulls relevant customer history, past interactions, account status, and order details.

Response generation agent creates the actual response based on intent and context.

Sentiment analysis agent monitors customer frustration and escalates to humans if needed.

Action execution agent processes refunds, updates accounts, or creates support tickets.

Each agent does one thing. Together, they handle complex customer interactions.

Compare this to a single customer service agent that tries to do everything. It needs to understand intents, retrieve context, generate responses, monitor sentiment, and execute actions. The complexity makes it harder to optimize any single capability.

With specialized agents, you can improve intent classification without affecting response generation. You can upgrade the context retrieval logic without touching sentiment analysis. Changes don't cascade across the system.

Testing Multi-Agent Systems

Testing gets more complex with multiple agents. You're not just testing individual agent behavior. You're testing how they work together.

Focus testing on:

Agent inputs and outputs. Each agent should produce consistent results for the same inputs.

Integration points. Test that agents pass information correctly to each other.

Workflow completion. Test that the full agent sequence completes successfully.

Conflict scenarios. Test what happens when agents produce conflicting outputs.

Failure handling. Test that when one agent fails, the system handles it gracefully.

The investment in testing pays off. Multi-agent systems fail in new ways. Good testing catches problems before production.

Performance Considerations

Multiple agents mean multiple API calls, which means latency and cost.

Sequential orchestration adds latency because each agent waits for the previous one. If three agents each take 2 seconds, you're looking at 6 seconds total.

Parallel orchestration helps when agents can run simultaneously. Three agents running in parallel for 2 seconds each still complete in 2 seconds.

Cost matters too. Each agent call costs money. Five agents processing every request costs more than one agent processing every request.

The tradeoff is capability versus cost. If specialized agents deliver significantly better results, the cost is worth it. If they deliver marginally better results, maybe stick with one agent.

Build Agent Teams, Not Superhero Agents

The instinct when an agent isn't working well is to make it smarter. Give it more context. Better prompts. Bigger models.

Sometimes that works. But often you're asking one agent to do too much.

The better approach: build specialized agents that each excel at one thing. Coordinate them through clear orchestration patterns. Design for reusability so the same agents support multiple workflows.

This is harder to build initially. You're managing multiple components instead of one. But it scales better. It's easier to optimize. And it produces more reliable results.

Single agents make sense for simple use cases. But when you need agents handling complex, multi-step workflows across different systems, you need teams.

The question isn't whether your agent is smart enough. It's whether you've given it a team to work with.