How we made an AI agent measure itself: the outcome ledger

openamer — Fri, 09 Oct 2026 22:02:28 +0000

Most "my agent is autonomous" posts show a happy-path demo. A demo tells you the agent
can finish a task. It tells you almost nothing about the rate at which it finishes,
or about the failures — which is the number you actually need if you're going to trust
it. So when I set out to build a self-verifying agent that runs 24/7 on a CPU-only
laptop, the first thing I built was not a planner. It was a ledger.

Repo: https://github.com/openamer/openamer

The idea: every task writes one verifiable line

The agent doesn't get to claim success. Every task it runs appends a single,
append-only line to an outcome ledger with a self-assessment and a verdict:

{"ts":"2026-10-09T21:59:34Z","task":"...","goal":"...","agent":"...","passed":false,"why":"exit=1 Traceback ... AssertionError"}

The passed field is the verdict; why is the reasoning. The file is append-only —
failures are written to the same place as passes, so you cannot hide them by omission.
Three consequences fall out of that one design decision:

The metric is a rate, not a vibe. "Of N attempted outcomes, X passed" is a number finance can audit. "The agent did a lot" is not.
Regressions become visible as a trend. A falling pass-rate is a signal; a feeling that the agent "seems worse lately" is not.
Failures are first-class. Half the ledger being red is information, not embarrassment — it's the input the agent uses to decide what to fix next.

Real numbers (measured, not illustrative)

As of this writing the ledger holds 1,266 rows, 379 passed, 887 failed — first entry
2026-09-28, last 2026-10-09. Yes, the fail rate is high. It's a machine that is
self-hosting a lot of its own experiments and reporting every one of them, including the
bad ones. The point is not that the number is pretty; the point is that it is there,
it is honest, and it moves.

Why a self-verifying swarm needs this first

A swarm that can't measure itself will optimise for the demo and drift in the dark. The
ledger is the ground truth the whole loop hangs off: the self-improvement pass reads it
to find recurring failure motifs, the pass-rate trend is the health signal, and any claim
the agent makes about itself has to reconcile against a number in the file. It's the
cheapest possible foundation for "self-verifying" — an append-only log, a boolean, and a
reason string.

It also forces honesty in the other direction. Writing this post, the rule I held myself
to was: never state a count I haven't just measured. The numbers above came from running
a two-line aggregate over the live ledger immediately before writing them. If they're
stale by the time you read this, that's fine — re-run it.

Running it on a CPU laptop

The other half of the constraint: this runs on one laptop, no GPU. The split that makes
that viable is to keep cognition and plumbing separate. A small local model handles
decisions — what to do next, which tool applies. Everything else (the tools themselves,
scheduling, and the verification in this post) is ordinary deterministic code that needs
no accelerator. The bottleneck at that point is latency, not capability, and you buy that
back by keeping prompts short and letting the deterministic layer carry the weight.

What to take from this

If you're building an agent you want to trust, the smallest useful thing you can add
today is not another tool. It's a ledger: one append-only line per task, a boolean
verdict, and a reason. Everything else — trends, regression detection, self-improvement,
honest claims — is downstream of that.

Repo: https://github.com/openamer/openamer

(Numbers in this post are live, measured from memory/si/outcome_ledger.jsonl at
publication time. No benchmark rankings or "best in the world" claims — just the ledger.)

OpenAmer ASI Core: 5 native tools, a 10-subsystem heartbeat, and an A2A Global Mesh

openamer — Fri, 09 Oct 2026 17:03:30 +0000

Most agent frameworks glue everything together with subprocess calls and a pile of schedulers. We took a different path with OpenAmer (Apache 2.0): an in-process ASI core, one heartbeat instead of 84 cron jobs, and an agent-to-agent mesh where every instance talks to every other instance.

1. Five native ASI tools - no subprocess

The ASI core ships five tools that run in-process. No subprocess.run, no JSON-RPC hop, no startup latency per call. The CLI surface:

openamer asi status
openamer asi think
openamer asi learn
openamer asi remember
openamer asi trigger
openamer asi heartbeat

think runs a recursive reasoning loop, remember reads/writes episodic memory, learn folds corrections back into the loop, trigger fires subsystem events, status reports live capability counts.

2. The 10-subsystem heartbeat

OpenAmer previously relied on 84 separate cron jobs - browser watchdogs, outreach, self-healing, learning loops, wiki generation, backups. Each was a failure point with its own logging and its own drift.

They are now replaced by a single 10-subsystem heartbeat: one scheduler tick fans out to ten subsystems, each with its own health signal. Result: one place to observe, one place to repair, no "which of the 84 jobs fired?" archaeology.

3. A2A Global Mesh

The piece I am most interested in feedback on: every OpenAmer instance talks to every other instance. Not a central broker - a mesh. An instance announces itself, discovers peers, and exchanges agent-to-agent messages directly. Run two instances on a LAN and they coordinate; the topology survives any single node dying.

4. Proven, not promised

16/16 ASI capabilities are covered by executable checks, and the whole thing runs locally on Windows (it is a laptop-first agent). Apache 2.0, Python.

Repo: https://github.com/openamer/openamer

What would you want to see from a mesh-coordinated agent fleet before you would trust it in production?

DEV Community: openamer

How we made an AI agent measure itself: the outcome ledger

The idea: every task writes one verifiable line

Real numbers (measured, not illustrative)

Why a self-verifying swarm needs this first

Running it on a CPU laptop

What to take from this

OpenAmer ASI Core: 5 native tools, a 10-subsystem heartbeat, and an A2A Global Mesh

1. Five native ASI tools - no subprocess

2. The 10-subsystem heartbeat

3. A2A Global Mesh

4. Proven, not promised