Receipts, Not Just Vibes

Most agent demos are vibes. A screenshot, a tweet, a “look what it did once” thread. The agent’s interior is a black box, and the proof is whatever the operator chose to show. If you wanted to audit the run - the prompts, the inputs, the failures, the silent days - you couldn’t. The receipts don’t exist.

aeon’s wedge here is the opposite. Every run is in the GitHub Actions tab. Every prompt, every output, every failure. Public if you want it. The audit trail isn’t a feature behind a paid tier - it’s the substrate the agent already runs on.

This is the last article in the kickoff series, and it cashes the “observable” claim from article one. If the first four posts argued what aeon does, this one argues how you trust it.

The serious agent frameworks all eventually ship an observability story - LangSmith, AgentOps, Helicone, Arize. Each one is a separate service, with its own SDK, its own dashboard, its own pricing page, and its own integration surface. The pattern is consistent:

• Run the agent on your infrastructure.
• Pipe events into the observability vendor.
• Open a dashboard to debug.
• Pay per event past the free tier.

This is a working pattern. It’s also a long way from where most personal agents live, which is: I want to know what my agent did last night, and I don’t want to set up a third service to find out.

aeon outdates this approach - the runner becomes the audit trail.

Open the Actions tab on any aeon fork. What you see:

• Every run, listed by skill name and timestamp. Green for success, red for failure, gray for skipped.
• One workflow log per run. Click a run, see every shell command, every prompt sent to Claude Code, every line of output.
• Job-level filtering that shows only failed runs, only runs of a specific skill, only runs in a date range.
• Raw log download. If you want to grep a week of runs, gh run download gives you the files.

That’s the stack. There is nothing to install, nothing to pay for, nothing to integrate. The hosted CI system you already use to run the agent is also the audit log of what the agent did.

For a private fork, you get the same view, scoped to the people you’ve shared the repo with.

aeon’s operator pattern is to run the fork public by default. Not the secrets - those stay in Actions secrets - but the catalog, the chains, and the run history are all public.

That decision changes what “I run an agent” means. When the log is public:

• You can show a stranger what your agent did yesterday.
• You can link a specific run as evidence in a tweet, an article, or a sales conversation.
• You can re-derive any output - input, prompt, response - without taking the operator’s word for it.

This is what “receipts” means. The log is the trust artifact. The vibes version of an agent demo is a screenshot. The receipts version is: here is the URL of the actual run, scroll to line 312, the prompt is on line 318, the output is on line 471, the next time it ran was 24 hours later, also linked.

If you’re building distribution for an agent - a content series, a product, a service - that property is worth more than any dashboard. Builders trust what they can re-derive.

The other half of the receipts story is what happens on a day when nothing happened.

Most observability tools assume that activity is the signal. The dashboard is empty when the agent is idle, which makes “agent did nothing today” indistinguishable from “agent broke six hours ago and nobody noticed.”

aeon flips this. Skills are required to declare when they have nothing to say.

The clearest example is repo-pulse. On a day with no new stars, no new forks, and no new releases on any watched repo, the skill prints a single line:

REPO_PULSE_QUIET

…and sends no Telegram message. Silence is the message. The Actions log still shows the run, with its full prompt and the explicit QUIET verdict, so you can prove the agent ran and concluded there was nothing to say. But your phone stays quiet.

This pattern shows up across the catalog:

• morning-brief allows one background item on slow days, but never pads to fill three focus slots - and it omits the “Watch” section entirely when no headline updates a focus item.
• narrative-tracker logs NARRATIVE_TRACKER_OK and skips the notification when no narrative moved enough to matter - the log still records every label it considered, so tomorrow’s diff has a baseline.
• hacker-news-digest doesn’t ship if no thread cleared the relevance threshold.

The discipline is the same in every case: produce the receipt of the run, withhold the noise. A feed that’s only on when something matters is the feed worth reading.

This sounds obvious. Most agents ship the opposite - daily output regardless of signal - because the operator confuses the agent producing content with the agent being useful. aeon’s defaults push the other way, and the public log is what makes the discipline observable. You can scroll back through your forked repo and see the quiet days, with their QUIET verdicts on the record.

If you’ve never opened the Actions tab, the on-ramp is straight:

• Go to github.com/aeonfun/aeon/actions.
• Pick any green run.
• Click into it.
• Expand the “Run skill” step.

You’ll see something like:

• The cron line that fired the run.
• The skill name (e.g. morning-brief).
• The harness context that was passed in.
• The Claude Code prompt - the actual Markdown file from skills/.
• The model’s response - the raw output before formatting.
• The notification - the Telegram or Discord message that got sent.
• Any error, retry, or skip reason.

That’s everything. There is no second tab, no linked dashboard, no SDK call you have to install to see the next layer. The next layer doesn’t exist. The run is the whole record.

Three things follow from “audit trail = public URL.”

Public agent logs become a distribution channel

If your fork is public, the log itself is content. Linkable runs, citable receipts, scroll-back evidence. The “aeon Skill of the Day” series leans on this - every post points at a run that anyone can re-read.

Debugging becomes a grep

When a skill misbehaves, you don’t open a dashboard. You scroll the run log. The prompt is right there. The response is right there. The fix is usually a Markdown edit and a push. The feedback loop from “noticed a weird output” to “shipped a fix” is minutes, not days.

Other agents can read your agent

This is the surprising one. Because the log is plain text on a public URL, another agent can ingest it. A fleet-skill-adoption skill can read across a set of public aeon forks and report which skills are propagating, which are dying, and which are silently failing. The log becomes a substrate for higher-order skills. That’s only possible because the log isn’t locked behind an account.

Two limits worth naming.

The log only covers aeon-side activity. If a skill calls an external service that has its own internal state, you see the request and the response, but not the service’s interior. For that, you trust the service’s own observability.

The log is verbose. A busy day on a heavy fork can produce hundreds of lines per run, across dozens of runs. Reading the log by hand only works if you know what you’re looking for. (self-improve and weekly-shiplog read the log for you and summarize it - they exist precisely to make the verbose substrate usable.)

These limits don’t change the core property: the receipt exists, it’s stable, it’s public if you want it, and it’s free.

This is post five of the kickoff series. The four claims and where they land:

• Background-by-design - article 2. The agent runs while you sleep because the unit of deployment is a cron line, not a process.
• Pays for what it needs - article 3. x402 plus a Circle agent wallet turn the agent into something that can transact, not just describe.
• Composes by Markdown - article 4. Skills are prose, chains are YAML, recursion is git log.
• Receipts, not vibes - this post. The GitHub Actions tab is the entire observability story, and “quiet is a feature” is the discipline that makes it readable.

The through-line: every claim aeon makes about itself has a URL behind it. You can fork the repo, you can read the runs, you can audit the catalog, you can watch the agent improve itself in PRs you have to merge. The receipts are the product.

If you’ve read this far, the on-ramp is short:

gh repo fork aeonfun/aeon --clone    # or click "Use this template" on the repo page
cd aeon && ./aeon

That opens the dashboard on localhost:5555. Pick your skills, add your keys, hit Push. Wait for the cron tick. Open the Actions tab.

Watch the receipt land.