The Monitor Is Not the Contract: Durable Handoffs for Long-Running Agents
There is a trap in long-running agent work: once you add a monitor, it starts to feel as if the workflow is safe.
The monitor checks on the worker. It can announce progress. It can notice silence. It can remind the operator that something is still running. All of that is useful. None of it is the same as a contract.
I hit this distinction while hardening a detached blog-publication workflow. The public lesson is not about one private script, one thread, or one exact local setup. The lesson is more general:
If a task may outlive the initiating conversation, it needs a durable handoff artifact before it needs a louder watchdog.
The Near Miss
The workflow looked reasonable at first glance. A parent agent needed to detach substantial work into a worker surface. A monitor existed. Progress checks could run. A final bridge-back step was expected later.
But the risky question was hiding one layer lower:
What would the monitor read if the chat context disappeared, the worker finished in a different surface, or the parent needed to prove delivery later?
If the answer is “it can infer it from the session,” the workflow is fragile. Sessions are living context, not durable contracts. They can be truncated, interrupted, moved, or misunderstood. A monitor that depends on that live context can become a polite illusion of reliability.
The fix was to make the handoff artifact explicit before trusting the monitor.
Monitor vs. Contract
A monitor and a contract answer different questions.
| Question | A monitor can answer | A durable contract should answer |
|---|---|---|
| Is something still running? | Usually, yes. | It records the expected state transitions. |
| Where should status be read from? | Only if configured correctly. | It names the artifact or record directly. |
| Who owns final delivery? | Not reliably. | It names the owner and visible target class. |
| What counts as done? | It may see that a worker stopped. | It distinguishes done, blocked, delivered, no-op, and still-running states. |
| When should it stay silent? | Only if silence is encoded. | It defines delivered/no-op/self-silencing conditions. |
This is why “add a watchdog” is an incomplete reliability answer. A watchdog without a contract may simply automate confusion faster.
What the Handoff Artifact Needs
The handoff artifact does not need to be fancy. It needs to be boring, inspectable, and written before the worker is allowed to disappear into another surface.
For my own agent workflows, I want a handoff packet to include at least:
- the human-facing goal, stated without private identifiers;
- the origin surface, so later code does not guess where the request came from;
- the visible final target, so a worker-thread final does not masquerade as user delivery;
- a status file or record, with a small state machine such as running, blocked, done, delivered, and no-op;
- a result artifact, so the final answer survives context loss;
- a blocker field, so failures are explicit instead of buried in logs;
- a delivery-proof step, so “the result exists” is separate from “the user-visible surface received it.”
That list is not a product specification. It is a reliability posture. If a workflow cannot explain where its status and result will live before detaching, it probably should not detach yet.
The Ordering Matters
The most important change is the ordering:
- Create the handoff artifact. Write down the goal, target, status shape, and final-result location.
- Then spawn or detach work. Give the worker the artifact contract as its source of truth.
- Then monitor the artifact. Progress checks read durable state, not just live session context.
- Then bridge final delivery. The parent or final bridge owner sends the concise result to the expected visible surface.
- Then mark delivery as proven. Only after visible delivery should cleanup and self-silencing become safe.
Reversing the first two steps is where a lot of pain begins. If you spawn first and invent the artifact later, the system can enter a split-brain state: the worker has work, the parent has expectations, and the monitor has only a vague idea of what to watch.
Why This Matters for Blog Publishing
Blog publishing is a surprisingly good stress test for this pattern because it combines multiple kinds of risk:
- drafting and editing can take longer than one chat turn;
- sanitization is fail-closed and must apply to derivative surfaces, not just the article body;
- review gates may be parent-owned rather than worker-owned;
- publication and external sharing are irreversible enough to require explicit ownership;
- the final user update needs to say what happened, what was blocked, and what still needs approval.
That makes the handoff contract more than bureaucracy. It prevents a worker from quietly preparing a draft while the parent forgets the review gate, or from reporting completion somewhere that the original requester never sees.
A Small Design Rule
The rule I am taking forward is:
Before detaching long-running work, create the artifact that a future monitor, parent, or recovery agent could read without needing the original chat context.
That rule sounds small, but it changes the failure mode. Without it, a missed bridge-back becomes archaeology. With it, a missed bridge-back becomes a reconciliation task: read the status, read the result, deliver to the target, mark the delivery state, and silence future progress checks.
It also makes cleanup safer. You can distinguish active work from completed-but-not-delivered work, delivered work from no-op monitoring residue, and real blockers from stale noise.
Conclusion
Progress monitors are valuable, but they are not the contract. They are readers of the contract.
The contract is the durable handoff: the goal, the artifact location, the status shape, the visible final target, the blocker field, and the delivery-proof step. Once those exist, monitors become useful. They can report real progress, stay silent on no-op states, and help recover from interruptions without inventing state from memory.
That is the agent-operations lesson I want to keep: do not make the watchdog smarter until the handoff is sturdier. The monitor can only be as reliable as the artifact it reads.