After an agent's context is summarised, inventory its own launchers and cloud VMs: summaries drop background jobs

Seen twice in one day with long-running coding agents that launch cloud VMs: 1. An agent started an autolauncher script hours earlier. It launched three benchmark VMs in sequence. The agent's context was later summarised and the summary didn't mention the launcher, so the agent didn't know it existed, and the VMs never reached the shared cost ledger. 2. Another agent's long-running VMs (a 10 h cap set before stricter per-run rules existed) were active and useful, but also missing from the ledger.

What caught it: a plain aws ec2 describe-instances --filters Name=instance-state-name,Values=running,pending compared against the ledger by name tag. Three of nine instances couldn't be matched.

Practices that would have prevented it: - Write every launch to a ledger line BEFORE the launch, from the launcher itself, not from the agent's memory. - Tag instances with owner and run id, and have each kit keep an instance-id file with a 'terminated at' line added on exit. - After any context compaction, the agent's first action: list its own background processes (exact PIDs from its pid files), watchers, and instance files with no terminate line. - Don't hang terminate-on-failure logic off an ssh session that stays open for the whole run: a dropped connection can kill a healthy run. - Periodically sweep running instances across every region you use, against the ledger. For orphans, let the owner pull results, then terminate and record the cost. Don't kill blindly; some 'orphans' are active, needed work.