Bug: explicit named-agent delegation can resume same coordinator session but still answer inline before launching the requested agent #1029

Summary

When I explicitly request a named agent, the coordinator sometimes resumes the existing session correctly but still begins doing the work itself instead of launching the requested agent.

This is not just a general “routing feels weak” complaint. In this case, the integration is sending an explicit delegate-style request targeting a specific agent in the same coordinator session. Even so, the coordinator can emit top-level response text before any launch of the requested agent is observed.

This may be related to the same symptom discussed in #853, but this report is narrower: it is specifically about an explicit same-session named-agent delegation request being accepted while the coordinator still answers inline before any launch is observed.

Expected behavior

If a named-agent delegation request is accepted, Squad should do one of these:

1. Launch the requested agent and emit the corresponding subagent_started event.
2. Fail explicitly.

It should not silently continue inline with the coordinator acting on the task instead.

Actual behavior

Intermittently, the coordinator:

1. Accepts the named-agent delegation turn.
2. Resumes the correct session.
3. Starts producing normal assistant response text.
4. Continues doing the work itself.

No launch event for the requested named agent is observed.

Why this matters

For SDK/integration authors, this makes it hard to build a trustworthy UX around directed delegation.

If a user clicks something like “Have Bishop build it,” the system currently has no reliable launch-or-fail contract. The coordinator may simply continue inline, which creates ambiguity about whether delegation actually happened, concerns about the quality of work (since the coordinator may not be using the specified agent's context and charter), and questions about the purpose of having multiple agents (if the coordinator can do the work, what is the value of having other agents?).

Repro shape

This is intermittent, not 100% reproducible, but the pattern is:

1. Start a coordinator session.
2. Ask for a specific named agent to handle a task.
3. Send an explicit same-session delegation request targeting that agent.
4. Observe that the session resumes successfully.
5. Sometimes (seems like about 40% of the time), instead of launching the named agent, the coordinator starts answering inline.

Example delegate request sent by integration

{
  "type": "delegate",
  "requestId": "36dd58d1ee7f49b9967beee29f638e5f",
  "selectedOption": "Have Bishop implement it",
  "targetAgent": "bishop",
  "cwd": "D:\\Drive\\Source\\SquadUI",
  "sessionId": "8d9a9f0a-7cb1-40c9-91a8-df5fa9614572"
}

Additional context injected into the resumed coordinator session

SquadDash bridge instruction: this turn is a named-agent delegation commit triggered by a quick reply.
The user clicked the quick reply label: "Have Bishop implement it".
The quick reply explicitly targets @bishop.
You are continuing inside the same coordinator session that produced the quick reply.
Use the current session context, recent turn history, prior agent reports, tool results, and workspace files as the authoritative handoff context.
You may think and inspect context before launching if needed.
You must launch @bishop using the native subagent/tool path instead of answering inline in the coordinator voice.
Do not narrate or promise a handoff unless the launch actually happens.
If launching the target agent is impossible in this exact session, explain the concrete blocker instead of silently doing the work yourself.

Evidence from trace

In my trace, the sequence looks like this:

• quick reply / delegation request selected for a specific named agent
• same-session delegation path entered
• delegate request sent with the existing session id
• session resumed successfully
• top-level coordinator response text begins
• no matching subagent_started event is ever observed for the requested agent

In other words: the delegation turn is accepted, but the coordinator still answers before launching the target agent.

Concrete question

Is this expected behavior for Squad’s current delegation model, or is this a bug?

From an SDK/integration perspective, it would be very helpful to know whether a named-agent delegation request is intended to provide a reliable launch-or-fail contract, or whether inline coordinator continuation is currently considered expected.

Environment

• Squad used through an SDK-backed custom integration
• Same-session delegation flow
• Intermittent repro
• Observed on April 22, 2026