What’s Wrong?
I noticed a serious issue while using AI agents, and this is not just a small edge case. It appears across multiple AI tools, not only one. _When an agent starts a long-running subprocess like cargo build, npm run build, Get-ChildItem, or a large find command, the subprocess may finish correctly, but the agent does not reliably recognize that it is done.
Instead, the agent often keeps going, starts new timers, runs extra discovery commands, and ends up looping even though the original task has already completed. This burns tokens, wastes time, and blocks the workflow._
This feels like a major reliability bug for any company building automated AI agents, because the system is acting as if the task is still active even after the real work has already finished.
The issue does not seem to be just a prompt problem. It looks more like a deeper orchestration and process-tracking failure across several layers:
OS process I/O handling
The shell or PTY can remain alive after the child process exits, and the agent may not get a clean signal that the command has finished.
Exit detection is indirect
The agent is often reading text output instead of relying on a true OS-level completion signal, so task completion is inferred rather than confirmed.
Context window drift
Long builds and noisy output can push the original task context out of focus, causing the agent to re-orient and re-check unnecessarily.
Weak task state management
There is no strong lifecycle like PENDING → RUNNING → DONE, so the agent can lose track of what has already completed.
Watchdog loop behavior
A timer fires, the task appears incomplete, another check is triggered, and the cycle repeats.
Subagent coordination issues
Completion is often communicated in text, so the orchestrator may not reliably treat the task as finished.
LLM temporal blindness
The model does not truly track time or process state the way a real runtime does, so it can keep asking for verification even after success.
The important part is that none of these layers alone is necessarily the full cause. The bug seems to happen when they combine, which makes it especially dangerous in large or long-running tasks.
This should be treated as a real product issue, not just a prompt-tuning issue. For agents to be dependable in production, they need stronger process completion detection, better lifecycle tracking, and a more reliable stop condition once the underlying task is actually complete.
What Should Happen?
[FIX]: PALMS (Process-Aware Lifecycle Management System)
A clean way to solve this is to move completion tracking outside the model itself.
PALMS would be an external MCP-compatible daemon that sits between the agent and the operating system. It would require no LLM changes and no framework changes, and could be used as a drop-in layer.
Core idea: structured exit contract
Instead of the agent guessing whether something is finished from text output, the agent should define what “done” means before the task starts.
Example:
{
"task_id": "build-001",
"command": ["cargo", "build", "--release"],
"exit_criteria": {
"success_exit_codes": [0],
"success_pattern": "Finished .* target",
"max_duration_ms": 600000,
"kill_on_timeout": true
},
"output_policy": {
"stream_to_agent": false,
"summary_last_n_lines": 20
}
}
PALMS would then:
spawn the process,
read the real OS exit code instead of inferring completion from text,
kill the full process group when the task completes or is cancelled,
condense large output into a small summary,
and emit exactly one structured completion event.
Example completion event:
{
"task_id": "build-001",
"status": "SUCCESS",
"exit_code": 0,
"duration_ms": 43218,
"summary": "Build completed. 0 errors. 3 warnings."
}
The agent should call spawn_task once and receive one completion event once. No polling. No repeated timers. No guessing.
What this would eliminate
PTY / pipe confusion: use process.Wait() and kill the full process group, not just the PID
Exit code guessing: read the exit code directly instead of inferring completion from logs
Context flooding: cap output sent to the agent to a small summary
Weak lifecycle handling: maintain a deterministic PENDING → RUNNING → DONE → FAILED state model
Watchdog loops: remove the need for repeated polling entirely
Text-based completion guessing: replace it with structured JSON completion
LLM re-verification chains: reduce the chance of the model continuing to “check” after the task is already finished
Reproduction examples
Windows / PowerShell
Prompt the agent to list files in a large system directory using Get-ChildItem.
Expected failure mode: the command completes, but the agent starts re-checking, spawns another monitoring pass, and continues looping.
Linux / macOS
Prompt the agent to run a large build such as cargo build.
Expected failure mode: the build finishes, but the agent runs extra commands like find, ls, or ps to verify completion, then repeats the cycle.
Node.js project
Prompt the agent to run npm run build.
Expected failure mode: once the build completes, the agent starts checking for output folders, reruns inspection commands, and may continue looping.
Immediate workarounds until a proper fix exists
- Wrapper script
Use a wrapper around long-running commands so completion is explicit and structured.
- PowerShell completion marker
Have commands print a clear done marker after finishing.
- AGENTS.md circuit breaker
Add rules such as:
do not stream large command output into context,
only read the exit code after completion,
do not run follow-up verification commands after a successful exit,
limit the number of monitoring commands per task.
Ask to platform and MCP teams
I think this should be handled at the agent runtime level and standardized more broadly.
The key requests are:
bind async task completion to OS exit codes, not log parsing,
kill process groups, not just individual PIDs,
add a maximum output-to-context limit for long-running tasks,
standardize a structured task completion event in the task schema.
A minimal event schema could look like this:
{
"task_id": "string",
"state": "PENDING|RUNNING|DONE|FAILED|KILLED",
"exit_code": "int",
"duration_ms": "int",
"summary": "string"
}
**This is not a niche bug. It affects any AI agent that manages long-running subprocesses through weak completion detection. A real fix needs stronger process lifecycle management at the system level. It’s the most minimalistic fixes as for long term any kind of AI companies should think of these problem it might become problematic for Ai-Agents.
I would love to discuss on how we could Scale the AI-Agents with creative features and Ideas!