Why Your Agent Stuck at 'Processing': Designing Observable Task Status & Business Results

Clarify Which Thing Actually Completed

Using a procurement example: an Agent verifies budget, supplier, and contract, obtains user confirmation, submits for approval, tracks the approval result, and notifies the applicant. This entire work is called a Task . Operations that produce business consequences — such as submitting approval or sending notifications — are called Actions . Conversations with the user belong to Session (meeting management). These three terms map to three distinct concerns.

When the model finishes generating an approval summary, only that generation ends. When the approval system returns an instance ID and acknowledges receipt per the interface contract, the submission action is complete. After the approver decides, the task must still send the notification per the task contract before the whole work can be considered finished.

Logs that merely say "success" are insufficient; they must record which step succeeded and on what evidence. An approval rejection does not necessarily mean the Agent task failed. If the goal is to accurately submit, track, and inform the result, correctly notifying the rejection may satisfy the delivery requirement.

When a task is confirmed cancelled or stops executing after failure, it should exit "processing" while preserving completed portions and pending actions. A newly issued cancellation request or a single failed call does not mean the entire task has stopped. For example, "Cancelled, original submission pending verification" is more accurate than "Fully revoked": stopping further execution does not erase external consequences.

"Processing" Must Explain What It Is Waiting For

During troubleshooting, the first questions are: which step is it stuck at, why is it stuck, and who handles the next move. The following situations can coexist; design should record execution phase, wait reason, and action result separately rather than stuffing everything into a single status field:

Queuing

Required evidence: Scheduling records, enqueue time

Wait reason & responsible party: Waiting for execution resources; scheduler responsible

Verifying materials

Required evidence: Current execution step, accepted verification results

Wait reason & responsible party: Execution program continues; missing materials handed to relevant personnel

Waiting for user confirmation

Required evidence: Content and version awaiting confirmation, confirmation request record

Wait reason & responsible party: Waiting for authorized user response

Waiting for approval result

Required evidence: Approval instance reference, latest authoritative query result

Wait reason & responsible party: Approver processes in business system; task service continues tracking

Submission result unknown

Required evidence: Original action identifier, submission evidence, timeout or exception records

Wait reason & responsible party: Recovery process verifies; escalate to responsible person if needed

Pending confirmation content, approval instance, and original submission records must be directly retrievable. When acceptance evidence is missing, show "pending verification" instead of assuming approval failure.

Status comes from the task execution program and business records; the model only explains it to the user. If the business system's acceptance evidence cannot be found, the model's claim "I am waiting for approval" is unfounded.

Wait duration starts when entering the current phase; polling or log refreshes must not reset it. Alert thresholds follow business agreements: contract retrieval and human approval cannot share the same standard.

Activity Does Not Equal Progress

Suppose an Agent queries a contract eight times consecutively; each tool call returns normally but the missing attachment is never retrieved.

Calls keep happening, yet the critical gap remains unfilled. If every tool response refreshes "last updated time", the task may appear perpetually active.

I record two separate timestamps: the latest execution activity (heartbeats, model returns, tool calls) and the latest evidence‑backed task advancement (a verification produced a valid result, user completed confirmation, or business system confirmed a new state).

A model writing an extra summary does not guarantee progress change; discovering a new contract conflict is valuable — it shows verification moved forward even though submission is still blocked. Judging progress requires returning to the problem this step was meant to solve.

Long absence of advancement warrants a prompt for further investigation, but cannot automatically declare the Agent stuck in a dead loop. Lengthy materials or slow dependencies can produce the same symptom. Combine current step, repeated calls, unresolved issues, and execution budget checks; then let controlled execution rules decide whether to stop or hand off to a human.

When no new logs appear, distinguish whether execution halted or data collection broke. The UI should simultaneously indicate task status and data completeness.

A Task Card Should Tell You Where to Look First

Instead of estimating "80% complete", I prefer placing an observation card in the task details. Dynamic re‑checks and human waits are hard to convert into accurate percentages.

