The latest OpenHands/OpenHands commit gives an automation run a second verdict. A run may be completed while its task is blocked, partial, failed, or needs review; ending a process is no longer automatically read as success.
The public patch centers on finish_tool_response. When it carries a recognized task status and outcome summary, OpenHands gives it a separate badge and explanation. In its focused fixture, the lifecycle is COMPLETED, the task is BLOCKED, and the system detail is a missing HubSpot credential. The run-log view now shows three layers instead of treating an execution error or a terminal lifecycle label as the whole story.
Three facts, not one status chip
The lifecycle record still answers a useful question: did the runner stop? But the new display helper gives a known task result priority. An unfamiliar or incomplete finish payload becomes needs review; only a completed run with no finish payload is shown as success. The distinction reaches home cards, the activity sparkline, run logs, and the automation-health calculation.
Its tests expect a latest completed-but-blocked task to make an automation failing. Partial and unknown outcomes are not quietly called healthy. That makes the health state a task-outcome reading, rather than a restatement of whether the runner emitted a terminal lifecycle value.
That is a reporting move, not merely a design refresh. Agent automations increasingly sit beside human operations, where “the job ended,” “the task was blocked,” and “the platform had an execution error” lead to different next actions. One undifferentiated success rate can hide each of those distinctions. Separating them gives an operator a better question to ask after a green-looking run: did the system finish, or did the work finish?
The audit question behind the patch
The source does not show a customer incident, a release, or a universal standard for agent telemetry. It shows OpenHands’ intended main-branch behavior and fixtures. Still, the next signal is precise: check whether an automation product records a task-owned outcome separately from lifecycle and system state, then inspect what its health metric does with a completed task that reports blocked. If one field is asked to answer all three questions, it may be compressing away the answer an operator actually needs.