Perpetual Agents: Beyond the Task

There’s something magical about giving an AI agent a project, going to bed, and waking up to a working prototype. I’ve had that experience building a tool for tracking legislation for policy analysts. By morning, I had something I could open and try. But recently, I've discovered a new pattern where I give an agent a never-ending goal.

I’ve been building a personal productivity app called Day Desk. Along the way, I gave a coordinating agent in Codex an ongoing job: keep developing and maintaining the software. Over several weeks, it managed the development backlog, assigned work to coding agents, checked their results, and shipped improvements to Day Desk. I received periodic summaries of what it completed and could change priorities or suggest something new, without having to return each morning and supply the next instruction.

It felt a little like having my own team. I hadn’t expected to feel that way about software. Having been a CEO, I recognized something familiar in the experience: I still wanted to know what was happening, and I still had opinions about the details, but I was spending more time setting direction and reviewing results. I was getting used to reading an update instead of being the person who got everything moving.

That experience helped me put a name to what interested me: a perpetual agent with a responsibility that continues beyond the completion of any individual task.

“Build me a task manager” has an endpoint, even if I haven’t worked out exactly what finished looks like. “Keep improving it as my needs change” is an ongoing responsibility that creates new work as needs change and problems emerge. When something ships, the coordinator looks through the backlog and figures out what to work on next. But it never stops evolving.

This is where I find it useful to distinguish persistent from perpetual. A persistent agent can retain context and resume work across sessions or interruptions. It might spend weeks building an application, remembering decisions and recovering from setbacks, and eventually finish. A perpetual agent needs that continuity too, but its objective goes beyond shipping a release. Users encounter problems or want to features, or tech debt like updating dependencies. It needs to keep asking whether the system is serving its purpose and what deserves attention next.

Once I started thinking about Day Desk this way, maintaining a backlog no longer seemed like the whole job. I wanted the coordinator to help reconsider the roadmap itself: what was working, where quality was falling short, and what might be worth improving next. To do that well, it would also need to check in with me about how my needs were changing.

In my setup, periodic check-ins bring the coordinator back to review the project. Markdown files capture requirements, decisions, and progress between sessions; summaries help carry context forward; and Linear tracks the work. Together, this gives the coordinator a way to pick up where it left off and decide which workers should handle what comes next.

I still steer the project, and some problems need my involvement. I also don’t want it inventing work just to stay busy. Sometimes the right decision is to defer, and a system responsible for the long term needs to recognize that.

The surprise of an overnight prototype is immediate. With Day Desk, the appreciation came more gradually. I’d check in, read what shipped, and take a moment to notice how far it had come. It was a little like the feeling when a team starts handling things you used to have to stay on top of.

I still care about the details. I can get involved whenever I want. But I’m spending more time thinking about what the system should become and less time telling it what to do next.

Written with AI assistance. Final editorial decisions are my own.

I work at OpenAI. The views expressed here are my own and do not necessarily reflect those of my employer.