Below is a schematic example (times and IDs are illustrative):

Task: Verify purchase request, submit approval, notify result
Business basis: Purchase request v3 and corresponding confirmation records
Latest valid progress: 16:10 Approval system accepted, instance A-17
Execution phase: 16:10 Entered waiting for approval result, notification not yet sent
Latest successful verification: 16:12 Queried A-17, approval still in progress
Data freshness: 16:14 Query failed; as of 16:15 no updated result
Responsibility split: Approver handles approval, task service verifies status
Next actions: Continue verification within limited attempts and time limit, then escalate to responsible person
Evidence entry points: Submission records, confirmation basis, instance queries, call logs

The 16:12 query showing unchanged status does not count as new task progress; the 16:14 query failure does not overturn the already‑accepted fact. The card should display the latest confirmed result and subsequent re‑check status, not pretend to have real‑time state.

User view can be simpler, e.g., "Approval accepted, latest result not yet retrieved". Investigators need access to corresponding records. Both views must respect permissions; a diagnostic page should not expose all contracts and business materials.

When Status Changes, Evidence Must Change With It

This card can be generated from reliable task records and business query results, and must be rebuildable if lost. Model summaries may be used for explanation, but cannot fabricate missing acknowledgments or receipts.

Status events may arrive late. For instance, the approval system produced a result at 16:20, but the 16:12 "approval in progress" event arrives at 16:21. Updating by receipt time would roll the UI back to "approval in progress". Therefore, records must retain source, object version, and event occurrence time alongside receipt time; then rely on source system version, event ordering, or re‑query to determine recency.

Business input changes also need clarification. If the user modifies the request amount, the budget check completed against the old amount remains a historical record but must not be displayed as if the new request has passed verification. Actions originally issued against the old version must keep their association and not disappear when the page switches.

When source system results conflict with local records, highlight the discrepancy and investigate. Reliable state and action records are required to resume execution; ordinary logs or sampled traces cannot replace them.

Handing Off to Humans: Pass a Scene They Can Continue Investigating

If a task escalates to a human with only "Execution exception, please handle", the assignee still has to guess from scratch.

Take "submission result unknown" as an example. Handoff information must include at least: what was to be submitted, which preconditions were confirmed, the action identifier used, what has been queried so far, and which subsequent steps are paused.

Who it was assigned to, when it was dispatched, and whether it was accepted must all be traceable. If notification is sent but no one picks it up, the system should continue escalating, not stop tracking.

The responsible person must distinguish between consequences that have already occurred and items still pending verification. A temporary lack of query results must not be recorded as "never submitted"; pausing a task must not be written as "external request revoked". Re‑execution still requires the same checks; suggestions on the diagnostic page do not constitute new authorization.

Use Several Types of "Not Done" to Validate the Design

To verify this card, arrange three "not done" scenarios in a test environment: normal approval wait, repeated tool calls without fulfilling material requirements, and external system already accepted but submission receipt lost.

The first should surface the approval instance, latest verification result, and handler. The second should show ongoing calls but highlight which requirement remains unsatisfied. The third should preserve the original action, enter verification mode, and not display a definite failure prompting re‑submission.

Also check whether polling resets wait time, whether unassigned human handoffs remain traceable, and whether collection interruptions flag incomplete information. If a cancelled task later receives an external receipt, retain the real consequence and do not automatically revive cancelled subsequent steps. Validation must cross‑check actual records, not just the Agent's explanation.

Short‑lived read‑only Q&A does not need the full card; clearly showing what is being queried, result sources, and error causes may suffice. Complete progress and consequence records become necessary for long tasks, human waits, or external writes.

When another person takes over, they should see whether to wait, to query, or to supplement materials — that is when this card proves its worth.

Records may be scattered across yesterday's and today's execution segments. The next article will explore how to stitch these Traces (call chains) under a single task.