Skip to main content

Outcome

A template built from your GitHub repo rebuilds every hour, so every session boots on a recent main. A startup script pulls once more at boot to close the gap between rebuilds. An agent on that template takes one prompt, adds a markdown file under memories/, and opens a pull request through Runtime. The PR shows up in GitHub with verified commits and only the agent’s change in the diff. The example repo is deliberately small: a memories/ folder where every run adds one .md file. Swap in your own repo and your own prompt once the loop works.
If the goal is for the agent to remember things across sessions, keep that memory in Notion or Confluence instead of a repo. Your team can read and edit it directly, and it needs no PR or rebuild. That is the recommended approach: Give an agent persistent memory in Notion or Confluence. Use this recipe when the change has to land in git.

Before you start

  • The GitHub App is installed on the repo, so Runtime can clone it and open PRs.
  • You are an org admin or owner. Creating, building and scheduling templates needs one of those roles.
  • The repo has a memories/ folder on main (an empty memories/.gitkeep is enough).

Do it

1

Add a startup script to the repo

Commit this file as scripts/runtm-start.sh on main. It runs on every session boot and pulls whatever landed after the last rebuild.
The script lives in the repo, so you can change it without rebuilding the template. The next pull picks up your edit.
2

Create the template from the repo

On Templates, create a template from the repo and the main branch, then build it. A repo of markdown files needs no AI setup step, so skip it.
3

Point the template at the startup script

Open the template, and on the Overview tab click Edit next to Template Settings. Set Startup Script Path to scripts/runtm-start.sh, switch Restart Services at Startup to Enabled so the script runs when a session boots, and save.
Template Settings form with Restart Services at Startup enabled and Startup Script Path set to scripts/runtm-start.sh

Template Settings in edit mode. The path is relative to the working directory.

4

Rebuild every hour

On the same Overview tab, set Auto Rebuild to Hourly. It saves right away. Each tick pulls the latest main and saves a fresh snapshot. When only the repo changed, it takes the fast rebuild path and skips the dependency install.
Auto Rebuild dropdown open with Off, Every 30 minutes, Hourly, Every 2 hours and Daily options, Hourly selected

Auto Rebuild on the template's Overview tab. Times are UTC.

5

Create the agent

On Agents, create an agent and set its Default template to the one above. Give it short instructions so every run ends the same way.
You work in the memories repo. Every change ends with a pull request opened with runtm-pr. Never push to main.
6

Send the prompt that opens the PR

Start a session as the agent, from the dashboard or from a trigger, and send:
Run git pull --rebase. Add a file memories/<UTC timestamp>.md with a short note on today’s date and the latest commit on main. Commit it, then open a PR with runtm-pr "Add memory <UTC timestamp>". Reply with the PR URL.
runtm-pr is installed in every session. It creates the branch, pushes it and opens the PR in one step. To add commits to a PR the session already opened, the agent commits and runs runtm-push.

Verify

The session’s last reply is a PR URL. In GitHub, the PR adds exactly one file under memories/, its commits show Verified, and its base is the commit that was on main when the session started. On the template, the build history shows a rebuild at the top of every hour.

Run it on a schedule

To get one PR per day without anyone sending the prompt, put the same prompt on a scheduled agent that runs on this template. Create it disabled, run it once, then enable it, as in Test a scheduled agent before enabling it.

Gotchas

  • Use runtm-pr, not git push or gh pr create. Raw pushes from the sandbox are unsigned, so repos that require signed commits block the merge. They also carry template setup changes, such as dependency installs, into the diff.
  • The startup script replaces the default service launch. When the script exists, Runtime runs it instead of the template’s per-service start commands. If the repo has a dev server, start it at the end of the script.
  • The startup pull runs in the background. It may still be running when the first prompt arrives. That is why the prompt starts with git pull --rebase. The hourly rebuild keeps the gap small either way.
  • Cron is in UTC. Hourly is 0 * * * *. A rebuild schedule needs Cloud Scheduler on the deployment; a 503 when saving means it is not configured there.
  • Running sessions keep their snapshot. A rebuild only affects sessions started after it.

Templates

What a snapshot contains, builds and fast rebuilds, and template secrets.