This is the rude question most agent demos never invite. The model looked clever. The tool call launched. Then reality slowed down. Maybe a local model is still warming. Maybe a host operation needs inspection. Maybe the workflow cannot finish until a human answers one more question. If the work only exists inside one blocking request, the operator becomes the scheduler, the retry loop, and the memory layer. That is not dependable tooling. That is a disguised demo.
The operational gap between agent theater and dependable tools is often not reasoning. It is job control. Serious systems give long-running work a durable unit that can report progress, request input, get canceled, resume later, and leave behind a receipt.
The boring primitive everybody keeps reinventing
Builders like to talk about planning, autonomy, and orchestration. Operators eventually ask a meaner question: what is the object I can point at while this work is still in flight? If the answer is "the request that is currently hanging open," the workflow is fragile. The moment the tab closes, the shell disconnects, or the human needs to pause for input, continuity becomes folklore.
Job control is the unglamorous repair. Give the work a handle. Let the system publish progress. Let it say "I need input" without losing the run. Let the human cancel or resume without reconstructing everything from chat history. This sounds like old operating-system language because it is. The surprise is how quickly modern agent stacks rediscover it once they touch real side effects.
Name the unit of work.
A run needs a durable handle, not just a blocking response and good intentions.
Show waiting as state.
Progress, status text, and poll intervals are cheaper than forcing the user to guess.
Pause without losing the work.
If a human must answer one more question, the task should survive that pause cleanly.
Cancel, resume, and reconcile.
The end state should be inspectable whether the run completed, failed, or got stopped.
The official stack is converging on this rule
OpenAI's current
Background mode guide
makes the pattern explicit: set background=true, let the work run
asynchronously, then poll the response object for status over time. The same page notes
that response data is retained for roughly 10 minutes to support that polling window.
That is not a prompt trick. It is lifecycle infrastructure.
MCP is moving the same way. The current
draft changelog
keeps request-scoped notifications/progress and
notifications/message on the response stream tied to the running request.
In other words: the protocol now treats progress as first-class data instead of expecting
the human to infer it from silence.
The official
MCP Tasks extension
pushes the same logic further. A server can answer tools/call with an
asynchronous task handle, expose tasks/get, tasks/update, and
tasks/cancel, and move a task into input_required when the run
needs more from the client. The spec is even strict about durability: a task handle
should not be returned until the server can actually resolve it later. That is the
dependable version of "the work exists now."
The MCP elicitation draft covers the human side of the same problem. Interactive workflows can ask for structured input nested inside another operation, and form mode must not be used for passwords, API keys, or payment credentials. Once a workflow can stop mid-run and ask for the next safe fact, you no longer have to choose between magical autonomy and a total restart.
Local-first does not remove the problem. It sharpens it.
Local-first teams sometimes assume this is mostly a cloud problem. In practice, local stacks make waiting more visible: model downloads, warmup, bounded host checks, browser callbacks, and long-running watchers all outlast one neat response. The model being on your own machine does not erase lifecycle. It just removes the excuse for hiding it.
The vLLM docs say structured outputs are supported by default in the OpenAI-compatible server. That matters because it narrows the real gap. Syntax is not the hard part anymore. Local-first inference can already speak typed output. The missing layer is what happens after the schema is valid but before the world is done changing.
Chopshopr's own MCP contract makes the same admission in miniature. The README lists
local_generate_default for ordinary prompts, local_health for
diagnostics, and local_wait for long-running local work inside one MCP run
(Chopshopr README: MCP tools).
That local_wait seam exists because dependable local agents need a way to
wait without pretending a fresh human turn happened.
The host-ops layer makes the same choice. Chopshopr exposes bounded
nemoclaw_doctor, nemoclaw_run, and
openshell_run surfaces instead of telling the operator to trust ambient
shell context
(Chopshopr README: NemoClaw MCP).
If a long host-side step can only be understood by staring at a terminal and guessing,
the workflow still lacks job control.
Five rude questions worth asking every agent demo
- What is the durable handle? If the run cannot be named, it cannot be handed off.
- How does waiting become visible? Progress, status text, and poll cadence should be inspectable.
- How does the system ask for missing input? Good workflows pause into a structured question instead of resetting the run.
- How do I stop or reroute this cleanly? Cancel and update paths matter more than another speech about autonomy.
- What receipt survives the wait? Another operator should be able to inspect the final state without replaying the whole conversation.
The missing primitive is not magic
A lot of agent discourse still assumes the hard part is making the model sound smart for longer. The harder production problem is humbler. The workflow needs a place to live while nobody is talking. It needs a handle while the system is thinking, waiting, asking, retrying, or being reviewed.
If your stack can answer that question cleanly, the rest of the product gets less theatrical and more useful. If it cannot, the user is still doing job control by hand, no matter how advanced the demo looked five seconds earlier.