Scheduled AI Agents on GitHub Actions Forget Everything Between Runs. Give Them One Memory

Your agents forget everything between runs. That is the one sentence version of a problem that costs automation operators real time every week.

Picture the setup. A nightly agent runs on GitHub Actions. It reads the day's merged pull requests, drafts release notes, and opens a PR. Two hundred runs in, and it still re-reads all forty PRs every single morning, because it remembers nothing about which ones it already summarized, which summaries needed corrections, or that you changed the tone guidelines three weeks ago. The agent is not learning. It is repeating, expensively.

Every scheduled run starts from zero

The reason is structural. GitHub Actions gives each job a fresh virtual environment and throws it away when the job finishes. Any AI agent running on a schedule inside Actions inherits that amnesia completely. GitHub's agentic workflows with schedule triggers, Claude Code launched from a workflow on a cron expression, all of them wake up on a blank machine.

The same is true of Anthropic's scheduled Routines. Each run clones the repository into a fresh cloud environment, executes the configured prompt, pushes the outcome to a new branch, and then the environment is destroyed. No state carries over. Nothing is supposed to carry over; that is the design.

Ephemerality is what makes continuous integration trustworthy. But for an agent that is supposed to accumulate judgment over time, it means the only thing that survives is what the agent deliberately writes somewhere durable before the runner disappears.

Progress files: the pattern and its price

The standard answer is to make the repository itself the memory. The agent keeps a small set of state files next to the code: the goal of the loop, the current state between runs, instructions for how each iteration should behave, and a directory for outputs. Every run begins by reading the state file and ends by rewriting it. Structured sections carry the essentials: where things stand, what the last run did, open items, blockers, items waiting on a human, what the next run should do, decisions that were made, and things that must not be repeated.

This works well enough that teams run it in production. Documentation-audit loops use it to detect drift incrementally instead of rescanning everything. The claim-before-you-start discipline solves the double-work problem: a run marks an item as in progress so the following run does not pick up the same task.

But files have a price that shows up at scale. First, curation is a tax on every run. Reading, updating, and rewriting the state file consumes tokens and attention each time, and when the agent gets lazy about it, the file goes stale. A stale state file is actively harmful: the next run inherits a confident lie. Second, a file cannot span repositories, and it cannot span tools. When the same knowledge needs to live in the scheduled workflow and in the Claude Code session on your laptop, markdown files force you into sync hacks. Third, overlapping runs read the same file before either of them writes, so two concurrent runs can both believe they own the same task. And none of this answers the deeper question: when the agent needs to know what was decided about the retry policy four months ago, a pile of markdown files is a haystack, not a memory. A file answers exact questions. A memory answers related ones.

One memory for every run

The missing piece is a memory layer that sits outside the runner entirely. Vilix AI is cloud-hosted with zero infrastructure to manage, which is exactly what ephemeral runners need: there is nothing to provision, nothing to mount, nothing that has to start before the agent does.

A headless scheduled agent connects over MCP using an API key as a Bearer header. When the run begins, it calls get_context to load the relevant saved context: the decisions from last month, the failed approach from the week before, the corrections you made in your own Claude Code session yesterday. When the run ends, it calls save_turn and the exchange is preserved. The same memory is readable from every connected AI tool, so the 6 a.m. scheduled agent and the 9 a.m. session on your laptop share one continuous context. If a memory gets corrected in one place, last write wins, and the new version is what every tool sees.

Vilix AI keeps the full conversation history, not just extracted facts, so the actual past discussion can be pulled back whenever a run needs the reasoning behind a decision, not just its outcome. Retrieval is semantic as well as keyword-based, which means the agent finds relevant context even when the wording differs, while exact identifiers still match literally.

The terms are simple: a free plan that is free forever, a 7-day trial of full Pro with no credit card required, and your data stays yours. Export everything in a portable format whenever you want. Delete individual memories or wipe the account instantly.

A setup that survives Monday

Keep the progress file. It is free, it is inspectable, and it is better than nothing. Make the agent read it first and update it last, and make it claim work before starting so concurrent runs do not collide.

Then give the agent the thing the file cannot be: a memory that outlives the runner. One shared store, readable from the scheduled workflow and from every other tool you use, carrying the decisions, the corrections, and the conversations forward while the infrastructure underneath gets destroyed on schedule.

Your agents forget everything between runs. Give them one memory.