THE EFFECTIVE AI ENGINEER
A Case-Based Approach
CASE #023The Engineer Who Checked Before Resuming
Choose Work That Matters
By Ravindra Dastikop
AIYING — Accomplishing with AI
The agent had saved its progress. Had the organisation preserved its permission to continue?
1. The current engineering challenge
AI agents increasingly perform work in the background while a user continues the conversation, changes requirements or starts another task.
LangChain’s Agents Are Going Async, published on 5 November 2026, describes an architecture in which a user-facing orchestrator stays available while background subagents work independently. It also discusses task updates, cancellation and approval handling. The article identifies task notifications as beta functionality. [1]
That architecture creates a practical design question:
When a background agent resumes, how does it establish that its next action still matches the user’s current intent?
This case focuses on changing instructions and the validity of an approved action. Reliable execution must account for what happened while the worker was waiting.
2. Audience and learning outcomes
- Freshers and students: distinguish saved progress from permission to act.
- AI builders and developers: design background tasks that tolerate changing instructions.
- AI and harness engineers: implement task versions, approval boundaries and cancellation states.
- Freelancers and consultants: define what a client has authorised an assistant to do.
- Managers and faculty: examine accountability when approval and execution occur at different times.
Prerequisites: basic familiarity with agents, APIs, workflow state and human approval.
After studying the case, learners should be able to:
- Identify how background work becomes stale.
- Bind approval to a specific proposed action.
- Distinguish cancellation requested from cancellation confirmed.
- Design a check immediately before an external action.
- Explain when work can be reused and when approval must be renewed.
3. The story: an approval overtaken by events
CedarWorks Services coordinated equipment maintenance across several offices. Its operations team spent substantial time finding technicians, checking access windows and preparing appointment confirmations.
Meera, an AI engineer, built an assistant that could read a maintenance request, research providers, compare appointments, prepare a booking and ask a supervisor for approval. Following approval, it could submit the booking through a vendor API.
Initially, the assistant handled one request at a time. A slow provider search left the supervisor waiting.
The team introduced background workers. The supervisor could now continue working while the assistant searched for appointments.
During demonstrations, the improvement was obvious. The assistant stayed responsive. Several searches could progress independently.
Then Meera tested what happened when a request changed while a worker was waiting.
“Arrange maintenance for the cooling unit at the North office on Friday morning. Prepare the booking for approval.”
The assistant created request version 1. A worker found a technician and prepared a booking. The supervisor approved it, but submission remained queued.
Before submission began, the facilities manager reported that the North office would be inaccessible on Friday.
The supervisor told the assistant:
“Change it to the South office on Monday afternoon. Keep the same maintenance scope.”
The conversational assistant acknowledged the change. However, the queued worker still held the earlier approved action.
When it resumed, it was ready to book the North office for Friday.
Its stored information appeared consistent: a request existed, a provider had been selected, approval had been recorded and submission remained incomplete.
But those records described an instruction the user had replaced.
4. Exhibit A: one task, two versions
Illustrative teaching timeline; these are fictional events.
| Time | Event | Implication |
|---|---|---|
| 09:00 | North office, Friday morning requested. | Version 1 created. |
| 09:06 | Worker prepares booking. | Proposal belongs to version 1. |
| 09:08 | Supervisor approves proposal. | Approval covers that proposal. |
| 09:09 | Submission waits in queue. | External booking has not occurred. |
| 09:11 | User changes location and appointment window. | Version 2 supersedes version 1. |
| 09:12 | Assistant acknowledges update. | Conversation reflects version 2. |
| 09:14 | Original worker resumes. | Pending action still reflects version 1. |
The defect was a disagreement between the current request and the pending action.
5. The decision point
The product manager argued:
“The supervisor already approved the maintenance. We should avoid asking again.”
The operations lead disagreed:
“I approved a specific visit. The location and time were part of that decision.”
Meera considered three options.
| Option | Benefit | Limitation |
|---|---|---|
| Resume the previously approved booking. | Fast; uses existing approval. | Acts on superseded instructions. |
| Replace booking details and reuse approval. | Avoids another approval request. | Changes what the supervisor reviewed. |
| Retain useful research, invalidate the old action and review the revised proposal. | Preserves useful work and respects the change. | Requires explicit version and approval handling. |
Stopping every worker whenever any message arrived was another possibility. However, an unrelated question should not necessarily invalidate maintenance work.
What should happen to the queued booking, the earlier approval and the provider research? Define your answer before reading the worked analysis.
6. What published sources establish
LangGraph’s interrupt documentation explains that an interrupt saves graph state and waits for input. Its documentation also explains that resuming an interrupted node restarts that node from its beginning, making the treatment of side effects important. Code executed before the interrupt must be safe to repeat. [2]
Persistence and checkpoints support retaining execution state and recovering workflow progress. [3]
The application-level inference: the system must additionally establish whether the proposed action remains valid under current instructions. A persisted approval record alone cannot answer that business question.
The sources support the technical context. The fictional incident and the following control design are teaching constructions.
7. The thinking shift
Hidden assumption: if a task can resume from saved state, its earlier permission remains sufficient.
PO — a deliberate provocation: “The agent may remember everything and still have no permission to continue.”
This statement is used to generate possibilities. It is not a claim that every resumed task needs a new human approval.
Movement: separate the information needed to continue working from the authority needed to perform an external action.
- Research can remain useful after a request changes.
- A proposal can become obsolete while its supporting research remains useful.
- Approval can cover a specific action or an explicitly defined range of actions.
- A worker can finish successfully while producing an unusable result.
Discovery: resumption should include a decision about applicability, rather than relying only on the presence of saved state.
This is the author’s lateral-thinking application to the engineering problem.
8. Worked analysis
Meera chose to retain useful research while invalidating the old proposal and approval. She separated three concepts:
- Research: information collected while preparing an action.
- Proposal: the exact action presented for review.
- Authority: permission to execute that proposal under stated conditions.
Changing the office and appointment window invalidated the booking proposal. In this application, the approval covered those details, so it also became unusable.
Some provider research could remain useful. A provider’s service coverage might still apply, while its Friday availability would require another check.
The system marked the first proposal as superseded, prevented it from reaching submission and prepared a replacement.
The supervisor could then receive this message:
“The earlier booking has not been submitted. Your change replaces the approved location and appointment window. I am preparing a revised proposal for review.”
That wording is appropriate only after the system has established that submission has not occurred.
9. A proposed approval contract
For CedarWorks, an approval should identify what the person reviewed and the conditions under which it may be used.
| Field | Purpose |
|---|---|
| Task ID | Identifies the maintenance workflow. |
| Request version | Identifies the applicable instruction. |
| Proposal ID and version | Identifies the reviewed action. |
| Action details or digest | Binds approval to particular booking content. |
| Approver identity and authority | Establishes who approved and whether they could approve. |
| Approval time and validity conditions | Defines when approval may be used. |
| Approval status | Records approved, revoked, expired, superseded or consumed. |
A digest can bind a record to particular content. It does not establish that the content is correct or authorised.
CedarWorks required renewed approval for changes to location, appointment window, provider or maintenance scope. Another application might permit a bounded range of choices, provided those boundaries were explicit when the person approved.
10. Check at the action boundary
Immediately before booking, the execution service should establish that:
- The task remains active.
- The proposal belongs to the current applicable request version.
- The approval covers that proposal.
- The approval remains valid.
- Relevant availability and access conditions remain acceptable.
- The booking has not already been submitted.
The check and the transition into submission must be coordinated. Otherwise, an update could arrive after validation but before the external call.
One implementation could use a conditional database transition that permits submission only while the expected task version remains current.
A prompt asking the model to “check the latest instructions” can support reasoning, but consequential execution should also enforce the relevant conditions in application logic.
11. Cancellation and uncertain outcomes
Meera distinguished four user-visible states:
- Cancellation requested: the system has received the instruction.
- Cancellation confirmed: the pending action has been prevented.
- Action already submitted: an external amendment or cancellation may be necessary.
- Outcome unknown: the system must reconcile the provider’s state.
If the booking already existed, the assistant should report that fact and follow the appropriate amendment process.
Stopping a worker does not, by itself, establish that an external appointment has been cancelled.
The interface should communicate the strongest conclusion supported by evidence.
12. Practical verification plan
Proposed tests. No implementation was executed for this case.
| Scenario | Expected behaviour |
|---|---|
| Approval followed by no relevant change. | Submit the approved proposal if other conditions remain valid. |
| Location changes before submission. | Block the old proposal and prepare a replacement. |
| User sends an unrelated question. | Retain valid maintenance approval. |
| Old worker returns after a newer worker. | Retain the trace and prevent stale action. |
| Approval callback arrives twice. | Avoid duplicate submission. |
| Worker restarts around an interrupt. | Avoid repeating external effects. |
| Cancellation arrives before submission. | Prevent action and confirm the outcome. |
| Cancellation arrives after submission. | Report booking state and amendment options. |
| Provider availability changes. | Recheck the proposal and approval rules. |
| Vendor response is lost. | Reconcile the outcome before another attempt. |
Useful measures include stale actions blocked, duplicate submissions, approval-to-action mismatches and time spent resolving uncertain outcomes.
Measure correctness alongside responsiveness.
13. Learner assignment and project
Prepare a design note answering:
- At what event does version 1 become superseded?
- Which research can version 2 reuse, and why?
- Which changes require a new approval?
- How will two workers be prevented from submitting competing proposals?
- What happens when cancellation races with submission?
- What evidence explains the final action to the supervisor?
Submit:
- A task state table.
- An example approval record.
- Five failure scenarios and expected outcomes.
- A short explanation suitable for a nontechnical client.
Student project: build the smallest useful simulation
Create a simple workflow with a request, proposal, approval and simulated booking. It can use a spreadsheet, a no-code tool or a small program. Add a way to change the request while the booking waits.
Demonstrate that the old proposal cannot execute after a relevant change. Use a simulated vendor service rather than real appointments. Record the event sequence and explain the outcome.
Advanced extension: allow a supervisor to approve any appointment within a stated date range and cost limit. Explain how execution verifies those boundaries and when further approval is required.
14. Reusable engineering prompts
Prompt 1 — Find stale-work risks
Review this background workflow. Identify every point where a changed instruction could make a worker’s output or pending action obsolete. Separate reusable research from proposed actions. State the evidence needed to decide what remains valid.
Prompt 2 — Define approval scope
Define the exact action a person approves, permitted variations, expiry conditions and changes that invalidate approval. Identify ambiguous wording. Propose the application checks needed before execution.
Prompt 3 — Test competing events
Generate event sequences involving approval, user updates, worker completion, cancellation, restart and external submission. State the expected outcome for each sequence. Include cases where the external outcome is unknown.
Prompt 4 — Review user messages
Check whether these status messages distinguish requested, pending, confirmed, failed and unknown outcomes. Flag any statement stronger than the available evidence. Rewrite it accurately and clearly.
15. Teaching and team discussion guide
Suggested session: 75 minutes.
- 10 minutes: read the story and make an individual decision.
- 15 minutes: compare the alternatives.
- 20 minutes: design the approval and state records.
- 20 minutes: challenge designs with competing event sequences.
- 10 minutes: explain the chosen behaviour to the supervisor.
Assess designs on clarity of authority, treatment of changed instructions, handling of uncertain outcomes and preservation of useful work.
For freshers, focus on the timeline and user messages. For experienced engineers, examine concurrency and the boundary between local state and external effects. For managers, discuss acceptable approval scope and responsibility for exceptions.
Discussion question:
Which decisions can the organisation authorise in advance, and which changes should return control to a person?
16. Sources and research limits
Sources checked: 10 November 2026.
-
LangChain — Agents Are Going Async.
Sydney Runkle and Thushanth Bengre, 5 November 2026.
Primary source for the recent asynchronous subagent architecture, task management
and the stated beta limitation for task notifications.
Read the original article -
LangGraph documentation — Interrupts.
Primary documentation for interrupt handling, resumption and considerations
around side effects.
Read the documentation -
LangGraph documentation — Persistence.
Supporting documentation for workflow state, checkpoints and recovery.
Read the documentation
Research limits: these sources establish the technical context. They do not document the CedarWorks scenario, validate the proposed control design or establish measured business outcomes. No performance improvement, incident reduction or production readiness is claimed.
Before implementation, verify the installed framework version, relevant API behaviour, persistence configuration and the external provider’s submission, cancellation and reconciliation capabilities.
17. The enduring lesson
Saved progress tells an agent where it can continue. Current intent and valid approval determine whether it should.
Keep the work moving. Check the authority before acting.
