The Agent That Runs While You Sleep

I closed my laptop on Friday at 19:00. The next morning, at 07:12, a Telegram message landed: three things to focus on, two repos that moved, one watchlist headline that mattered. By the time I opened the laptop on Sunday afternoon, the agent had already shipped six skill runs, paid for one API call, and stayed quiet on the day nothing needed doing.

Nothing crashed. Nothing paged. There was no server to check on.

This is the architecture story behind that. If you’ve ever stood up a LangGraph deployment on Fly.io, written a Dockerfile for a CrewAI process, or paid Render to keep an AutoGen worker alive, you already know the alternative. Aeon picks a different starting point.

Most agent frameworks assume that “an agent” is a long-running process. You write the orchestration code, you instantiate the agent, and then you need somewhere to run it. That somewhere becomes its own project:

• A Dockerfile.
• A hosting choice: Fly, Render, Railway, a VPS, a Kubernetes cluster.
• A process manager: systemd, pm2, or Docker restart policies.
• A logging stack: at minimum, journald or a hosted log drain.
• A monitoring layer: uptime checks, alert routing, an on-call rotation.
• A deploy pipeline: usually a second GitHub Actions workflow that builds the image you actually wanted to run.

None of this is the agent. It’s the scaffolding that keeps the agent breathing. And the work-to-payoff ratio gets worse the more “personal” the agent is — you don’t want a PagerDuty rotation for a morning brief.

Aeon’s wedge is that it deletes this layer entirely.

In Aeon, the unit of deployment isn’t a process. It’s a line in aeon.yml:

schedule:
  - skill: morning-brief
    cron: "0 7 * * *"
  - skill: repo-pulse
    cron: "0 9 * * *"
  - skill: narrative-tracker
    cron: "0 12 * * *"

When you push that file, GitHub Actions takes over. Every cron tick spawns a fresh runner, the runner executes the skill, the skill posts its output to Telegram (or Discord, or Slack), and the runner dies. Next tick, repeat.

There is no process that has to stay alive between ticks. There is no state in RAM. The agent is a sequence of short, independent invocations — closer in spirit to AWS Lambda than to a daemon, but without a single line of provisioning code.

No server to keep alive

The first thing that disappears is the hosting question. You don’t pick a region. You don’t size a VM. You don’t write a Dockerfile. GitHub Actions runners are ephemeral, sized for you, and free up to a generous quota for personal use. If you blow past the free tier, you pay GitHub by the minute — but by then you’re well past the use case where renting a $5/month VPS was the obvious answer.

No supervisor, because every tick is independent

Long-running agents fail in the worst possible way: silently. The process is alive, the loop is stuck, the queue is full, and nothing is moving. You only find out when a human notices a missing message.

Cron-driven agents fail loudly and locally. If morning-brief fails at 07:00, that one run is marked red in the Actions tab. The next scheduled tick — repo-pulse at 09:00 — fires regardless. There is no cascading failure because there is no shared process to corrupt. Self-healing is the default, not a feature you bolt on.

Your laptop can be closed

This sounds obvious until you’ve shipped a side-project agent and then realized you have to keep your laptop plugged in to run it. Aeon agents are yours, but they don’t live on your hardware. They live in your fork. You close the laptop, the cron still ticks. You go on holiday for two weeks; the agent goes too — except it keeps working.

Reactive triggers come for free

Cron is the obvious trigger, but it’s not the only one. Aeon inherits the full set of GitHub Actions event types:

• workflow_dispatch: manual runs from the Actions tab. Useful for testing a new skill before you schedule it.
• push: every commit can fire a skill. Push a new aeon.yml, and the verify skill runs.
• repository_dispatch: external services — or Aeon itself — can trigger skills by hitting an HTTP endpoint.
• Telegram DM inbound: replying to the bot routes the message back into Aeon as a trigger for reply-handler, or any skill chained off it.

The same deployment surface that runs your cron also runs your interactive flows. There is no second system for “reactive” agents.

This isn’t free. The honest cost of cron-driven agents is latency.

GitHub Actions cron is granular to about five minutes on private repos, and faster on public ones — but it’s not real-time. If you need sub-second response to an event, a serverless function or a hosted process will beat Aeon every time. A trading bot that has to react to a price tick in 200 milliseconds is the wrong fit.

The right fit is everything that doesn’t need that latency — which turns out to be most personal-agent work:

• Daily briefs.
• Repo monitoring.
• Newsletter and digest skills.
• Scheduled research and roundups.
• Reactive flows where “a few seconds” or “a few minutes” is fine.

For that surface, the latency tradeoff is unnoticeable and the ops savings are total.

The fork at github.com/NurstarK/aeon is the operator log behind this post. The Actions tab shows every skill that fired last week — every output, every prompt. Nothing was babysat. The cadence speaks for itself:

• morning-brief — 7 runs, 0 failures.
• repo-pulse — 7 runs, 4 active days, 3 quiet days (printed REPO_PULSE_QUIET, sent nothing).
• narrative-tracker — 7 runs, 0 failures.
• One failed run on a new skill in development — caught by the next tick.

That’s the unit of trust this architecture buys you. The agent ran. You can see exactly what it did. You didn’t have to do anything.

The legitimate worry about per-tick agents is shared state. If every run is fresh, where does memory live?

Aeon answers this with git. Memory is a directory of Markdown files (memory/) committed to your fork. Skill runs read from it at the start, write to it at the end, and commit the diff. The next tick starts from the committed state.

This has two side effects worth naming:

• Audit trail is free. git log memory/ tells you exactly when the agent learned a fact, changed a priority, or revised a watchlist.
• You can edit the agent’s memory by hand. Open the file, change a line, commit, push — the next tick picks up the change. There is no “memory store” API to learn.

For ephemeral state inside a single skill run, the runner’s filesystem is enough. For state that has to survive across ticks, git is the persistence layer. There is no third option, and you don’t need one.

If you want to feel the difference, the on-ramp is short:

gh repo fork aaronjmars/aeon --clone
cd aeon
./onboard

The onboard script writes the three secrets you need, runs a verify pass, and fires a test skill so you see your first Telegram message land. From there, open aeon.yml, change one cron line, and push. Wait for the tick. That’s the entire loop.

You don’t have to host anything. You don’t have to monitor anything. You don’t have to be awake when the agent runs.

That’s the point.

Article 3: Letting your agent spend money. What changes when the agent has its own USDC wallet and can pay for the APIs it needs — without your credit card, your API keys, or your prefunded billing accounts.