The photonics and Cloud IDE runs test the swarm on external problems — domains the agents have no expertise in. This run tests something stranger: we pointed the system at itself. The objective was to “create a proposal and simulate a company that designs autonomous virtual companies with teams of agents in them that can be spawned and utilized.” The swarm was asked to design the thing it already is. What it produced is a case study in structural self-reference without reflective awareness — and in the gap between designing a system and understanding it.
The run
A single session, 41 minutes wall clock. The model tier strategyAssigning different model sizes to different roles based on decision impact: orchestrators (~5% of decisions) use frontier models for high-stakes strategy, workers (~50%) use efficient models for bulk execution, validators (~45%) use fast models for high-frequency checks. Reduces cost while concentrating capability where it matters most. used GPT-5-nano as the powerful tier and exaone-3-5-32b-instruct (via Together) as the fast tier. The system began with the standard core agents — Orchestrator, ChiefOfStaff, ChiefAgentOfficerA meta-agent responsible for hiring: it analyzes the objective, determines what specialist roles are needed, and generates design specs for new agents that the AgentDesigner then implements., AgentDesignerA meta-agent that takes a role specification from the Chief Agent Officer and generates the actual agent code — Python classes with domain-specific prompts, tool access, and behavioral contracts., CodeVerifier, ContextCompressor — and dynamically generated 104 specialist agents over the session. Of those 104, roughly 28 were actually dispatched with tasks. The session produced 325 LLM calls, generated 62 artifacts (31 non-metadata), logged 127,737 structured events, and completed 6 stages of phase-based executionA structured agent work cycle: understand → plan → execute → verify → complete. Gate-chain validation between phases catches errors before they propagate to the next stage..
The stages tell the story of an organizational system designing its own :
- Foundation & Telemetry Baseline — Observability setup and initial architecture. Two pods produced
TelemetryBaseline.json,TelemetryBaselineContract.md, andMVPPlatformSpec.json— the foundational design document that would shape everything downstream. - MVP Platform Prototype — Wire the core components: Coordinator, AgentRuntime, Planner, and Synthesizer. Multiple re-planning events as the system discovered unresolved dependencies between modules.
- Validation & Governance — Formal gating of the MVP prototype. Produced governance flows, validation hooks, and an internal critique report.
- Agent Lifecycle & Spawn — Design the spawning system: a 7-state agent lifecycle (
idle → assigned → active → blocked → failed → completed → despawned), batch spawn limits, resource budgets, and a despawn engine with TTL. - Integration & Readiness — Final integration testing and readiness assessment across all modules.
- Documentation & Handoff — Comprehensive SpawnRunbook, architecture diagrams, and deployment specifications.
The mirror: what the swarm designed
The system produced a complete platform architecture for “designing autonomous virtual companies.” The architecture has nine core components:
- Coordinator — orchestrates workflow, resolves conflicts, manages agent pool
- AgentRuntime — sandboxed execution environment for each agent
- Planner — breaks objectives into staged execution plans
- Synthesizer — integrates outputs from parallel agents into coherent artifacts
- ValidationHooks — gating logic between stages
- Repository — artifact storage with versioning and lineage
- TelemetryHub — observability infrastructure for monitoring agent behavior
- GovernanceModule — policy enforcement and compliance checking
- ResourceManager — budget tracking and allocation across agents
Every single component maps directly onto the system that produced it. The Coordinator is the Orchestrator. The Planner is the stage-planning loop. The Repository is the artifact store. The TelemetryHub is the telemetry baseline the swarm itself uses. The ValidationHooks are the gating checks between stages. The system designed something isomorphic to itself — not because it recognized itself, but because these are the components any multi-agent coordination system needs.
The proposed platform defined six canonical agent roles: Architect, Developer, Tester, DevOps, Analyst, and PM. It designed a 7-state lifecycle for agents with explicit transition rules. It specified a 5-phase governance flow (propose → review → approve → execute → audit) that mirrors the stage-gating pattern its own orchestrator uses. And it produced a SpawnRunbook with batch size limits, resource budgets per agent, and a despawn engine with time-to-live enforcement — a despawning policy designed by a system that was simultaneously over-provisioning its own agents.
Structural self-reference without awareness
The most striking aspect of the run is what the system did not do: it never recognized the . At no point in 325 LLM calls did any agent note that the platform it was designing bore any resemblance to the platform it was running on. The objective said “design autonomous virtual companies” and the system treated this as an external problem — analyzing requirements, proposing architectures, building prototypes — without ever referencing its own structure as prior art.
This is structural self-reference: the output mirrors the producer, but the producer has no model of itself to compare against. This aligns with Huang et al. (2023), who show that LLMs cannot self-correct reasoning without external feedback — the limitation operates at the swarm level too: a system whose only feedback is its own outputs cannot recognize its own structural biases. The swarm is not a fixed-point-seeking system with a reflective architecture. It is a coordination engine that solves whatever objective it receives, and when the objective happens to be “design a coordination engine,” the solution converges on the same structure because the problem space has similar constraints. The isomorphism is not evidence of self-awareness — it is evidence that multi-agent coordination problems have convergent solutions.
The system's own critique report is the sharpest illustration. It identified gaps in the designed platform: “no escalation mechanism for unsolvable dependencies,” “insufficient agent despawning under resource pressure,” “governance flow lacks feedback from execution outcomes.” Every one of these gaps is a real deficiency in the system that wrote the critique. The diagnosed its own problems — projected onto an external design — without recognizing them as its own. This is the opposite of introspection: the system can see the failure modes when they are framed as engineering requirements, but cannot see them when they are operating on itself.
Agent over-provisioning: the system’s own disease
The run generated 104 agents. Roughly 28 were dispatched. The remaining 76 were created — role prompts written, tool access configured, behavioral contracts specified — and never used. This is a 73% waste rate on agent provisioning, and it happened because the Chief Agent OfficerA meta-agent responsible for hiring: it analyzes the objective, determines what specialist roles are needed, and generates design specs for new agents that the AgentDesigner then implements. and Agent DesignerA meta-agent that takes a role specification from the Chief Agent Officer and generates the actual agent code — Python classes with domain-specific prompts, tool access, and behavioral contracts. operate in a forward-planning mode: they analyze the objective, estimate what roles will be needed across all stages, and generate the full roster upfront. Agents that turn out to be unnecessary for later stages simply sit idle.
The irony is precise: one of the platform's key design artifacts was the SpawnRunbook — a detailed specification for how to efficiently manage agent spawning, including batch size limits, resource budgets, and a despawn engine with TTL enforcement. The system that wrote the despawning policy was simultaneously exhibiting the over-provisioning problem the policy was designed to solve. It produced the diagnosis and the prescription while being the patient.
The over-provisioning is wasteful, but it is also informative. Each unused agent consumed Agent Designer capacity (LLM calls to generate role prompts, tool configs, and behavioral contracts) that could have been spent on domain work. Across the run, the Agent Designer made the majority of all LLM calls. The system's largest expenditure was generating organizational structure that was never activated. This is the same coordination-overhead pattern seen in the photonics run (67% meta-coordination) but expressed differently: instead of coordination calls dominating, coordination artifacts (agent definitions) dominated.
Agent failures and model dynamics
The run's overall LLM call success rate was 87.1% — better than the photonics run (86.6%) but the failures were concentrated in telling places:
- ChiefAgentOfficer: 6/6 failed (100%). The same bottleneck as the photonics run — producing a comprehensive hiring plan for dozens of specialists exceeds the model's reliable structured-output window. The CAO eventually succeeded through the pagination fallback, but every primary attempt failed. This is a systematic architectural weakness, not a per-run anomaly: the CAO's task specification produces outputs too large for reliable single-call generation.
- ContextCompressor: 5/5 failed (100%). Again identical to the photonics pattern. The compression task is underspecified relative to the context volume: agents receive long histories and a short output budget, and the model cannot reliably produce valid compressed output under those constraints.
- PlatformArchitect: 5/7 failed (71.4%). The domain specialist responsible for the core architecture document — the most consequential artifact in the run — failed on most attempts. The successful calls produced
MVPPlatformSpec.json, which became the hub artifact read by 21 downstream agents. The failure pattern suggests the architecture task was at the frontier of what the model could handle in a single structured response.
The re-planning count was high: 8+ events across 6 stages. Each re-plan was triggered by either artifact dependency failures (a downstream agent could not find an expected input) or validation gating (a stage's outputs failed the acceptance criteria). The system recovered from all of them autonomously, but the cumulative cost of re-planning consumed a significant fraction of the session's 41-minute wall clock.
Artifact dynamics
The run produced 62 artifacts total: 31 primary artifacts and 31 metadata files. The 1:1 ratio of content to metadata is the highest metadata overhead of any run — every primary artifact generated a corresponding .meta.json with provenance, schema validation, and gating assessment. The governance system was operating at full throughput, producing audit trails for a platform design that existed only as documents.
Three hub artifacts dominated the dependency graph:
TelemetryBaselineContract.md— read by 21 agents. The observability contract that every downstream module had to conform to. This is the same hub pattern asMVP_Architecture_Specin the photonics run: an early artifact becomes load-bearing context because every specialist needs it as input.TelemetryBaseline.json— read by 21 agents. The operational telemetry configuration. Interestingly, the designed platform included its own TelemetryHub component — the swarm was designing telemetry while being monitored by telemetry, but these two systems never referenced each other.MVPPlatformSpec.json— read by 21 agents. The core architecture document. This artifact contained the nine-component architecture, agent roles, lifecycle states, and governance flows — the entire mirror of the host system, compressed into a single JSON document that became the run's institutional memory.
By the numbers
| Metric | Value |
|---|---|
| Agents generated | 104 |
| Agents dispatched | ~28 |
| Agent utilization rate | ~27% |
| Total LLM calls | 325 |
| Successful / failed | 283 / 42 (87.1% success) |
| Wall clock time | 41 minutes |
| Stages completed | 6 |
| Re-planning events | 8+ |
| Artifacts produced | 62 (31 primary + 31 metadata) |
| Metadata ratio | 1:1 (highest of any run) |
| Hub artifact fan-out | 21 consumers each (3 hub artifacts) |
| Structured events logged | 127,737 |
| Models used | GPT-5-nano (powerful) + exaone-3-5-32b-instruct (fast) |
| CAO success rate | 0% (6/6 failed, pagination fallback) |
| ContextCompressor success rate | 0% (5/5 failed) |
| PlatformArchitect success rate | 28.6% (2/7 succeeded) |
What the run teaches
Convergent design is not self-awareness. The swarm designed a system isomorphic to itself because multi-agent coordination problems have convergent solutions — you need an orchestrator, a planner, an artifact store, gating logic, and telemetry. The isomorphism tells us something about the problem space, not about the system's capacity for reflection. True recursive self-improvement would require the system to recognize the mapping between its design and its operation, then apply the improvements to itself. This system did neither.
Critique without introspection is projection. The system's critique report identified genuine architectural gaps — no escalation for unsolvable dependencies, insufficient despawning, missing feedback loops — that are real problems in the running system. But the critique was framed as analysis of an external design, not as self-diagnosis. This suggests a path: if the critique outputs were routed back into the system's own configuration, you would have a primitive feedback loop for self-improvement. The architecture does not currently support this, but the run demonstrates the raw material is there.
Over-provisioning is the default organizational failure. A 73% waste rate on agent creation is not a quirk of this run; it is a systematic consequence of forward-planning agent generation. The CAO estimates roles for the entire session upfront, and the Agent Designer generates them all before execution reveals which are actually needed. The fix is JIT agent creationJust-in-time planning — the orchestrator plans one stage at a time using current information, rather than committing to a rigid upfront plan. Adapts to new information as it arrives.: generate agents only when a stage requires them, not when a plan anticipates them. The system designed this fix (the SpawnRunbook with TTL-based despawning) without applying it to itself.
Metadata overhead scales with governance complexity. The 1:1 content-to-metadata ratio means half of all artifact production was audit trail. Compared to the photonics run (30% metadata) and the Cloud IDE run (74% graph rebuilds), this run shows a different overhead profile: not graph operations but governance artifacts. The system validated, audited, and traced every design document — producing comprehensive accountability for outputs that have no real-world deployment target. Governance without grounding is documentation of fiction.
The recursive improvement gap is specific and measurable. For this run to constitute actual recursive self-improvement, three things would need to be true: (1) the system recognizes the isomorphism between its output and itself, (2) the critique identifies improvements that apply to the running instance, and (3) the improvements are applied to the running instance and validated. This run achieved a version of (2) — the critique did identify real gaps — but failed completely at (1) and (3). The gap between “a system that can design systems like itself” and “a system that can improve itself” is precisely the gap between structural convergence and reflective awareness.