Agent output that sounds sure hides how little work stood behind it

Girish Konda of Microsoft argued on the AI Engineer podcast that fluent agent output hides how much work stood behind it. In WebPulse's framing, that is how AI multiplies risk when an orchestrator, the program that hands tasks to sub-agents, accepts text as proof. His fix is explicit status values and checks in code, not a warning in the prompt.

What was said

Konda's frame is that an orchestrator with sub-agents is a distributed system, so it inherits old failures. A half-finished sub-agent does not crash. It returns normal-looking text shaped like a success.

He described pointing an agent at an alert queue. Three runs gave the same answer. One pulled telemetry and compared it. One matched the alert title to titles it had seen. One did nothing. All three said benign, with equal confidence. In his words: "The orchestrator can read the conclusion. It cannot read how much work was behind it."

His made-up second example: one sub-agent writes to a shared context that an error rate fell by 80%, though it inferred this. Two others repeat it. The orchestrator sees three artifacts agree. Konda said: "Their agreement is one source counted three different times."

A call with no reply is another trap. The sub-agent may be slow, crashed, or its answer may be lost, and the orchestrator cannot tell which. He said to record that as unknown and keep the real cause.

His remedy: every hand-off ends in a named state. The orchestrator checks schema, evidence, freshness and recomputed numbers. A failed check returns a refusal with a reason. In his example, 10 errors in 1,000 requests and 6 in 600 are both 1%, so the claimed fall is refused.

Why it matters

Our reading: a prompt warning asks a fluent system to police itself, and a check the model can skip is only a request. Buyers of agent pipelines can ask concrete questions. Can a step return anything besides success, such as unknown? Does code or the model run the checks? Who owns a refusal?

Also ask what stands behind agreement. If several agents read one shared context, their matching answers may be a single guess. Ask whether the pipeline treats a timeout as a failure, a success, or an unknown.

The other side

Konda was open about limits. He said his model does not make facts true: a claim becomes checkable, not correct. It does not give exactly-once delivery, and undoing a half-finished task needs a compensation step you design.

There is a price. He said it chooses consistency over availability for writes, so it refuses rather than guesses. Each freshness check costs an extra read, and someone must be named to handle each refusal.

He also said it does not suit every case. When an agent only writes a draft that a person reviews before any action, he said most of this is extra weight. It assumes one orchestrator; peer agents with no central point need something else.