An async agent finished during approval. Keep the action on hold.

An open question with one documented implementation

In his October 31 article, Harrison Chase identifies asynchronous work as one of several remaining context-engineering challenges. Long-running tools and subagents can finish while the main agent is busy, finished or paused for human approval. He asks how those results should reach the agent. His account describes conversations with builders and his own judgment, rather than a representative survey or measured failure rate.^[1]

LangChain's October 29 Managed Deep Agents v0.10 release describes three cases. A busy agent checks unfinished tasks before each model call, receiving results mid-run. An idle agent is awakened with a new run. An agent paused on approval keeps that approval untouched; the result arrives once the user answers. These are vendor-described public-beta behaviors, not a locally tested guarantee or a policy for every harness.^[2]

That distinction gives you a concrete engineering task: specify the relationship between a completion event and an unresolved action. The release describes delivery timing. It does not establish revision-aware approval or duplicate-event guarantees. The following exercise proposes checks for those separate questions without attributing them to the product.^[1][2]

Predict the action in this fictional timeline

This is a static invented example. No SDK, model, email or external account was run. Research subtask R1 supports version v1 of a draft. The main agent asks for approval to send v1 and pauses. While approval remains unanswered, R1 finishes. The user then says to keep the work draft-only. Later, the same completion event is delivered twice. Decide what action is permitted before reading the diagnosis.^[1][2]

The permitted outcome is no send. Retain one completion record, inspect the result and reconcile it with the draft-only instruction. R1 finishing supplies information; it supplies no permission to send. The old request concerned a particular revision and action. A later changed instruction cannot be ignored just because a background worker completed its earlier assignment.^[1][2]

Keep the distinction precise when implementing your own policy. A completed task can be recorded even when its result cannot yet be applied. A result can be relevant to a draft without authorizing delivery of that draft. If the user later approves sending, check the exact current content and action covered by that approval. This is our proposed authority rule, not a reported LangChain test result.^[1][2]

Record enough state to explain the decision

For this exercise, a filled event record reads: task R1; starting revision v1; current instruction draft-only; completion event C1; main state approval-paused at completion; pending target send-v1; action held. Record the user's changed instruction separately from the worker's result. Otherwise the completion text can obscure which instruction currently governs the action.^[1][2]

A proposed implementation would also retain the current revision, the approval's revision-and-action target and whether the event has already been processed. Those fields support different checks: is this a new event, does its result still apply, and is the requested action allowed? They are a design starting point. Merely logging these fields does not enforce the policy or prove correct behavior.^[1][2]

Replay the cases that a happy path misses

Walk through three proposed cases on paper first. Duplicate: C1 arrives again, so no second processing or action should follow. Stale: R1 began from v1 while the current draft is v2, so hold application pending reconciliation. Canceled: the task is canceled before a late completion arrives, so record that lateness and apply an explicit discard-or-review policy. None of these events answers a pending send approval.^[1][2]

The release describes task cancellation tools and a thread Stop button, but it does not settle the late-completion policy above. To test your own implementation, preserve the event order, expected final draft, approval target and external-action count for each case. Include a normal approved case so a system that blocks everything cannot pass. Use a harmless substitute for sending while you test.^[2]

A useful portfolio artifact is the timeline, the filled state record and, once actually executed, the replay results. Label reasoning separately from tested behavior. Chase's open question can guide that work without proving that a particular design is safe or improves hiring outcomes. The deliverable here is a static exercise and proposed test plan, with no executed integration claimed.^[1][2]