The real failure mode isn't bad code

Most debates about AI coding agents focus on model quality — is the code good enough? Teams that have actually put an agent into their delivery loop usually run into a different problem first.

When a requirement is ambiguous, the agent doesn't stop. It picks an interpretation and ships it with the same confident tone it uses for unambiguous work. Two weeks later someone asks "why does this field default to false?" and the honest answer is that nobody decided — nobody was even asked.

That's not a model-quality problem. It's a workflow problem: there is no place in the loop for "I'm not sure," and no gate between the agent's output and "done."

What ask_human actually does

WKFGo exposes an ask_human tool over MCP. When an agent hits a genuinely ambiguous acceptance criterion — one where different readings lead to different implementations — it calls ask_human instead of picking one and moving on.

The question gets attached to the task as a blocking item, not dropped into a chat channel that scrolls away. A human answers from the task page. The reply lands back in the agent's context pack (get_context_pack), so it can resume with the actual decision instead of its own guess.

The difference from "the agent asks in chat" is where the answer lives afterward. It's on the task, in the task's history, searchable. Six months later, when someone asks why a field is optional, the answer is sitting next to the code that implements it — not buried in a conversation nobody can find.

If nobody answers, the task simply stays blocked and shows up in aging reports. That's the intended behavior, not a failure state — a stalled question is a much cheaper problem to notice than a wrong guess that ships.

Why teams skip this and pay for it later

Three patterns explain most of the pain:

No instruction to ask. Left to its own judgment, an agent treats a half-finished task as a failure and defaults to guessing rather than stopping. The fix is explicit, in the agent's instructions: "If acceptance criteria admit more than one reading that leads to different implementations, call ask_human and wait — do not guess."

Nobody owns the queue. A question that sits unanswered for three days makes the agent useless regardless of how good the underlying model is. Someone has to be responsible for clearing blocked questions, the same way someone owns a review queue.

The agent works from stale or missing context. Without get_context_pack at the start of a task, the agent doesn't have the acceptance criteria in front of it in the first place, so it can't tell the difference between "ambiguous" and "just needs more digging."

Setting it up

Give the agent an identity. In WKFGo this is the is_agent flag on a user account, created and scoped by a human (recorded in minted_by). Everything the agent does — including its questions — is attributed to that account, not borrowed from a teammate's key.

Scope its access. Read tasks, update status, comment. Skip finance and user management until there's a reason not to.

Write the ask-when instruction explicitly. This is the step most teams skip. Something like: "Call get_context_pack before starting and read the acceptance criteria. If there's ambiguity that would change the implementation, call ask_human and wait for the reply before continuing."

Own the response queue. If questions sit unanswered, the practice dies — not because the tool failed, but because nobody treated the queue as work.

What to measure

Questions asked per task. Zero is a warning sign — it usually means the agent is guessing instead of asking. A very high number usually means the tasks themselves are too vague or too large.

Time a question sits blocked. This is the number that degrades first and quietly slows the whole loop down.

First-pass approval rate on work the agent submits via submit_for_review. A low rate is rarely a model problem — it's usually acceptance criteria that were never specific enough to answer without guessing.

None of these are "AI quality" metrics. They're workflow health metrics, which is the actual point.

Anti-patterns

No ask-when instruction. Without one, the agent defaults to guessing because leaving a task half-done reads as failure to it.
A review queue with no owner. Creates a new bottleneck, and the team concludes "the agent is slow" when the real issue is an unattended queue.
Sharing a human's key with the agent. Breaks attribution and makes later audits impossible.
Tasks too large or vague to have a single answer. "Rewrite the auth flow" doesn't have one ambiguity to resolve — it has dozens, and ask_human becomes noise instead of signal.

FAQ

Does this replace a developer? No — the opposite. Every piece of agent work still goes through a human review gate (submit_for_review). What shrinks is repetitive implementation work, not judgment.

What happens if nobody answers the question? The task stays blocked and shows up in aging reports. That's by design — better to see a stalled question than discover a wrong guess two weeks later.

Can more than one agent use this? Yes, no limit. Some teams run one agent per domain (backend, frontend) with different access scopes.

Does this only work with WKFGo's own IDE integration? No — any MCP-connected editor can call ask_human the same way it calls other WKFGo tools.