Your GitHub Actions AI Agent Wakes Up on a Wiped Machine Every Run. Here's the Memory Fix

Every morning at six, your scheduled workflow fires. GitHub Actions spins up a fresh runner, your AI agent checks out the repo, triages the overnight issues, reviews the dependency PRs, and drafts the doc updates. It has done this two hundred times. Then someone asks a simple question: what did you decide about the retry policy last Tuesday?

The agent cannot answer. Not because the decision was never made. Because the machine that made it was destroyed months ago, and nothing about the decision survived.

Ephemeral runners are the whole design

A GitHub Actions runner is born when the job starts and dies when it finishes. Scheduled agentic workflows inherit this completely. Whether you use GitHub's own agentic workflows on a schedule trigger or run Claude Code through GitHub Actions on a cron expression, the agent gets a brand-new virtual environment, a fresh checkout, and zero memory of yesterday's run.

Anthropic's own scheduled option has the same property. Claude Code Routines clone the repo into a fresh cloud environment, run the configured prompt, push the result to a new branch, and then destroy the environment. Each run starts cold. No state persists between them.

This is not a flaw. Ephemeral is what makes CI reproducible, safe, and cheap. But it means your agent's memory is exactly as durable as the files it manages to write somewhere that survives the run. Everything else, every judgment call, every lesson from the last failed attempt, dies with the runner.

The pattern everyone lands on: the repo is the memory

Since the runner is wiped, the only durable surface the agent controls is the repository itself. The community has converged on one shape for this, and it is worth learning because it is genuinely useful.

Keep three files side by side: a TASK.md describing the loop's goal, a PROGRESS.md holding the state between runs, and a LOOP_INSTRUCTIONS.md describing how the agent should behave each iteration, plus an outputs directory for the actual artifacts. The agent reads PROGRESS.md before acting and updates it before stopping. The file stays short and structured: current state, last run, open items, blockers, needs-human-review, next run should, decisions made, do-not-repeat. If it is missing, stale, or too long, the loop loses continuity.

This is the initializer-agent pattern from Anthropic's long-running agent harnesses: the first session writes the baseline and the progress file, and every later session reads them and picks up where the last one stopped. It also gives you a control surface for free. A do-not-repeat section stops the agent from retrying failed actions. A needs-human-review section stops it from silently continuing past a judgment call.

One more discipline matters: the agent should claim work before starting it. Mark an item in progress so the next scheduled run sees the claim and does not rebuild the same thing twice. GitHub's own Aspire team runs this pattern across repositories, turning merged product changes into reviewed documentation PRs in separate repos. The mechanism works at real scale.

Where files stop being enough

Three failure modes show up once a scheduled agent runs for months.

First, the file is only as reliable as the agent that writes it. Agents overwrite it, truncate it, or quietly leave it stale, and a stale PROGRESS.md is worse than no file at all: it tells the next run the wrong story with full confidence. Every run must read the file, curate it, and write it back, which costs tokens and attention on every single run, forever.

Second, the file is per repo. A scheduled agent that spans several repositories cannot share one markdown file across them without sync hacks. Neither can an agent whose context lives partly in your local Claude Code sessions. The moment the same knowledge needs to exist in two places, the file pattern breaks.

Third, files do not answer questions. When the question is "what did we decide about the retry policy," a file only helps if someone wrote that exact heading. Six months of progress files are a haystack, and the next scheduled run has limited time to search it. The agent needs retrieval, not a longer file.

Give the agent a memory that outlives the runner

This is where a real memory layer comes in. Vilix AI is cloud-hosted, so there is nothing to install on the runner and nothing to babysit. That matters on ephemeral infrastructure: no database to provision, no volume to mount, no sidecar that has to start before the agent does.

A headless agent connects over MCP with an API key sent as a Bearer header. At the start of the run, the agent calls get_context and pulls in the relevant saved context: past decisions, failed attempts, prior conversations about the same repo. At the end of the run, it calls save_turn and the exchange is stored.

Retrieval is semantic plus keyword search, so the agent finds what was meant, not just what was typed, and exact strings like order IDs, policy names, and version pins match literally. Vilix AI stores the full conversation history, not just extracted facts, so the real past discussion can be revisited whenever the current run needs it.

And because it is one shared store over MCP, the scheduled GitHub Actions run and your local Claude Code session read and write the same memory. The agent that triages issues at 6 a.m. and the Claude Code session you open at 9 a.m. are looking at the same context. When the two disagree, last write wins, so you correct something once and it stays corrected everywhere.

There is a free plan that stays free, a 7-day trial of full Pro that asks for no credit card, and your data is portable: export everything in a portable format anytime, delete individual memories or wipe the account instantly.

The checklist

1. Commit a progress file anyway. PROGRESS.md is free, inspectable, and better than nothing. Make the agent read it first and update it last.
2. Make the scheduled run claim work before starting it, so overlapping runs do not redo each other's jobs.
3. Give the agent a memory that survives the wipe. The runner will be destroyed on schedule. The context does not have to be.

The next time someone asks what the agent decided last Tuesday, it answers from memory instead of pointing at a git log you have to dig through yourself. That is the whole difference between a scheduled prompt and a scheduled agent.