When the Worker Needs to Ask the Supervisor a Question

Most multi-agent designs are one-directional: the supervisor delegates, the worker executes and returns. What happens when the worker hits something it can't resolve is usually unspecified — and unspecified means the worker invents an answer, because that's the only path available to it.

The delegated task was written before anyone knew what the worker would find. Some fraction of the time it will be underspecified, and that fraction is where the design either holds or quietly produces wrong work.

Three things a worker can do when blocked

Guess and proceed. The default when nothing else exists. Fast, and the guess is invisible in the returned result — the worker reports success and the assumption never surfaces.

Fail the subtask. Honest but wasteful. The supervisor gets an error, has to reconstruct what happened, and often re-delegates with a marginally different brief.

Ask. Requires a channel back, which most designs lack.

Only the third preserves both the work done and the accuracy — and it's the one that needs deliberate design.

Return a question as a result type

The clean implementation avoids any new channel: make "I need something" one of the shapes a subtask can return.

{ status: "needs_input",
  question: "Order A-4471 has two line items already refunded.
             Refund the remaining three, or the full original total?",
  options: ["remaining_three: 412.00", "full_original: 690.00"],
  work_so_far: { verified: [...], pending: [...] },
  blocking: true }

The supervisor sees this as an ordinary result, answers it, and re-invokes the worker with the answer and the preserved work. No new plumbing, no bidirectional channel, and the exchange appears in the trace like everything else.

Two fields do the heavy lifting. options turns an open question into a choice, which supervisors answer far more reliably than free-form queries. work_so_far is what makes asking cheaper than failing — without it, answering means the worker restarts.

Whether the supervisor can even answer

The uncomfortable case: the supervisor doesn't know either. It delegated precisely because it didn't have the details.

The design needs a defined path for this, or you get a question bouncing between agents, each deferring to the other, burning turns. Options:

• Escalate to a human, carrying the accumulated context from both agents.
• Answer with an explicit default and record it — "assume the remaining three; flag it in the final report." The decision is made and visible, which is far better than an invisible guess.
• Return the question to the requester if the run is interactive.

⚠️ The rule that prevents the bouncing: a question may be passed up the hierarchy, never sideways or back down. Sideways delegation of an unanswerable question is how multi-agent systems livelock.

Cap it

Question-asking needs the same budgets as everything else:

• A maximum per subtask — two or three. A worker asking five questions received a task that shouldn't have been delegated in this form.
• A total per run, so a whole fleet of workers can't collectively stall the supervisor.
• Non-blocking questions where possible. Not every uncertainty must halt the work; a worker can proceed under a stated assumption and report the assumption alongside its result. This is the underused middle option: status: "done_with_assumptions" carrying the list, so the supervisor can review rather than pre-authorize.

🔍 Questions are a design signal

The most valuable thing about implementing this is what the questions tell you.

Log every one. Cluster them. A question asked repeatedly across runs isn't a worker problem — it's a gap in the delegation template, and the fix is to include that information in the brief so it's never asked again.

Teams that run this loop find their question rate drops sharply over a few weeks as the recurring ones get designed out. What remains is the genuinely case-specific residue, which is exactly what the mechanism should be handling.

✅ The related metric: the fraction of questions where the supervisor's answer differs from what the worker would have guessed. High means asking is preventing real errors. Near zero means the threshold is too low and workers should proceed with a stated assumption instead.

The takeaway

A worker with no way to ask will guess, and the guess won't be visible in what it returns. Make "needs input" a result type carrying the specific question, concrete options, and the work already done; allow questions only upward; cap them; and prefer stated assumptions over blocking where the stakes allow. Then log what gets asked — the recurring questions are a to-do list for improving the delegation itself.