Workflow: re-prompt an agent session on a schedule, instead of spawning a new agent every run

[Herbrant]

Four of us have described the same problem in separate places, so this puts it in one thread as a workflow rather than as a feature request.

What are we trying to do?

Send a prompt into an agent session that already exists — one that already has the right provider, mode, workspace and accumulated context — at a time we choose.

Two shapes of the same need:

• Recurring. A standing review agent, re-prompted every morning with "check overnight CI and summarize failures" (@dkribeiro, feat: schedule recurring prompts to an existing agent (not just new agents) #3748). A long-lived agent watching a repo: "pull latest, run the smoke suite, report" (same thread).
• One-shot. A turn dies on the Claude 5h usage limit and the window resets at 00:00, so the "continue" prompt is queued now and lands when the session can act on it (@okon3 in feat: schedule recurring prompts to an existing agent (not just new agents) #3748, @JeremyCarlsten in Add timed prompt option #3436, @yuruiz in Proposal: wake-up schedules — resume an agent automatically when its usage limit resets #4122).

How do we do it today?

Manually. You watch the clock and re-prompt by hand, which defeats the point of monitoring agents remotely — or you create a schedule that spawns a new agent each run and rebuild its setup.

Over MCP and the CLI the agent-targeted version already exists: create_heartbeat and the CLI write { type: "agent", agentId } schedules today, and the daemon has always executed them.

Where does Paseo get in the way?

The app's create form is the only surface that cannot do it. So:

• The recurring run cannot reuse the session's context, workspace or provider/mode setup.
• You accumulate one-off scheduled agents instead of one durable session you re-prompt.
• The capability is asymmetric across surfaces: heartbeats can be born over MCP or the CLI, are listed and cadence-edited in the app, but cannot be created there. Existing heartbeats are already labelled "Heartbeat" in the schedules list and in the edit sheet, and docs/glossary.md already defines the term.

What would the flow look like?

From the Schedules form, choose the target: a new agent (today) or an agent session that is already running. And from a running agent, an entry point that opens that form with the session already chosen.

The one-shot case needs no new cadence type: pick the cron time and set Max runs to 1.

If you have this problem too

Please add your own version below — which agent, what prompt, what cadence, and what you do today instead. That is the part currently split across #3748, #3436, #4122 and #1948.

Related

• feat: schedule recurring prompts to an existing agent (not just new agents) #3748 (closed — issues are for bugs) · Add timed prompt option #3436 · Proposal: wake-up schedules — resume an agent automatically when its usage limit resets #4122 · Proposal: wake-up schedules — resume an agent automatically when its usage limit resets #4123
• Support scheduling existing agents #1948 (closed) — first implementation attempt, by @dafang
• feat(app): create heartbeats against a running agent #4396 — current implementation, app-only, no protocol/server/CLI/MCP change

[dwaxe]

I’m the person who reported #4339, and this is the concrete workflow behind my interest in this.

I run a daily dashboard-daily-status-collector schedule for a repository and workspace I already use. On Paseo 0.6.1, the current new-agent flow did this:

1. The run created a fresh local-backed workspace named Run dashboard-daily-status-collector.
2. The scheduled agent completed successfully.
3. archiveOnFinish archived the agent and its run workspace.
4. Restoring the workspace left me with an empty-looking shell: no visible agent and no route in the app to the successful result, although paseo schedule logs and the persisted records still contained it.

That led me through this history:

• feat: schedule recurring prompts to an existing agent (not just new agents) #3748 described recurring prompts against an existing agent.
• Support scheduling existing agents #1948 implemented an initial create-form selector. I reviewed it and asked for the target state to live in the schedule form model, loading to be distinct from empty, and browser/QA coverage.
• feat(app): create heartbeats against a running agent #4396 then implemented those points on current main, including model coverage, a real browser flow, and mobile QA, but was closed pending this workflow discussion.
• I filed bug: completed schedule results are not readable in the app #4339 for the separate result-discoverability problem; it was also closed with direction to bring the workflow to Discussions.

For my use case, I want both behaviors:

1. Let the daily status schedule target one durable agent in my existing workspace, preserving its context instead of creating and archiving another one-off agent every day.
2. In Schedules, show each run’s status and time and let me open its actual result, including for schedules that intentionally create fresh agents.

My ideal flow is: choose an existing agent while creating a schedule (or start from that agent), see the next and latest runs, open a run’s result from schedule history, and explicitly decide when the durable agent should be archived.

Existing-agent targeting solves context continuity and agent/workspace proliferation. It does not by itself solve result discoverability for schedules that should create fresh agents, so I see these as related but distinct parts of the same workflow.