You spawn a sub-agent to handle background work, the tool returns a run id, and then nothing happens. No completion event. No result in the channel. The task just sits there, silent, eating your patience and your tokens. This is the most common multi-agent failure there is, and it is almost never a model problem.
Sub-agents fail silently because spawning is fire-and-forget by design. The parent agent hands off work, gets an id back, and moves on. If the child never finishes, never reports, or crashes before it starts, nothing screams. The work just evaporates, and you only find out hours later when the output you expected is missing.
This guide covers the four ways sub-agents go quiet, how to diagnose each one in under ten minutes, and the config rules that stop it happening again. If your sub-agents spawn but never deliver, start here.
Symptom 1: The Spawn That Never Starts
The most common silent failure is a spawn that returns success but never actually runs. You get a run id and a child session key, and then the child does nothing. No logs, no output, no error.
The usual cause is a fire-and-forget spawn with no wait and no completion contract. When you spawn a sub-agent with a zero timeout, the parent gets the id immediately and the child is enqueued. If the child then fails to start (model misconfigured, tool permission denied, workspace issue), the failure goes nowhere. There is no completion event because there was never a wait.
How to diagnose it: Check the child session log, not the parent. The parent log will show a clean spawn. The child session shows whether the run actually began. If the child session does not exist or is empty, the spawn never started.
How to fix it: Always decide the completion contract before you spawn. If you need the result, wait for it with a timeout. If you genuinely want fire-and-forget, add a verify step later: check the child session or the output file the child was supposed to write. Fire-and-forget is fine, but it is not “set and forget.”
Symptom 2: The Run That Hangs Forever
The child starts fine, and then stalls. A tool call never returns, the model loops, or the task is simply too big for the context window and the child keeps churning. From the outside it looks identical to Symptom 1: no result, no completion.
The difference is visible in the logs. The child session shows activity: tool calls, token usage, a growing transcript. It is working, it is just not finishing.
How to diagnose it: Check the child session transcript and compare timestamps. If the last tool call was twenty minutes ago and nothing happened since, it is hung. If token usage is still climbing, it is still working, just slowly.
How to fix it: Every sub-agent needs a timeout, full stop. A spawned task that can run forever is a resource leak with a heartbeat. Set a timeout that matches the task, and design the task so a timeout is safe: the child writes progress to a file or a task registry as it goes, so a kill does not lose everything. Our guide on debugging agent teams covers exactly this pattern, and the same rules apply to a single orphaned sub-agent.
Symptom 3: The Completion Event That Never Arrives
The child finishes. The transcript shows a clean completion. But the result never reaches you. No event in the parent session, no message in the channel, nothing.
This is a routing failure, not a run failure. The sub-agent completed its work but the completion event went somewhere you were not looking. This happens with fire-and-forget spawns (there is nothing to deliver to), with thread-bound spawns where the completion posts to a thread nobody watches, and with spawns that lose their route back to the requester.
How to diagnose it: Read the child session to the end. If the final entry says the task completed, the run was fine and the delivery failed. Check where the completion was supposed to post: the requester channel, the bound thread, or nowhere.
How to fix it: Do not rely on completion events for critical work. Have the sub-agent write its result to a file or a task registry as its final step, and have the parent verify that artifact after the wait. Completion events are a convenience, not a guarantee. If you need the result in a specific place, make the child put it there directly.
Symptom 4: The Child That Dies Instantly
The spawn returns, the child session exists, and it contains one line: an error, then silence. The sub-agent crashed before doing anything useful.
The usual causes are a model that the child cannot use, a missing tool permission, or a context fork that pulled in something the child could not handle. The child fails fast, and because the parent already moved on, the failure is invisible.
How to diagnose it: Read the first few entries of the child session. The error is usually on line one or two. Model errors and permission denials are the most common, and both are usually obvious once you look.
How to fix it: Give the child a narrow, explicit brief and verify it can actually run before you build a pipeline around it. Test the spawn once with a trivial task, confirm the completion path works, then scale up. This is the same lesson as our sub-agents hands-on guide: a sub-agent is only as reliable as the brief you give it.
The 10-Minute Diagnostic Workflow
When a sub-agent goes quiet, work through this order. It covers all four symptoms and takes under ten minutes:
- Confirm the spawn happened. The parent log should show a run id. No id, no spawn, start there.
- Check the child session exists. No child session, or an empty one: the spawn never started (Symptom 1).
- Read the first lines of the child session. An early error means the child crashed on startup (Symptom 4).
- Read the last lines of the child session. A clean completion means the run worked and delivery failed (Symptom 3). Stale timestamps with no progress means a hang (Symptom 2).
- Check the artifact, not the event. Whatever the child was supposed to produce, check it directly. If it exists, you have your result. If it does not, you have your answer.
The step that saves the most time is the last one. Stop waiting for completion events and check the output. Events are how the system tells you things. Artifacts are the actual work.
Prevention Rules That Stop All Four
Steal these rules and most of this article becomes unnecessary:
- Every spawn has a timeout. Zero timeout is a deliberate choice, not a default. If you use it, add a later verify step.
- Every sub-agent writes an artifact. File, task registry entry, database row. The child’s last step is always to persist its result somewhere the parent can check.
- Test the spawn path before the pipeline. One trivial task, confirm start and completion, then scale.
- Check child sessions, not parent vibes. The child transcript is the ground truth. Read it.
- Never rely on the completion event alone. Treat it as a notification, not a delivery.
None of these are complicated. They are the same ownership rules that make any distributed system reliable, applied to agents. A sub-agent is just a process that talks like a colleague. Treat it like one: give it a clear task, a deadline, and a way to hand back the work.
The Verdict
Sub-agents do not fail because the model is bad. They fail because spawning is designed to be fire-and-forget, and fire-and-forget has no error handling. The fix is not a better model. It is a completion contract: timeout, artifact, and a parent that checks the work instead of waiting for a message.
Decide the contract before you spawn, and the silent failures become loud ones. Loud failures are fixable. Silent ones just cost you hours. If you are weighing whether the whole team approach is even worth it, our multi-agent overkill guide covers when one agent is the right call.
Sub-agents are the building blocks. Learn how to delegate hands-off tasks that actually come back, and how to design agent teams that do not fight, loop, or lose work.
About The Author
