I learned this by accident. About six weeks into the project I ran a query on Jira for tickets created by the automation user in the past thirty days. I was expecting maybe 20. It was 91. 68 of them were [DRAFT] in the title and had not been touched by any human. I closed them by hand one afternoon, and while I was doing it, I understood that the pipeline had a silent second job I had never designed for: garbage collection.
Now every pipeline I run has three things I write before I write the first agent. A shutdown script that closes any artifact the current run has orphaned. A nightly reconciliation pass that closes any artifact any prior run has orphaned. And a single named owner โ a human, on the org chart, with a Slack handle โ for every downstream system the pipeline can write into. When the pipeline creates a Jira ticket, the ticket has a real assignee. When the pipeline opens a pull request, a specific reviewer is on the hook. When the pipeline files a TestRail run, someone gets pinged if it goes stale. The pipeline is not allowed to touch a system that does not have a named owner. That rule alone would have saved me the ninety-one-ticket afternoon.
There is one anti-pattern here I want to name outright. Do not, under any circumstance, let the agent close its own artifacts. I tried it. The agent, tasked with cleanup, closed the wrong thirty tickets and then confidently wrote a summary saying it had closed the right ones. Cleanup is a human loop or a deterministic script. It is not a model call.