EPIC Mode: Archon-Level Orchestration for Agent Swarms

The stuck agent problem

Give a modern reasoning model a hard task and it will often do the wrong thing by thinking too much. It reads another paper, plans another branch, re-evaluates, re-plans, and never acts. Cuadrón et al. call this the reasoning-action dilemma in their 2025 study of agentic tasks: models favor extended internal reasoning over environmental interaction, producing three failure modes — Analysis Paralysis, Rogue Actions, and Premature Disengagement. Higher overthinking scores correlate with lower performance, and reasoning models overthink more than non-reasoning models.

The numbers are significant. On SWE-bench Verified, Cuadrón et al. show that selecting the solution with the lower overthinking score improves performance by almost 30% while cutting compute cost by 43%. In another line of work, Pandian et al. show that Snap-Think — a dual-process mechanism that switches between fast, intuitive action (System 1) and slower deliberation (System 2) — raises solve rates on New York Times Connections puzzles from 72% to 98% with GPT-4o. The lesson is not that reasoning is bad; it is that unbounded reasoning is a liability.

EPIC in one sentence

EPIC is a proposed agent execution mode — Episodic Policy and Intention Control — in which an archon-level orchestrator manages sub-agents through a shared memory bus, a dynamic task topology, and a bounded-rationality gate that prevents overthinking.

Why existing orchestration is not enough

Today's multi-agent toolkits are excellent at wiring agents together, but they do not solve the meta-problem of an agent getting stuck in its own head. Each addresses a different slice:

None of these systems treat memory, dreams, and shared context as first-class citizens of the orchestration itself. They have context windows, checkpoints, or vector stores, but those are plumbing, not policy. EPIC tries to make the orchestrator explicitly aware of its own reasoning budget and of the long-term memory it should consult before, during, and after a mission.

The archon archetype

A quick word on naming. "Archon" is not a single product. Several independent projects use the name — including coleam00/Archon (coding-agent workflows) and shreed27/Archon.AI (distributed engineering). In this post "archon" is an archetype: the agent that rules over other agents, not by doing their work, but by holding their shared intention and resolving their conflicts. It is the role that the EPIC mode instantiates.

The archon archetype appears throughout the research. HMAW frames multi-agent work as a corporate hierarchy: CEO → manager → workers. Planning with Multi-Constraints (PMC) decomposes complex goals into a hierarchy of subordinate tasks. ROMA uses Atomizer, Planner, Executor, and Aggregator. MegaAgent removes predefined SOPs and lets agents spawn agents. The common thread is recursive delegation with a meta-level view. EPIC adds a second common thread: that meta-level view must be grounded in shared, governed, consolidated memory.

The four layers of EPIC

EPIC is not a library. It is a set of contracts. The acronym names four layers that an archon-level mode must implement:

EPIC at work: the control loop

The loop below is what an archon runs for every mission. It is not a one-way pipeline; it is a feedback cycle. The archon keeps a live intention, dispatches sub-agents to the shared context, observes their outputs, and then compresses what matters into memory and dreams.

Stopping the spiral: satisficing and overthink gating

The core anti-paralysis device in EPIC is a satisficing gate. The term comes from Herbert Simon's bounded-rationality work: an agent satisfices by searching until it finds an option that meets an aspiration level, rather than optimizing indefinitely. In EPIC, the archon sets aspiration levels for each subtask — a token budget, a time budget, and a confidence threshold. When any of those is exhausted, the archon forces a decision and moves on.

This is where the research on overthinking becomes operational. The archon maintains an overthink score for each sub-agent. The score is a composite of repetition, reasoning length, and lack of state change. If the score rises above a threshold, the archon intervenes. It can:

The archon does not need to be smarter than the sub-agents. It needs to be aware of when reasoning has stopped producing value. That is a control problem, not a capability problem.

Shared memory as infrastructure, not an afterthought

Multi-agent memory is usually discussed as retrieval: plug in a vector database and search. Recent work argues this is insufficient. The Governed Shared Memory paper identifies four failure modes in fleet-scale multi-agent memory: unauthorized leakage, stale propagation, contradiction persistence, and provenance collapse. The Mesh Memory Protocol goes further, specifying that agents do not copy memory from each other; they remix incoming signals through their own domain intelligence, with per-field admission and inter-agent lineage.

