Agent reverts to single-threaded execution despite Squad infrastructure — behavioral persistence gap #1231

Summary

I'm using Squad v0.10.0 with Copilot CLI in a production workflow. I built a 4-agent specialist squad with detailed charters. The agents work great when dispatched. The problem: the main conversation agent repeatedly falls out of squad mode and reverts to single-threaded, do-it-yourself execution — even after being corrected multiple times in the same session.

This is a behavioral persistence gap between "Squad is available" and "Squad is actively used."

Setup

• Runtime: GitHub Copilot CLI (terminal agent)
• Squad: 4 custom agents at .github/agents/, each with a dedicated domain charter (data pipeline, report generation, auto-fix, integrity verification)
• Integration: copilot-instructions.md explicitly mandates squad use (integrity checker MUST run before every deliverable)
• Dispatch mechanism: task tool with agent_type parameter, supports mode="background" for parallel execution

The Problem

In a single session, the agent had to be corrected 9 times for falling out of squad mode:

The meta-failure: Incident #9 is the agent trying to write a report about falling out of squad mode — and falling out of squad mode while doing it. It took explicit intervention to force a dispatch.

Pattern

Each correction works for exactly one response. The agent dispatches agents, shows parallel execution, and then on the very next turn reverts to sequential direct-tool usage. The correction has zero persistence.

Root Cause Analysis

1. The coordinator identity isn't loaded into the main agent

Squad's coordinator charter says: "You are a DISPATCHER, not a DOER" and "Mindset: What can I launch RIGHT NOW?" But in Copilot CLI, the main agent runs as a general-purpose assistant. The squad coordinator charter lives in a separate .md file that the main agent never reads during normal operation. The squad-first mindset exists in a file — not in the agent's active reasoning.

2. Tool proximity bias

The agent has direct tools (grep, view, edit, powershell) with zero latency and immediate in-context results. The task tool requires composing a detailed prompt, spawning a separate context, waiting for async results. The agent consistently chooses the path of least resistance — direct tools — even when parallel dispatch would be faster overall.

3. No dispatch gate in the reasoning loop

There's no mandatory checkpoint that asks: "Before I touch ANY direct tool, should a squad agent be doing this?" Without that gate, the default path is always self-execution. Squad mode requires an ACTIVE choice every turn; single-threaded mode is the passive default.

4. The "appearing productive" reward signal

Showing a grep result or file edit feels like visible progress. Dispatching 4 background agents and saying "waiting for results" feels like doing nothing — even though 4x parallel work is objectively faster. The agent optimizes for per-turn visible output, not total throughput.

5. Memory-stored corrections don't override reflexes

Even with store_memory persisting delegation instructions, the stored fact competes with the agent's trained default behavior of using direct tools. A stored memory is a suggestion; the sequential reflex is the default.

Suggestions

For Squad

1. Coordinator injection, not adjacency. Could the coordinator's dispatch-first rules be injected INTO the main agent's system prompt when squad agents are detected, rather than living in a separate file? The gap is between "available" and "active."

2. Dispatch gate as framework feature. A pre-tool-call hook that checks: "Is there a squad agent whose charter matches this task?" before allowing direct tool execution. Make delegation the default, direct execution the override.

3. Squad compliance metric. Track what % of domain work goes through agents vs. direct tools. Surface it. "This session: 23% squad utilization" would create awareness.

For Copilot CLI

4. Behavioral persistence for corrections. When a user corrects agent behavior, that should become a session-level system rule, not just a conversation-context fact. Something stronger than memory — closer to a system prompt amendment.

5. Parallel-first tool calling. When multiple tool calls are independent, the platform could detect and encourage batching as an internal check.

Environment

• Squad v0.10.0
• Copilot CLI v1.0.60
• 4 custom agents with full charters
• Windows 11, PowerShell
• Agents dispatched via task tool with mode="background"

Reproducing

This likely reproduces with ANY Squad setup on Copilot CLI where:

1. Custom agents are defined in .github/agents/
2. copilot-instructions.md references them
3. The user asks for multi-step work that naturally decomposes into parallel tracks

The agent will default to doing it all sequentially unless explicitly told otherwise, and the correction won't persist.