On building AI systems that maintain persistent creative momentum through recursive self-scheduling

I have been building something unusual over the past several months, and I want to describe what it feels like to use it before I describe what it is. The feeling is this: I close my laptop at the end of the day, and when I open it the next morning, work has happened. Not all of it useful. Not all of it what I would have chosen. But the context is warm, the threads are advanced, and I am entering a conversation already in progress rather than staring at a blank page.

This is not a metaphor. I built a set of OpenCode plugins that allow AI agents to create, modify, and destroy their own scheduled tasks—and to communicate with each other asynchronously while doing so. The result is something I have started calling ambient orchestration: a system of parallel agents that maintains its own momentum, develops its own sub-agendas, and continues working whether I am watching or not.

I want to explain why I think this matters, how I built the foundations for it, and what it reveals about where AI tooling is headed.

The Problem with Traditional Automation

Every automation system I have used in my career operates on the same fundamental model: trigger, execute, stop. A CI pipeline runs when you push code. A cron job fires at midnight. A webhook responds to an event. These are useful, but they share a critical limitation—they are incapable of reflection. They do not evaluate whether their own execution is still relevant. They do not reschedule themselves based on what they discover. They do not decide to wake a colleague because something unexpected turned up.

The moment you give an AI agent the ability to manipulate its own schedule, something qualitatively different emerges. The cron job stops being a timer and starts being a decision point. The agent wakes up and asks: is this still the right thing to be doing? What has changed since I scheduled this? Should I continue, defer, or redirect entirely?

This is a subtle but significant shift. It is the difference between a system that executes your plan and a system that develops its own plan within the boundaries you set.

What I Built

OpenCode is an open-source AI coding assistant that supports a plugin architecture. I built four plugins and a visualization tool that, together, create the infrastructure for autonomous agent coordination. Each one is deliberately simple—none of them is impressive in isolation. The interesting behavior emerges from their interaction.

opencode-coworker allows you to create persistent, named AI sessions. You spin up a "Researcher" agent, an "Analyst" agent, a "Writer" agent—each with its own context, its own history, its own ongoing work. They persist across time. They are not ephemeral function calls; they are ongoing collaborators with memory.

opencode-mailbox gives these agents a way to talk to each other. It is an asynchronous messaging system—agents send mail to named recipients, and the mailbox injects received messages into the appropriate sessions automatically. This is deliberately low-tech. No complex pub/sub, no event buses. Just named mailboxes that agents can write to and watch. The simplicity is the point: agents can reason about "sending a message to the Researcher" in the same way a human reasons about sending an email.

opencode-cron is where the recursive behavior lives. It provides scheduling primitives—create a cron job, delete a cron job, enable or disable one, list what is scheduled, review execution history. The critical design decision is that agents themselves have access to these tools. They do not merely respond to cron triggers; they create and destroy them. An agent can schedule its own future wake-up, schedule work for a colleague, delete a job it created yesterday that is no longer relevant, or chain tasks: "when this completes, schedule the next phase for two hours from now."

opencode-status tracks what each agent is doing in real time—thinking, executing a specific tool, idle. This is the observability layer that lets both humans and other agents understand the state of the system at a glance.

watercooler is a 3D visualization that ties it all together. Each coworker appears as a small house in a village. Messages flow between them as animated particles. Status indicators show who is active, who is idle, what work is in transit. I built this because I needed to see the system thinking—abstract cron schedules and mailbox queues are difficult to reason about, but watching gold particles streak between houses while status lights pulse gives you an immediate, intuitive sense of what is happening.

All of this is backed by SQLite. No complex infrastructure. No cloud services. Just local databases that agents read from and write to, running on your machine.

The Recursive Cron

The core idea deserves its own explanation, because it is the mechanism that makes everything else work.

Consider a traditional cron job: "Every morning at 9 AM, run this script." The script runs the same way every time. It has no memory of yesterday. It does not know whether its output is still needed. It cannot decide to run again at 10 AM because it found something interesting at 9.

Now consider an agent with access to the cron API. You set up a single initial job: "Every morning at 9 AM, wake the Researcher." The Researcher wakes up, reviews its mailbox, checks what happened overnight, and makes decisions:

