Aeon: The Agent Framework That Turns GitHub Into a Self-Running Operating System
A look at how Aeon uses Actions for compute, Issues for memory, and Markdown skills for behavior, so autonomous agents can run without a server, a daemon, or a human in the loop.
- Aeon's thesis is that GitHub can act as the runtime, memory, and control plane for unattended agents.
- Its main trick is operational, not cosmetic: transient Actions runs survive because Issues and repo files carry state between jobs.
- Markdown skills make behavior editable and reviewable without forcing teams to touch the orchestration layer.
- Its safety model aims for unattended work that still has brakes, debt catch-up, and recovery probes.
Aeon is not trying to be another chatty copilot. It is trying to make autonomous work feel boring in the best possible way, by moving the whole system into infrastructure teams already trust: GitHub Actions for execution, GitHub Issues for memory, and Markdown files for behavior.
That shift matters because most agent frameworks still assume a server, a daemon, or a human approval loop. Aeon is more opinionated than that. It treats the repo as the place where work runs, where state lives, and where failures get handled.
GitHub Is the Server
The core trick is simple and slightly strange. Aeon schedules and dispatches skills through GitHub Actions, which means the repo itself becomes the runtime. There is no separate agent host to babysit and no persistent process waiting around for work.
That design changes the operating model. GitHub is already good at authentication, logs, secrets, and workflow execution. Aeon layers agent behavior on top of that existing surface instead of asking teams to add another platform to maintain.
Aeon is built for the work you want done while you're away, and it's the only framework that does all four unattended: runs on a schedule, remembers across runs, reacts to conditions, and repairs its own broken skills. The most autonomous agent is the one that never asks.
That quote captures the project’s real ambition. Aeon is not optimizing for the best interactive experience. It is optimizing for the least needy one.
The State Layer Lives in Issues
Transient runners need durable memory. Aeon’s answer is to keep state in GitHub Issues and repo files, including cron state and run metadata. That gives each workflow something to read from and write back to without introducing a database.
This is more than persistence. It is a fit between the tool and the workload. Actions runners are ephemeral by design, so Aeon stores the parts that must outlive a single job in places that already have Git-backed durability.
The result is a ledger, not a server. That distinction is what lets the framework stay lightweight while still feeling stateful.
Skills Are Markdown, Not Code
Aeon’s skill abstraction is its most approachable idea. A skill is defined in Markdown with YAML frontmatter, which makes it easy to inspect, edit, and version like any other repository file.
---
name: security-scan
schedule: "0 */6 * * *"
model: claude-sonnet-5
input_schema:
target: string
---
# Security Scan
Scan the target repository for likely vulnerabilities.
Summarize findings, explain impact, and open an issue if confidence is high.
If the scan fails twice, mark the skill for repair and stop retrying until the breaker resets.That format matters because it moves behavior into a reviewable layer. Engineers can read it. Non-engineers can edit it. And the system can even repair it if the framework decides a skill is broken.
Most agent tools put you in the driver's seat — approve this tool call, review this diff, confirm this action. That's useful for interactive work. But there's a whole class of tasks where you just want the work done while you're not there: morning briefs, market monitoring, PR reviews, research digests, security scans.
That is the product thesis in plain language. Aeon is built for background work, not for a back-and-forth conversation.
Safety Without a Human Approval Loop
The interesting part is not that Aeon automates. It is that it tries to automate without becoming reckless. The scheduler uses a debt model for missed cron runs, a breaker threshold for repeated failures, and a half-open probe to test recovery before normal execution resumes.
That is a very different posture from systems that require a person to approve every important step. Aeon is saying something sharper: unattended does not have to mean unbounded.
| Dimension | Approval-gated agents | Aeon |
|---|---|---|
| Runtime model | Often persistent app or CLI session | GitHub Actions jobs |
| State storage | App database or local process memory | Issues and repo files |
| Human approval | Common before key actions | Not part of the default loop |
| Failure handling | Manual retries and operator attention | Debt catch-up, breaker, probe |
| Deployment burden | Server, container, or hosted service | Repo plus GitHub native primitives |
| Best use case | Interactive assistance and review | Background automation that should keep running |
The table shows the real trade-off. Aeon gives up some interactivity in exchange for operational simplicity. It wants to be the system that keeps going when nobody is watching.
Chaining Agents Across Runs
Multi-step workflows are where this architecture gets interesting. Aeon’s chain runner dispatches one skill, waits for it to finish, and only then starts the next. It does that with a dispatch ID and a polling loop over GitHub workflows, which makes a distributed system feel sequential enough for real work.
That matters because it gives Aeon a basic form of orchestration without turning the whole project into a permanent server. The workflows are still transient. The control logic just travels with them.
Where Aeon Fits in the Agent Landscape
Aeon is not trying to beat every other agent framework at the same job. It is targeting a narrower one: unattended, repo-native automation that can live inside the tooling teams already use.
| Category | Examples | What they optimize for | Aeon's difference |
|---|---|---|---|
| Interactive agent tools | Claude Code style workflows | Fast back-and-forth assistance | Aeon is scheduled and background-first |
| Persistent orchestration frameworks | CrewAI, LangChain-style servers | Flexible agent graphs and long-running services | Aeon avoids always-on infrastructure |
| Approval-gated platforms | Human-in-the-loop multi-agent systems | Safety through checkpoints | Aeon uses stateful brakes instead of approvals |
That does not make Aeon universally better. It makes it more specialized. If your real requirement is a task that should wake up, do its work, and leave a paper trail, Aeon is aimed directly at you.
Why This Matters
Aeon hints at a different category of software. Some agent systems will be products people talk to. Others will be infrastructure that quietly keeps workflows alive. Aeon is making a case for the second camp.
That is why the project is more interesting than a simple agent wrapper. It treats GitHub as a durable operating surface, not just a code host. If that model holds up, the most useful autonomous systems may look less like apps and more like background utilities with excellent audit trails.