A Running Task Column Isn't Execution: Evidence Separation in Agent Task Systems

A task board needs a running column to support workflow collaboration—someone has claimed a card, or the team wants a visual sense of progress. But a board column is a declaration about process, not evidence that the process is still active. This distinction is especially critical in agent systems.

A task may remain in the running column after a runtime session has ended; an agent may be active on a task thread while the card still shows pending; a human can also manually drag a card for planning purposes. If a dashboard interprets any of these situations as "work is actually happening," it is reporting a level of confidence it has not actually earned.

APX's design separates these two concerns: the task workflow records the column an open task has been placed into, while the execution view answers a different question—what evidence exists right now?

One Label, Many Realities

Suppose a task card titled "Review the authentication flow" is sitting in the running column. There are at least four possible realities:

• An agent turn is currently working on that task thread
• A linked coding runtime session is still open
• The linked session has completed or failed
• There is no associated activity at all; the card was moved earlier and never changed again

Only the first two support "work is happening." The third supports "execution has ended." The fourth supports only "not verified," not "ran successfully."

This is exactly why APX does not treat a status field as a liveness signal. Its task execution view combines specific sources of evidence: the currently running agent turn, runtime sessions explicitly linked from task comments, and recent activity (such as comments, or session start/end). When no evidence is live but the workflow column shows running, the conclusion is not_verified.

The wording is deliberately less reassuring than a green dot. It tells the task owner exactly what the system knows, without pretending to know more.

not_verified is a deliberately conservative state semantic. In monitoring and observability systems, a three-state model is typically used instead of a binary "healthy/failed": healthy, failed, unknown. Collapsing "unknown" into "healthy" produces false reassurance, while collapsing "unknown" into "failed" triggers false alarms and unnecessary intervention. not_verified belongs to the third category—it does not claim the task is fine, nor does it claim the task is dead; it only states that the evidence currently available to the system is insufficient to support any assertion. In distributed systems, this design is known as the "fail silent vs fail loud" trade-off: if a stale card stuck in the running column is not identified as unverified, a subsequent agent might start duplicate work on it, or a human reviewer might mistakenly assume a colleague is handling it and skip it. not_verified makes this gray area explicit, allowing automated systems to route it to human confirmation or degraded handling rather than guessing.

Check the Task Before Reporting Progress

For agents, the practical rule is simple: when the title or board column is not enough to answer the question, use get_task. The returned result contains an execution object that separates workflow information from runtime information. This lets a useful progress report distinguish between cases like the following:

Workflow: running
Execution: working
Evidence: linked runtime session is open

Workflow: running
Execution: not verified
Evidence: no live task turn or linked open session

Workflow: in_review
Execution: ended
Evidence: latest linked session finished

These are not decorative wording adjustments; they lead to different follow-up actions. "working" may mean waiting or checking an active session; "not verified" means checking the task thread, asking the owner, or figuring out what happened before moving the card; "ended" means reading the result and reviewing it—not automatically closing the task.

In particular, note that a process exiting successfully does not equal business approval. A runtime can exit with code 0 while producing only a draft, an incomplete investigation, or a result that requires human review. APX keeps execution evidence separate from task closure, preventing an agent from quietly translating "the command finished" into "the work has been accepted."

Why Links Must Be Explicit

APX finds runtime sessions related to a task through task comments that carry session identity and paths. This is much narrower than scanning all agent history, which both prevents unrelated sessions from making a task appear active and ensures evidence attaches to the card where reviewers expect to find it.

The same boundary also explains the role of APC. APC is the portable project context layer: AGENTS.md, agent definitions, skills, and persistent rules travel with the project. APX, by contrast, is the runtime and tool layer used day to day: it places local sessions, task activity, and execution evidence outside that portable contract.

A portable task instruction can state what conditions success must meet, but only the runtime can say whether a specific session is still alive.

AGENTS.md is an agent-oriented project context convention file, usually placed at the repository root, used to describe project structure, build commands, testing methods, code style constraints, and operational rules the agent should follow. It is similar to CONTRIBUTING.md for human contributors, but its readers are agents. APX and APC's layered approach borrows from the principle of separating declaration and state in "configuration as code": APC provides a portable, version-controlled instruction contract that travels with the repository and describes "what success should look like"; APX handles "what is actually happening right now," the transient, local, non-portable runtime facts. Mixing the two can lead to instruction files polluted by runtime noise, or runtime evidence being lost when migrating across environments.

A Better Way to Ask About the Board

When you see a task card in running, don't just ask "which column is it in?" Ask "what evidence shows that it is running right now?"

This small separation leads to calmer automation: avoid starting duplicate work on active tasks, expose stale cards before they turn into false reassurance, and keep approval authority where it belongs—with review of the actual result.

The board tracks workflow, evidence tracks execution. Reliable agent operations need both.

One-line Summary

Board columns declare process; execution evidence shows whether it is actually running. APX separates the two to avoid false confidence.

Paragraph Summary

The article points out that the running column on a task board is often misread as evidence that a task is executing, when it is really only a workflow declaration. A card stuck in running may correspond to four very different realities: an agent turn is working, a linked session is still open, the session has ended, or there is no associated activity at all. APX separates the workflow view from the execution view, determining execution state by combining the current agent turn, explicitly linked runtime sessions, and recent activity. When the column shows running but there is no live evidence, it returns not_verified rather than success. The author emphasizes that an exit code of 0 does not equal business approval, runtime sessions must be explicitly linked through task comments, and the right question is "what evidence shows that it is running right now?"