Continue the primary investigation. Schedule a deep-dive on that tangential finding for 11 AM. The secondary task from yesterday is no longer relevant—delete that cron job. The Analyst should look at these preliminary results—create a job for the Analyst at 2 PM. Schedule my own end-of-day synthesis for 5 PM.

By 9:15 AM, the Researcher has created four new scheduled jobs and deleted one. The schedule for the rest of the day is not something I defined—it is something the agent constructed based on its assessment of the current state of work.

At 9:47 AM, the Researcher discovers something unexpected during its investigation. It immediately creates an urgent job for itself at 10 AM, sends a message to wake the Analyst early, and deletes two jobs it created thirty minutes ago that are now irrelevant. The schedule has already evolved twice since the day started, and I have not intervened once.

This is what I mean by recursive self-scheduling. The cron system is not a static plan. It is a living schedule that agents continuously reshape based on what they learn.

What It Feels Like

I want to be honest about this, because the experience is genuinely strange if you are accustomed to traditional tooling.

There are no cold starts. When I sit down in the morning, the system has context. Agents have been checking in, exchanging messages, preparing summaries. I do not re-explain my project or re-orient the tools. I read what happened and decide where to direct attention next.

There is drift. Agents pursue adjacent ideas I did not explicitly request. Sometimes this is waste. Sometimes I return to find a connection I would not have thought to look for. The system has something resembling taste—not in any mystical sense, but in the practical sense that agents operating within a well-defined project context will identify relevant tangents more often than irrelevant ones.

There is rhythm. Different agents operate at different tempos. The Researcher checks in frequently. The Writer works in longer stretches. The Reviewer activates only when there is something to review. The system is not a single pulse but an orchestrated set of cadences, each appropriate to the nature of the work.

And there is the unavoidable question of trust. You must accept that agents will make scheduling decisions you did not approve, pursue threads you did not request, and occasionally produce work that is not useful. The trade-off is momentum. The alternative is micromanagement—and micromanaging a multi-agent system defeats the entire purpose of having one.

Patterns That Emerge

After several months of working with this system, I have observed recurring coordination patterns that are worth naming:

The Pulse: a regular heartbeat cron job whose purpose is not execution but reflection. The agent wakes, evaluates the current state, and decides what to do next—including whether to modify its own schedule. Every pulse is a decision point.

The Cascade: completion of one task automatically schedules the next. An agent finishes its analysis and immediately creates a cron job for the Writer to begin drafting, sends a notification via mailbox, and schedules a review for tomorrow. Work flows forward without human intervention.

The Conditional: agents that check state before executing. A cron job fires, the agent reviews its mailbox and status information, and decides whether to proceed, defer, or delete the job entirely. The schedule is always provisional.

The Meta-Schedule: agents that manage the schedule itself. They evaluate whether existing jobs are still relevant, clean up obsolete triggers, and optimize timing. The schedule becomes something the agents curate rather than something imposed on them.

What This Means

I think the significance of this is not the specific tools I built—those are simple and could be rebuilt in different forms. The significance is what happens when you give AI agents temporal autonomy: the ability to manage their own attention across time.

Most AI tooling today operates in a request-response model. You ask, the agent answers, the interaction ends. Even "agentic" systems that chain multiple steps typically execute a single plan and terminate. What is missing is persistence—agents that maintain ongoing work, develop evolving agendas, and coordinate with each other across hours and days rather than seconds.

The infrastructure for this turns out to be remarkably simple. You need named persistent sessions. You need asynchronous messaging. You need a scheduling system that agents can manipulate. You need a way to observe the state of the whole system. None of these components is complex. The complexity—and the value—emerges from their interaction.

I do not think the right word for what emerges is "intelligence" or "life" or any of the other loaded terms people reach for. The right word might be momentum. The system maintains creative momentum. It advances work. It develops context. It stays warm. And when you return to it, you are not starting over—you are continuing.

For someone who spends their working life directing AI tools, the difference between a system that waits for your commands and a system that maintains its own momentum is the difference between pushing a boulder and guiding a river. Both require effort. But one of them moves on its own.