EPIC adopts this as a design principle. The shared context is not a chat log. It is a governed, namespaced, versioned fact store. Every sub-agent writes structured Cognitive Memory Blocks (inspired by the Mesh Memory Protocol's CAT7 schema) to a shared bus. Each block has source identity, scope, timestamp, and a confidence tag. The archon is the reader of last resort: it resolves contradictions, evicts stale facts, and traces provenance.

Dreams as a control signal

Most agent memory work is episodic: store, retrieve, repeat. EPIC treats dreams as a control signal. A dream cycle — replaying recent experience, compressing it into semantic knowledge, and integrating it into a graph — happens both at session end and on demand. When the archon is unsure how to route a task, it queries the dream graph for similar past missions and their outcomes. The graph gives it a topology, not just a fact.

This matters for analysis paralysis because a dream can answer the question "have we done something like this before?" faster than the sub-agents can reason from first principles. It is a form of cached, verified intuition for the archon.

Implementation blueprint for CatGame agent protocols

The CatGame project already has the pieces an EPIC mode needs: skills, workflows, abilities, memory files, dream CSVs, and the &dream / &memory abilities. The blueprint below shows how to add an epic archetype without breaking the existing triplet structure.

.devin/
  skills/epic/SKILL.md          # /epic command usage
  workflows/epic.md             # EPIC phase orchestration
  abilities/epic.md             # &epic advanced mode
  rules/epic.md                 # EPIC policy thresholds
  memories/m_epic_*.md          # high-signal EPIC session records
  ideas/IDEA_EPIC_*.md          # EPIC-derived feature ideas

The /epic skill would run the following phases:

The existing /frontier-post workflow is a perfect EPIC candidate. A single frontier post requires research, drafting, critique, build, publish, and memory consolidation. An EPIC run could delegate research to a subagent_explore, drafting to a subagent_general, critique to a second explore sub-agent, and build/publish to the existing skill — all coordinated through the shared context and all producing memory updates at the end.

Making it concrete: thresholds, API, and metrics

The blueprint above is a sketch. To make it implementable, the archon needs explicit thresholds, a sub-agent contract, and a way to measure whether it is helping. The following table is a straw-man runtime configuration. It is meant to be tuned, not copied.

The sub-agent contract is intentionally small. A sub-agent receives an intention packet (goal, scope, budget, acceptance criteria) and an context pointer (the shared memory namespace). It returns a result packet (status, artifacts, confidence, overthink score). Timeouts, retries, and cancellation are handled by the archon, not by the sub-agent. In Devin-style environments, this maps directly onto run_subagent with a pinned profile and a shared working directory; in other environments it maps to LangGraph nodes, CrewAI tasks, or HTTP workers.

{
  "intention": {
    "goal": "Draft the EPIC section on shared memory",
    "scope": ["governed memory", "mesh protocol", "failure modes"],
    "budget": {"tokens": 8000, "time_sec": 120, "replan_max": 2},
    "criteria": ["cites arXiv 2606.24535", "lists four failure modes"]
  },
  "context": "shared://epic-mode/memory",
  "result": {
    "status": "done|stuck|blocked",
    "artifacts": ["docs/frontier/posts/epic-mode/body.html#shared-memory"],
    "confidence": 0.85,
    "overthink_score": 0.42
  }
}

Security is not an afterthought in EPIC. Shared memory is a prompt-injection surface: a compromised sub-agent can write misleading "facts" that poison downstream agents. EPIC mitigates this with scoped access (a sub-agent can only write to its namespace), provenance on every fact (so a poisoned claim can be traced and rolled back), and read-only audit memory for the archon. These are the same four governance dimensions that Margalit et al. identify: scope, time, provenance, and propagation.

Finally, success metrics. An EPIC prototype is not proven by a single good output. It must be measured on a repeated task with three variables: overthink score (lower is better), mission wall time (lower is better), and output quality (verified by a second sub-agent against the acceptance criteria). If EPIC raises quality while lowering the other two, it is worth the overhead. If it only lowers overthinking at the cost of quality, the thresholds are too aggressive.

Gaps, risks, and what EPIC is not

This is a design proposal, not a shipping system. The following gaps are real and should be flagged:

Another open question is the topology cost model. AdaptOrch shows that dynamic topology selection beats static topologies by 12–23% on coding (SWE-bench), reasoning (GPQA), and retrieval-augmented generation tasks, but it does not say which topology is best for a given task without measurement. An EPIC implementation would need a small offline benchmark suite that records token cost, wall time, and success rate per topology for recurring mission types, then lets the dream graph learn the mapping.

From idea to protocol

EPIC mode started as a thought experiment: what if an agent could be as good at stopping itself as it is at reasoning? The answer, at least in outline, is to separate the role of reasoning from the role of control, and to give the controller access to a governed, dream-consolidated memory. The pieces already exist in the literature and in the CatGame agent infrastructure. The work is to wire them into a single, verifiable loop.

If this line of research continues, the next step is a minimal EPIC prototype: a /epic skill that runs one concrete mission (such as producing this very frontier post), logs the overthink scores and topology decisions, and writes the result to memory and dreams. The experiment is not whether the archon is more intelligent. It is whether it is less stuck.