A year of AI coding / 14
Giving persistent agents a bounded job
Agents that react to events need durable state, explicit authority, retry limits, and a clear way to stop when the task cannot safely continue.
By Grafty team · · 3 min read
Written in .
"Keep this pull request moving until it is ready" sounds like a sensible assignment. It also contains several unanswered questions. Can the agent change the public API to satisfy a failing test? Can it remove a check that appears flaky? Can it merge when all checks are green?
An agent that waits for a single prompt has a relatively clear interaction boundary. An agent that wakes up on events needs a more durable definition of its job.
Cursor's August 19, 2026 release added cloud-agent subscriptions for events such as pull request activity and Slack conversations, along with long-lived goals. The release notes described workers continuing through updates rather than requiring a new prompt at each step. That is useful automation territory, and it deserves the same care as other event-driven services.
Open full-size diagram Define the allowed transitions
An agent maintaining a dependency update needs a defined set of states it can move through. It can inspect a failed build, propose a patch, run checks, and request review. It cannot broaden its own permissions or merge the result unless that authority was explicitly granted through the organization's controls.
The state should survive restarts. A worker needs to know whether a patch was already pushed, which revision was tested, and whether it is waiting on a reviewer. Reconstructing all of that from a chat transcript is fragile.
Events can arrive more than once or out of order. If the same CI failure notification is delivered twice, the agent should not create two competing fixes. Before acting, check whether the event still describes the current revision and whether another task is already handling it.
An external event is data, not new authority. A comment on a pull request may contain a useful request, but the system should verify whether the author is allowed to direct the agent and whether the requested operation fits the standing assignment.
Open full-size diagram Put limits on recovery
Retries are necessary. Unlimited retries are a way to spend money while hiding a blocked task.
Set a budget for repeated attempts and distinguish transient failures from missing decisions. A temporary build worker outage may justify another attempt. An unavailable production credential does not justify searching for alternate credentials. A test that exposes an ambiguous requirement should trigger a focused question.
Persistence should not expand scope. If fixing the dependency requires a broad architectural change, the agent should summarize the discovery and ask for a new decision. "Keep going" is not a blank check to redesign the application.
The stop path should be easy to use and easy to inspect. An operator needs to cancel future work, revoke active credentials when appropriate, and see which external changes have already happened. Stopping the process does not undo a pushed branch or an opened ticket.
Make waiting visible
A persistent agent can spend much of its time waiting for CI, a scheduled event, or a human response. The interface should distinguish waiting from failure and active execution. Otherwise people will either interrupt healthy work or assume blocked work is progressing.
We would want a short status that names the current revision, the next expected event, and any decision needed from a person. That is useful operational information without exposing the full internal conversation.
Persistent agents can remove repetitive follow-up work. To do that dependably, they need a bounded assignment and ordinary service engineering around it. Start with a narrow job, inspect the event history, and expand only when the behavior is understandable under failure as well as success.