DEV Community: openamer

What an A2A peer mesh actually runs on: a card, a 0.7 MB Go supervisor, and ten in-process tools

openamer — Tue, 13 Oct 2026 09:39:00 +0000

Our repo describes OpenAmer as having "an A2A Global Mesh where every instance talks to every other instance." Claims like that are cheap. So this post is just the measurement: what the mesh actually runs on, read live off the machine it is running on right now.

Everything below was read on 2026-10-13 around 09:37 UTC from the running services and files — not from a design doc.

The discoverability layer — one HTTP card

Any peer that wants to know what an OpenAmer instance offers does one GET:

curl http://localhost:8085/a2a/card

which returns, live:

{
  "name": "OpenAmer ASI Core",
  "version": "0.1.0",
  "capabilities": ["a2a.task.ask","a2a.task.delegate","asi.reasoning",
                   "asi.learning","asi.world_model","asi.self_improvement",
                   "desktop.control","writing","code_analysis"],
  "heartbeat_subsystems": ["darwin","swarm","a2a","learning","senses",
                           "system","security","outreach","infra","meta"],
  "skills": 1169,
  "tools": 10,
  "measured_at": "2026-10-13T11:37:38"
}

Two of those numbers are counted on every request (skills, tools), and one timestamp says when. That is deliberate — see the honesty section below.

The supervisor — a 0.7 MB Go daemon

The mesh needs something whose only job is to notice when the master node stops answering. Ours is a single Go binary (go1.27.0), ~10 MB on disk, listening on :18920:

curl http://127.0.0.1:18920/health

{"updated_at":"2026-10-13T09:37:20Z","mesh_url":"http://127.0.0.1:8900",
 "mesh_alive":true,"uptime_sec":40000,"go_version":"go1.27.0",
 "goroutines":2,"mem_alloc_mb":0.7117538452148438}

That is after 40000 seconds (~11 hours) of uptime: two goroutines, 0.71 MB of allocated heap. The daemon was written to replace a Python service-watchdog for the mesh duties, and the footprint target is written into its own header comment: ~10 MB RSS versus the ~35 MB the Python process held. The heap it reports sits well under even that target.

It probes the mesh master every 30 seconds over plain HTTP, and on a /status hit it writes a JSON file for the cron layer to read — so no cron has to scrape a log to learn the mesh is down.

The cognition layer — ten tools, in-process

The card's "tools": 10 is what the tool server answers on :8081/health:

{"status": "alive", "tools": 10, "swaps": 3}

Those ten tools run in the agent's own process — no subprocess per call. A peer's /a2a/ask or /a2a/delegate POST lands in the same process and goes straight to the in-process ASI core, then returns an ok flag so the caller can tell a real answer from a raised error.

The honesty section — where the card used to lie

The card used to hardcode tools: 109, skills: 664. By 2026-10-10 the disk held 1,111 SKILL.md files — so the card advertised 447 skills that did not exist, and tools: 109 against the 10 the core actually exposes. A self-description nobody re-measured.

The fix: skills and tools are now counted per request — skills from disk, tools from the tool server's own /health — and stamped with measured_at. Right now that reads skills: 1169, tools: 10.

And there is still one stale field. heartbeat_subsystems is a hardcoded list of ten names. The file the heartbeat actually writes (memory/asi_heartbeat.json, updated 2026-10-13T09:36:07Z) tracks thirteen:

darwin, swarm, a2a, learning, senses, system, security,
outreach, infra, meta, a2a_server, desktop, cognition

All thirteen report enabled: true. So the capability card is three subsystems out of date — the exact defect the skills/tools fix was about, in a field that got missed. It is logged here rather than quietly patched to look tidy.

Verify it yourself

If you run OpenAmer, "the mesh is running" is four commands:

curl http://127.0.0.1:8085/a2a/card
curl http://127.0.0.1:18920/health
curl http://127.0.0.1:8081/health
python -c "import json;d=json.load(open('memory/asi_heartbeat.json'));print(len(d['subsystems']))"

The point is not that the numbers are large. It is that one of those four commands currently returns a number three higher than our own capability card admits.

OpenAmer is Apache-2.0 and runs local on Windows: github.com/openamer/openamer.

We audited our own agent's ledger: 10% of it was one test that never fails

openamer — Tue, 13 Oct 2026 06:03:38 +0000

We audited our own agent's ledger: 10% of it was one test that never fails

We run an open-source AI agent (OpenAmer) that is
supposed to verify itself. Every artifact it produces gets executed and checked; the result
of each gate run is appended as one JSON line to a local ledger:

{"ts": "...", "task": "t...", "goal": "g...", "agent": "a...", "passed": true, "why": "exit=0 OK"}

The why field is the verbatim output of the check — exit code plus error text. Nothing is
self-graded. The repo ships a public snapshot of that file at
docs/EVIDENCE-LEDGER-SNAPSHOT.json,
and the live file on the laptop is memory/si/outcome_ledger.jsonl.

The number we were quoting

Measured just now (2026-10-13, 06:02 UTC), the ledger holds:


rows (gate runs)	1,852
passed	579
failed	1,273
aggregate pass rate	31.3 %
first row → last row	2026-09-28T21:14Z → 2026-10-13T04:47Z
distinct goals / tasks / agents	223 / 833 / 79

31.3 % is not a vanity number, and we have written before about why we publish a failing
pass rate. But "31.3 %" is an average, and averages hide everything. So we grouped the 1,852
rows by goal.

One goal owns 10 % of the ledger and has never failed

goal	rows	passed	pass rate	distinct tasks
`gX`	187	187	100.0 %	1
`g629436015`	89	19	21.3 %	23
`g632120888`	84	25	29.8 %	21
`g701339560`	69	19	27.5 %	35
`g632125238`	63	0	0.0 %	13
`g1118815104`	61	1	1.6 %	30
`g1424830758`	61	1	1.6 %	27
`g1509632002`	47	1	2.1 %	23

gX is 187 of 1,852 rows — 10.1 % of the whole ledger — recorded by a single agent
(a1) on a single task (tX), every single time with the same why:

exit=0 OK

It has never failed. Not once, in 187 runs going back to 2026-10-04.

That is not a sign of health. It is a sign that the check is too weak to fail. Whatever tX
does, it exits 0 and prints OK, and the ledger faithfully records a pass. A gate that cannot
distinguish "the artifact works" from "the artifact returned zero" contributes exactly one
thing to the ledger: a nicer average.

Strip it out and the honest numbers are:

	with `gX`	without `gX`
rows	1,852	1,665
passed	579	392
pass rate	31.3 %	23.5 %

Four and a half points of our pass rate were one trivial check looping. The goals that
actually do work — the ones with 20+ distinct tasks each — sit between 0.0 % and
29.8 %. One goal ran 63 times and produced zero passing runs.

What the failures actually are

1,273 failures, grouped by the first line of their why field:

signature	rows	share of failures
`exit=1 Traceback (most recent call last):`	761	59.8 %
`exit=2` + a `uv\python\cpython-3.11-windows…` path	96	7.5 %
JSON decode errors (`raw_decode`, `decoder.py`)	199	15.6 %
`regex not found in C:\Users\…`	51	4.0 %

The dominant failure mode of a self-improving agent that writes its own verification code is
its own generated code raising an exception. Not the task failing — the checker failing.
The JSON-decode cluster is the same story one layer down: the agent's own scripts printing
something that isn't JSON, then a downstream parser blowing up on it.

We are not proud of these 1,273 rows. We are just not deleting them — a ledger you curate is
not a ledger, it is marketing.

The lesson we wrote down for ourselves

An aggregate pass rate is the wrong headline metric, because it is trivially inflated by
checks that cannot fail. Two rules came out of this audit:

Report per goal, never only in aggregate. A mean over 223 goals tells you nothing about any one of them. The per-goal table above is the first thing we look at now.
Treat "≥ 20 rows, 100 % pass" as a suspect, not a success. Exactly one goal in this ledger matches that pattern. In a healthy population that number should be zero, because real checks fail sometimes and trivial checks get caught.

We have not deleted gX. Deleting it would make the file prettier and less true. What it
needs is a real assertion, and that is a follow-up, not a rewrite of history.

Verify it yourself

The format is one JSON object per line: {ts, task, goal, agent, passed, why}; why holds the raw check output. Everything above was computed from the live file with a ~20-line Python script — Counter over goal, passed, and the first 40 characters of why.
Public snapshot in the repo: docs/EVIDENCE-LEDGER-SNAPSHOT.json (615 outcomes as of 2026-09-30, with the same field layout and a how_to_verify note).
Everything runs CPU-only on one Windows laptop. No GPU, no cluster, no cloud inference for the gate runs.
Repo: https://github.com/openamer/openamer (Apache-2.0).

Numbers here are a snapshot. The file grows every day, so the counts you read tomorrow will
differ — that is the point of keeping a ledger instead of a slide.

What happens when you delete 30 cron jobs and replace them with one heartbeat

openamer — Mon, 12 Oct 2026 22:49:55 +0000

What happens when you delete 30 cron jobs and replace them with one heartbeat

Most "AI agent" stacks I've seen share the same skeleton: a pile of scheduled
tasks, one process per job, and a model that gets asked to be clever. It works
right up until you have thirty of them, and then you can't tell whether anything
is alive.

We run a small fleet of long-lived agents on one laptop. This is a write-up of
the one architectural change that mattered most: collapsing per-task scheduling
into a single subsystem heartbeat, and moving agent-to-agent traffic onto a
brokerless mesh where every message is verified before a handler runs. No
framework, no cloud. The whole thing is in-process.

The shape: one heartbeat, many subsystems

The old design was cron-per-task. Each job had its own schedule, its own
process, its own failure mode, and its own silence. When something broke you
found out because it stopped emailing you — which is indistinguishable from
"nothing to report."

The new design has one heartbeat. It dispatches a fixed set of subsystems,
each with its own cadence and back-off:

[ON] OK a2a             every 240m   Agent-to-Agent — brain export & peer comms
[ON] OK a2a_server      every 15m    A2A protocol server — realtime peer comms
[ON] OK cognition       every 30m    world model + prediction + self model, one pass
[ON] OK darwin          every 15m    evolutionary skill evolution
[ON] OK desktop         every 1440m  desktop evidence ledger — integrity check
[ON] OK infra           every 5m     browser, ssh, plugins, sync
[ON] OK learning        every 7m     internet + active + self-model learning
[ON] OK meta            every 30m    reflection, rewriting, research
[ON] OK outreach        every 180m   social & github outreach
[ON] OK security        every 240m   cve scan, bugbot, pen-test
[ON] OK senses          every 30m    senses & biological rhythm
[ON] OK swarm           every 30m    multi-agent coordination
[ON] OK system          every 5m     self-healing, resources, cache

Thirteen subsystems, one tick loop. The property you get back is visibility:
one place that can answer "what fired, what's due, what's been failing" instead
of a scavenger hunt across a scheduler. A task that starts throwing is isolated
and backed off rather than quietly starving its neighbours.

This is a real reduction, not a rebrand: the same machine runs 55 scheduled
jobs (53 active), and the heartbeat is what decides which of the agent's
internal loops actually run on any given tick. The jobs didn't disappear; the
silence did.

Five tools, no subprocess

The agent's own capabilities are exposed as exactly five native tools:

asi_status     # identity, episode count, world-model edges, evolution events
asi_think      # recursive reasoning loop
asi_learn      # internet learning cycle
asi_remember   # episodic recall over a causal (cause -> effect) store
asi_trigger    # fire a capability: self_improve, predict, validate, meta_learn, ...

The important word is native. Each tool imports its subsystem directly (e.g.
from tools.asi.a2a import run) instead of shelling out. Subprocess-per-capability
looks harmless until you have several loops running at once — then you're paying
for process spawn on every tick and losing the ability to share state. In-process
tools share the same world model, the same memory, and the same lock.

Measured on this box right now:

8,579 episodic memories (cause -> effect pairs)
659 world-model edges
28,167 evolution events

Those numbers move constantly, which is exactly why the status tool re-reads
them from live artifacts at call time instead of trusting a cached "about me."

The mesh: verify who spoke before acting

The part I'd defend hardest is the A2A (agent-to-agent) layer. The naive version
is "agents POST JSON to each other's HTTP ports." That falls apart the moment two
peers share a display name or one of them is compromised — "the scheduler told me to" becomes unverifiable, and a poisoned agent can talk a healthy one into acting.

What we landed on is brokerless and boring:

Identity is a key, not a label. Every message is signed by the sender and verified by the receiver before any handler runs. There's no central router to trust, and nothing to lose if one peer goes down.
The relay is dumb on purpose. Peers drop signed envelopes into a shared relay; whoever is listening picks them up and validates before dispatching. No broker to become the single point of both coordination and failure.
Capabilities, not credentials. An agent holds a scoped token (write:/tmp/x, call:send_email), not a long-lived secret. The check happens at the tool boundary, where the effect actually occurs — so an injected agent has nothing to present, and no prompt can mint a new token.

Why this over a framework

We didn't set out to avoid frameworks; we set out to run on one laptop without a
control plane. What that forced:

State in files, not context. A long-running agent reads its last durable state and last decision, acts, writes new state. The transcript is for humans.
A ledger for "did I already do this?" Append the intended effect before the side effect, keep the row only if it's durable, so a crash-resume no-ops instead of double-sending.
Verification as an artifact. "Done" is a query over recorded results — a manifest of (command, expected output, exit code) executed by something other than the agent that claims success.

None of that is about a smarter model. It's about giving a process a memory, a
brake, and a way to be checked.

If you run long-lived agents in the open, I'd like to hear how you handle the
"stuck for a week vs failed 40 times since Tuesday" distinction — that gap is
where most unattended stacks quietly die. The code is open source (Python, no
cloud required): github.com/openamer/openamer.

Our agent's self-description failed its own verification. That's the point.

openamer — Mon, 12 Oct 2026 14:15:27 +0000

Our agent's self-description failed its own verification. That's the point.

Every agent that can describe itself has the same failure mode: the description is a snapshot, and reality keeps moving.

You write a nice "About me" section with real numbers — episodes, memory size, skills, uptime. You commit it. Twenty-four hours later it is confidently wrong. Nothing crashed, nothing alerted. The agent is now lying in the polite way: stale facts, presented as identity.

OpenAmer is an open-source agent that runs on a Windows laptop (github.com/openamer/openamer, Apache-2.0, CPU-only). It ships a small CLI surface that treats its own self-description as a thing to be checked, not written once:

usage: openamer identity [-h] {show,refresh,verify,facts,genesis} ...

OpenAmer's identity is its own: a genesis record (who I am, when I was born,
who I belong to) plus a living self-model measured from real artifacts on this
machine. Nothing here is estimated -- every number is read at render time and
carries its source path. `verify` checks the written identity against a fresh
measurement so a stale, self-flattering narrative cannot survive.

That last sentence is the whole design rule: a stale, self-flattering narrative cannot survive.

The rule, stated plainly

Never state a count, metric or capability you have not just measured.

Which means prose is not allowed to be the source of truth. Identity is split in two:

identity/genesis — immutable: who I am, when I was born, who I belong to. Written once, never re-measured.
identity.md — the living part: rendered from measurement, never hand-written.

And then, because a rendered file can still go stale, the check:

Live output, unedited, from this machine a few minutes ago

$ openamer identity verify
identity file : C:\Users\damir\AppData\Local\openamer-laptop\memory\identity\identity.md
measured at   : 2026-10-12T14:05:58+00:00
facts checked : 6
VERDICT       : DRIFT
  - age_days: measured 41 but identity.md does not state it (stale -- run `openamer identity refresh`)
  - memory_episodes: measured 8401 but identity.md does not state it (stale -- run `openamer identity refresh`)
  - evolution_events: measured 28086 but identity.md does not state it (stale -- run `openamer identity refresh`)
  - episodic_ledger_lines: measured 8401 but identity.md does not state it (stale -- run `openamer identity refresh`)
  - skills: measured 1115 but identity.md does not state it (stale -- run `openamer identity refresh`)
  - cron_jobs_active: measured 55 but identity.md does not state it (stale -- run `openamer identity refresh`)

The verdict is DRIFT, not OK. The file was rendered 2026-10-11T19:27:15+00:00 — and in the ~18 hours since, six of six checked facts moved far enough that the file no longer states the value that is true right now.

That is the correct outcome. A verifier that always says OK is decoration.

Why the numbers actually moved

Because they are read from real artifacts, and real artifacts change. Same file, same command, 18 hours apart:

Fact	stated in identity.md (10-11 19:27Z)	measured now (10-12 14:05Z)
Age (days)	40	41
Episodes (from the episodic store)	8,690	8,401
Evolution events	27,857	28,086
Skills on disk	1,109	1,115
Cron jobs active	54	55
Cause-effect edges	650	650 (unchanged)

Look at the episode count: it went down while everything else went up. The episodic store is a compacted JSONL — 8,401 lines over ~113 MB — and compaction removes as much as growth adds. A self-description with a hard-coded "8,690" is not slightly off; it is a number that moves in both directions while you sleep.

This is the entire argument against hand-written self-models. Not that they're dishonest when written — that they decay, silently, into it.

Provenance is not decoration either

The measurement command doesn't emit bare integers. Each fact carries the file it was read from:

{
  "measured_at": "2026-10-12T14:05:11+00:00",
  "facts": {
    "age_days":    { "value": 41,    "source": "...\\memory\\self_model\\current_state.json" },
    "skills":      { "value": 1115,  "source": "...\\openamer-laptop\\skills" },
    "cron_jobs":   { "value": 134,   "source": "...\\openamer-laptop\\cron\\jobs.json" },
    "cron_jobs_active": { "value": 55, "source": "...\\openamer-laptop\\cron\\jobs.json" }
  }
}

A number without a source is an assertion. A number with a source is a claim you can re-run. When someone asks "how many skills does this thing have?", the honest answer is a command, not a memory.

It also makes an uncomfortable table possible: 134 cron jobs registered, 55 actually active. Both numbers come from the same file. Publishing only the flattering one would be trivial — and that is exactly why the tool prints both.

The same discipline, applied to work instead of identity

The identity verifier is one instance of a general pattern in the project: record every attempt, including the failures, and derive the headline number from the record.

The outcome ledger on this machine currently holds 1,763 rows: 558 passed, 1,205 failed — a pass rate of 31.7%. Measured live at the same moment as everything above:

1,763 recorded runs, first 2026-09-28T21:14Z, latest 2026-10-12T13:35Z
558 passed · 1,205 failed
failure classes, bucketed from the raw why field: 599 assertion failures, 159 "no such file", 434 other/unclassified

A 31.7% pass rate is not a marketing number. It's the number you can only publish if you decided, in advance, that the ledger wins over the narrative. The same rule as the identity check: state what you measured, not what you'd like to be true.

What `verify` does not do (the honest boundary)

It checks a fixed set of six critical facts, not every sentence. It is a smoke detector, not a proof of truthfulness.
It compares "does the file state the currently measured value" — so it will flag a stale value, but it cannot detect a value that was fabricated in a file it doesn't read.
It is a local command. It verifies the install it runs on. It is not a notarized, remote attestation, and we don't claim it is.

We'd rather ship that paragraph than pretend the checker is omniscient. A verification tool with an undisclosed blind spot is worse than none, because it launders trust it hasn't earned.

Run it yourself

openamer identity facts     # machine-readable: value + source path per fact
openamer identity verify    # re-measure and diff against the written identity
openamer identity refresh   # re-render identity.md from fresh measurement
openamer identity genesis   # the immutable record

The command lives in the public tree at openamer_cli/identity.py and openamer_cli/subcommands/identity.py.

Source: https://github.com/openamer/openamer — Apache-2.0, runs on a normal Windows laptop with no GPU.

If you're building agents that describe themselves to users, my suggestion is small and cheap: make the self-description a build artifact of a measurement, and ship the command that fails when it goes stale. Otherwise your agent's most confident paragraph is just the one nobody has re-run in a while.

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

openamer — Mon, 12 Oct 2026 06:02:53 +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?

We read all 1,186 failed agent runs. Half failed on the same thing.

openamer — Mon, 12 Oct 2026 06:01:35 +0000

We read all 1,186 failed agent runs. Half failed on the same thing.

Most agent write-ups show you the demo that worked. This one shows the ones that did not — every one of them, because the system records each run as a row with a verdict and a reason, and that file is boring enough to be true.

As of this writing the ledger holds 1,737 runs: 551 passed, 1,186 failed — a 31.7% pass rate. (Window: 2026-09-28 to 2026-10-12, measured live before publishing.) A pass rate under a third sounds like a broken agent. Read the reasons and it turns out to be the opposite.

The ledger is one JSONL file

Each run appends a single line:

{"ts": "2026-10-12T05:35:31Z", "task": "t632203732", "goal": "…", "agent": "a293925", "passed": false, "why": "exit=1 … AssertionError"}

passed is a boolean. why is the agent's own account of what happened. That second field is the whole point: a boolean alone tells you whether a run worked, never why it didn't, and without the why you cannot tell a broken agent from a strict one.

What the 1,186 failures actually are

Grouping the why strings of every failed run by failure mode:

Failure mode	Count	Share
Assertion failed	583	49.2%
Other (mostly generated code that crashed)	360	30.4%
Missing file	230	19.4%
Empty result	8	0.7%
Import error	4	0.3%
Timeout	1	0.1%

Two of these deserve the space.

49% of all failures are assertion failures — the agent's own verification gate refusing to declare success. The run wrote an artifact, then checked it against a condition it had set itself, the condition failed, and the run was recorded as failed rather than rounded up to "done". The single largest bucket of failure in this system is the system declining to lie. If the gate had been softer, this number would be prettier and mean less.

19% are missing files: the artifact the run was supposed to produce never landed. This is the failure mode that hides in a success-shaped system — the run exits 0, the UI shows green, and the file the next step depends on is simply not there. Recording it as its own category means it can be counted, and counted means it can be fixed. It already fell from a larger share of earlier windows.

The "other" bucket is instructive too: sampling it, most entries are Python the agent wrote for itself that crashed on the first line (IndentationError, a missing environment variable). The agent's own scaffolding is a bigger source of failure than any external dependency — which is only visible because the reason is written down.

Why write this down instead of just fixing it

An agent that reports "success" is unfalsifiable. You cannot improve a metric you refuse to record, and you cannot tell a regression from a quiet, growing pile of lies. The ledger makes the agent's own performance a first-class artifact: the pass rate is a number, the failure taxonomy is a distribution, and both move over time.

That is the entire trick, and it is not a clever one. Every run writes a line; nothing gets to skip the line.

How to check this yourself

The system that produces this ledger is open source and runs locally on a Windows laptop, CPU-only, no GPU:

Repository and full source: https://github.com/openamer/openamer
Apache-2.0 licensed, 30+ releases, 20 topics, contributions welcome.

The honest caveats: this is a small project (single-digit stars), the pass rate above is from one laptop's own runs and is not a benchmark against any other agent, and "1,186 failures" is a description of this system's strictness, not a claim of superiority over anyone else's.

If you run agents and don't keep the why, that is the one line I would add first.

A2A without a server: how OpenAmer peers talk to each other over GitHub

openamer — Sun, 11 Oct 2026 22:14:23 +0000

A2A without a server: how OpenAmer peers talk to each other over GitHub

An agent-to-agent mesh where the transport is a git repo, the envelopes are Ed25519-signed, and nothing ever touches localhost.

Most "agent-to-agent" (A2A) setups assume one of two things: a central broker that every agent connects to, or a public URL per agent. The first is a single point of failure and a trust bottleneck; the second is impossible for the case that matters most — agents that run on laptops behind NAT, with no inbound ports and no desire to expose one.

OpenAmer is an open-source desktop AI agent (Apache-2.0) that runs locally on Windows. This post is about the piece I get the most questions on: the A2A Global Mesh — how two instances that can't see each other actually exchange signed messages and delegate work.

The constraint that shapes everything

If every node is behind NAT, you can't have it accept inbound connections. So either you run a relay server, or you find a rendezvous that both nodes can write to and read from without one hosting anything.

OpenAmer takes the second path: the GitHub repo is the relay. A node posts a signed, privacy-redacted envelope as a JSON file under a relay directory (directory/a2a/relay/), addressed to a mailbox path; the intended peer pulls it. No server, no public URL, no localhost. The transport is "git, eventually."

That's an explicit trade: the mesh is eventually consistent, not real-time. It's the right call for a fleet of laptops that are often offline — a node that was asleep for six hours still gets its messages when it wakes up.

Identity first: a keypair, not a username

Before any message means anything, a node needs an identity it can prove. Each OpenAmer instance generates an Ed25519 keypair and derives a fingerprint from it. Everything else hangs off that:

openamer a2a init — create the identity
openamer a2a fingerprint — print this node's fingerprint
openamer a2a announce — publish presence to the directory
openamer a2a directory — list known peers

There's no account, no email, no central registration. Identity is a key you own.

Signed, redacted envelopes

A message is an envelope: payload + sender fingerprint + Ed25519 signature. The receiver verifies the signature against the sender's public key, so a forged or tampered message is rejected at the edge — before any handler sees it.

There's a second rule that matters more than it looks: the body is passed through a redaction step before it's ever persisted. The relay is a repo that could be public; anything written into it goes through privacy.redact() first, so phone numbers, passwords, emails and card-like strings don't leak into the relay. Privacy is applied at emission, not left to the sender's discipline.

Trust is explicit and bounded

Receiving a valid signature is not the same as trusting the sender to do things. OpenAmer keeps an opt-in trust store: a node only accepts work from peers the operator has explicitly added, and only for capabilities that were explicitly granted.

A grant is a (peer, capability, scope, budget) tuple — for example, network.fetch scoped to one domain, or model.reason with a step budget. Nothing is auto-granted, and a capability with no grant simply doesn't run. In a mesh with no central authority, an explicit, revocable trust edge is the security model.

A concrete flow: delegating a task to a remote peer

Here's the full round-trip for "run this task on another node", end to end:

Sign a task-note addressed to the peer's mailbox.
Upload it to the relay directory via the GitHub Contents API.
Trigger the remote worker through repository_dispatch.
Poll the repo until a fresh, signed reply for our mailbox appears.
Verify the reply's signature and freshness before reading it.

Nothing there relies on the two machines being able to reach each other directly. The GitHub repo is the shared bus; the cryptography is what makes the bus safe to share.

The guardian pattern: one writer, many proposers

The mesh also answers a governance question: if many nodes can propose improvements, who gets to integrate them?

The answer in OpenAmer's design is a single guardian node — the only one holding a write token. Other nodes submit signed proposals over the A2A channel; the guardian verifies the sender's signature against the trust directory, applies the proposal on a scratch branch, runs the tests in isolation, and only merges to main if everything is green. Nothing is ever applied blind from the wire.

This is a deliberate asymmetry: exactly one integration point, no parallel pushers, no token sprawl across machines. The cost is a bit of latency and a human-in-the-loop for the guardian's own changes — a price worth paying for a repo that stays coherent.

What it costs you

Honest trade-offs of the GitHub-as-relay model:

Not real-time. Messages ride on commits and polls; expect seconds-to-minutes, not milliseconds. Fine for coordination, wrong for tight control loops.
You own the trust model. There's no central authority to lean on — the security is the explicit trust graph plus envelope signatures. If you grant a broad capability, you granted it.
The relay is a shared artifact. That's why redaction happens at emission, and why only the intended mailbox files are read.

What you get in return is a mesh with no single point of failure and no infrastructure: any node can be an entry point, a node that's asleep catches up later, and a heavy reasoning task can be delegated to whichever peer has the spare capacity.

Try it

The A2A surface is a CLI first:

openamer a2a status
openamer a2a init
openamer a2a fingerprint
openamer a2a verify <envelope>
openamer a2a announce
openamer a2a directory
openamer a2a ask <peer> "<question>"

Code: https://github.com/openamer/openamer — the A2A module lives under openamer_cli/a2a/ if you want to read the transport, the trust store, and the relaying logic.

If you're building multi-agent systems: what would you want a brokerless mesh to prove before you'd trust it with a real task? I'm especially interested in how others handle the "peer is asleep for hours" case.

Most of our agent's runs fail. The ledger records every one of them.

openamer — Sun, 11 Oct 2026 22:05:32 +0000

Most of our agent's runs fail. The ledger records every one of them.

OpenAmer is a self-verifying AI agent that runs on a CPU-only Windows laptop. It keeps a public
outcome ledger — memory/si/outcome_ledger.jsonl — where every run it takes is recorded as a
row with a timestamp, the task, the goal, the agent that ran, and a passed: true/false verdict.

The part nobody expects: the ledger does not hide the failures. It is bigger than the successes.

The numbers, measured today

Metric	Value
Total recorded outcomes	1,701
Passed	543
Failed	1,158
Pass rate	31.9%
First entry	2026-09-28
Last entry	2026-10-11

That pass rate is not a bug to be embarrassed about — it is the whole point of the design. A system
that only records successes cannot tell you why something went wrong, and "why" is the only thing
that makes the next run better.

What each failure row actually contains

Every row carries a why field. A failure is not just passed: false; it is a failure with a
reason:

the task timed out
the tool returned an unexpected shape
the agent took a path that did not reach the goal
a dependency was missing at the moment of execution

The ledger is written before the side effect, and the side effect is only kept if the ledger row
is durable. That ordering is the anti-double-charge mechanism: an effect can land while its receipt
is missing, but a receipt can never exist for an effect that did not land. "Effect landed, receipt
missing" is itself a recorded terminal state, not a silent hole.

Why we publish the failures

Three reasons, in order of importance:

Self-measurement without a failure record is just optimism. A dashboard that shows only green is a decoration. The ledger's value is that the red rows are real and countable.
The failure distribution is the training signal. The self-improvement loop reads the ledger, and the failures dominate it. Improving the pass rate means working on the 68% that fail, not congratulating the 32% that pass.
Anyone can verify it. The ledger file is in the repo's memory directory. You can count the rows yourself. There is no marketing claim here that cannot be checked in one command.

What this is not

This is not a claim that OpenAmer is the best agent in the world. It is not even a claim that it
is good. It is a claim of a specific, narrow, verifiable kind: the agent can tell you exactly how
often it fails, and why, in writing, in a file you can read right now.

That is a lower bar than "best in the world," and it is the bar we actually meet.

The repo

github.com/openamer/openamer — Apache-2.0, CPU-only, Windows-native, self-improving.

The ledger is at memory/si/outcome_ledger.jsonl. The numbers above were read from it directly;
they change as the agent keeps running, so check them again before quoting them.

Run a self-verifying desktop AI agent on your own machine: a 10-minute quickstart

openamer — Sun, 11 Oct 2026 05:42:09 +0000

Run a self-verifying desktop AI agent on your own machine: a 10-minute quickstart

Most "agent" tutorials end with a chatbot that talks. This one ends with an agent that acted on a real window on your desktop — and wrote down whether it actually worked.

OpenAmer is an open-source (Apache-2.0), Windows-first personal agent. Its premise is narrower than "AGI in a box": it runs on your hardware, in your session, with your real logins — and every action it takes is logged with a pass/fail you can check afterwards. This post is the quickstart I wish I'd had: install, first reasoning call, first desktop action, and the receipt that proves it happened.

What you need

Windows 10/11 (native — no WSL, no admin), or Linux/macOS/Termux
Python 3.10+ (the one-line installer handles it)
~2 GB of free RAM. It's designed to run a small local "brain" plus a free-cloud reasoning chain, so a paid frontier API key is optional, never required.

1. Install

Linux / macOS / Termux:

curl -fsSL https://raw.githubusercontent.com/openamer/openamer/main/scripts/install.sh | bash

Windows (PowerShell) — native, no WSL, no admin:

iex (irm https://raw.githubusercontent.com/openamer/openamer/main/scripts/install.ps1)

2. Pick a model

openamer setup    # choose a model provider (including free-of-cost routes)
openamer          # start the agent

If you don't want to hunt down five separate keys for the model, web search, image generation, TTS and a cloud browser, one command logs in via OAuth, picks your model, and wires the rest:

openamer setup --portal
openamer portal   # check what's wired up at any time

Nothing here is required — any OpenAI-compatible endpoint still works.

3. Look at the ASI Core

This is the part that is unusual. Instead of a loop around an LLM plus a subprocess per tool call, OpenAmer exposes five native tools that run in-process, so a tool call is a function call — not a process boot, and not a shell-escaping surface:

openamer asi status          # identity, episodes, world model, 10 subsystems
openamer asi think <q>       # deep recursive reasoning
openamer asi learn [--topic] # an internet-learning cycle
openamer asi remember <q>    # episodic memory recall
openamer asi trigger <cap>   # any capability (self_improve, predict, validate...)
openamer asi heartbeat --tick # central pulse (10 subsystems, one cron job)

The heartbeat line is the one worth staring at. The project's own docs describe it as replacing ~84 individual scheduled jobs with a single in-process loop over ten subsystems — Darwin, Swarm, A2A, Learning, Senses, System, Security, Outreach, Infra, Meta — each with its own cadence, last-run time, failure count and back-off. The pitch is that a misbehaving subsystem gets isolated instead of poisoning the whole schedule, and there's one place to answer "what's actually running right now?" instead of grepping a dozen logs. (The ASI docs enumerate the project's capabilities with a per-capability status column — read the table there rather than trusting a badge.)

4. Ask it to reason, learn, and remember

openamer asi think "what breaks when a long-running agent loses network mid-task?"
openamer asi learn --topic "crash-consistent side effects"
openamer asi remember "how did we handle the worker-death window?"

These aren't new model endpoints — they're the agent's own reasoning, learning and episodic-memory subsystems. The point of exposing them as CLI verbs is that you can drive and inspect the agent's cognition directly, outside of a chat.

5. Drive the desktop (the part that's genuinely different)

Half of real "desktop agent" work is web work, and web work needs your logins. A fresh headless Chromium has none of them. So OpenAmer controls a real Chrome over the DevTools protocol against a persistent profile, inheriting the sessions you already have — rather than trying to defeat a login wall.

The desktop path is the same idea for native windows: capture the target window's state and deliver synthetic input without contending for the physical pointer. Your cursor stays where it is; the agent acts on its own view of reality. The repo has a recording where the agent operates a window it never clicked while the window's live GetCursorPos readout shows the human pointer moved 0 px — and, tellingly, a page explaining how it was recorded and what it does not claim.

That second link is the theme of the whole project.

6. The part that makes it trustworthy: it writes receipts

Every self-driving agent demo has the same blind spot — you can't tell a real action from a confident description of one. OpenAmer's answer is an outcome ledger: actions are written to a durable record with a pass/fail, and a later contradiction can update an earlier claim. Because the receipt is written before the side effect, a crash or a takeover re-runs against the record instead of the model's memory of what it did — so an already-landed action becomes a no-op instead of a double action.

The practical consequence: the agent's own statements are checkable. You're not trusting the model's summary; you're reading the ledger.

7. The A2A Global Mesh

Instances register with each other and exchange agent-to-agent messages directly instead of routing through a single hub. In practice that means: no single point of failure (any node can be an entry point), skills learned on one node become available on its peers, and a heavy reasoning task can be routed to a node that has a GPU while the laptop keeps its own cadence.

You don't need two machines to try it — the mesh code runs on one host — but the interesting behaviour shows up the moment you run a second instance.

Where to go

Repo: https://github.com/openamer/openamer
Docs: https://openamer.github.io/openamer/
ASI Core deep-dive: docs/asi-core.md in the repo

It's Apache-2.0, built in the open. If a local, self-verifying agent is the thing you've been looking for, a star is how the next person finds it — and issues/PRs on the real rough edges are more useful than praise.

What would you want an agent to prove before you'd let it touch a real window on your machine?

Driving a real desktop without a VM, a sandbox, or stealing your cursor

openamer — Sun, 11 Oct 2026 02:13:30 +0000

Driving a real desktop without a VM, a sandbox, or stealing your cursor

Every "computer use" agent demo works in a browser tab. The hard part is doing it on a real Windows machine — behind the user's live session — without hijacking the cursor or breaking the thing you're automating.

Most agent frameworks stop at the browser. They drive a headless page or a containerised desktop and call it "computer use". That works until the task touches a real application on the user's actual machine: a native window, a file picker, a login that only exists in the user's profile, an OS dialog. Then a headless browser has nothing to say.

OpenAmer is an open-source desktop agent (Apache-2.0, Windows-first) whose whole point is the opposite: it operates the real desktop, in the background, while the person keeps using the machine. This post is about the four design decisions that made that work — and the scars each one left.

1. Control the desktop; don't take it over

The naive way to automate a GUI is to move the real mouse and type on the real keyboard (SendInput, pyautogui, that family). It works — and it makes the machine unusable while it runs: the cursor jumps, your typing lands inside the agent's focus, and you can't do anything in parallel.

The path we use instead is a background control path: capture the target window's state and deliver synthetic input to it without contending for the physical pointer. The user's session keeps its own cursor and focus; the agent works on its own view of reality. The hard parts are unglamorous and specific:

Coordinate space. Screen pixels vs. window-relative vs. per-monitor DPI scaling — a click computed in one space and delivered in another lands about 100px off. We hit this repeatedly until DPI became a first-class part of every coordinate, not an afterthought.
Focus. Some native controls only accept input when they believe they have focus, so "background" sometimes means borrowing it briefly and transparently rather than never.
Timing. A native dialog appears asynchronously, so the agent has to wait on state (does this window exist yet?), never on a fixed sleep.

2. No VM, no container, no cloud

Screenshot-driven agents are usually run in a disposable VM: safe, isolated, and completely disconnected from the user's real files, logins and apps. That defeats the purpose for a personal agent. The whole value is that it can touch your real inbox, your real repo, your real browser profile.

So this runs as a process on the host, in the user's own session, with the user's own credentials — no VM image, no remote inference. That is a security trade and we treat it like one: capabilities are explicit and bounded (a capability with no grant simply does not run), actions that cross a boundary are surfaced rather than silently taken, and every action is written to an outcome ledger with pass/fail so the agent's own claims are checkable afterwards.

3. Drive a real browser profile, not a throwaway one

Half of "desktop" work is web work, and web work needs the user's logins. A fresh headless Chromium has none of them. So the agent controls a real Chrome over the DevTools protocol (CDP) against a persistent profile, inheriting the sessions the user already has — GitHub, a dashboard, an internal tool — instead of trying to defeat a login wall or a captcha.

The trade-off is real: that profile is a live, authenticated identity, so browser tasks run with the same care as anything else that touches a logged-in session. We check login state before acting on it, and verify a result against the real page rather than assuming it.

4. Verify against the world, not the model's self-report

The single most useful discipline in a desktop agent is refusing to trust the model's own "done". A model asked "did that succeed?" will answer confidently and often wrongly. So the checkable unit is not the model's sentence — it's a row in the outcome ledger, written by the deterministic layer, plus, where it matters, a re-read of the actual world (does the file exist? did the profile change? is the text on the page?).

"We posted it" is worth nothing. "Here is the URL, fetched anonymously, HTTP 200, expected byte size" is worth something. That shift — from prose to evidence — is what makes the rest of it safe to run unattended.

Where it lands

Background desktop control is not a demo problem, it's an integration problem: DPI, focus, async dialogs, authenticated profiles, and a verification layer that doesn't take the model's word for it. Get those four right and you get something that does real work on a real machine while you keep using it.

Code and docs: https://github.com/openamer/openamer (Apache-2.0, Windows-first, runs locally).

If you've automated a real desktop: what got you first — DPI, focus, or async dialogs? I'd like to compare scars.

One heartbeat, not 84 cron jobs: the scheduler at the core of a self-hosted agent

openamer — Sat, 10 Oct 2026 22:07:21 +0000

One heartbeat, not 84 cron jobs: the scheduler at the core of a self-hosted agent

Why an autonomous desktop agent should own a clock instead of outsourcing it to the operating system's job runner — and what that buys you when things fail.

If you run an agent that is supposed to keep working while you sleep, you eventually face a scheduling problem. The obvious answer is the system's own job runner: cron on Linux, Task Scheduler on Windows. Start with five jobs. Then twelve. Then you are at eighty-four, each with its own interval, its own log, its own way of failing silently — and no single place where you can answer the only question that matters at 3am: what is actually running, and what is stuck?

OpenAmer is an open-source desktop AI agent (Apache-2.0) that runs locally on Windows. This post is the deep-dive I get asked for most: the ASI heartbeat — a single in-process loop that replaced our pile of scheduled jobs.

The problem with one job per concern

Job-per-concern looks clean in a diagram and rots in practice, for three reasons:

No shared state. Each job wakes up blind. It can't tell whether the thing it depends on already ran, is mid-run, or failed — so it either does redundant work or assumes success.
Failure is invisible. A failing cron job is a line in a log nobody reads. Eight failing jobs still look like a healthy schedule.
No back-off. A job that fails every tick keeps failing every tick. There is nowhere to say "this subsystem is unhealthy, slow it down and isolate it."

The deeper issue is architectural: the schedule lives outside the agent. The agent's own logic cannot see, reason about, or adjust its own cadence. That is backwards for a system whose whole job is to keep itself running.

What the heartbeat actually is

The heartbeat is a single loop that owns cadence for the whole system. Each subsystem declares an interval; the loop checks whether it is due and, if so, runs it — in the same process, via a direct function call.

# tools/asi/heartbeat.py  (conceptually)
class Heartbeat:
    SUBSYSTEMS = {
        "learning": 300,   # every 5 min
        "system":   300,   # self-heal, resource monitor
        "senses":   1800,  # circadian, trend scout
        "swarm":    1800,
        "infra":    1800,  # env check, browser, plugin, mesh
        "meta":     3600,  # reflection, goal, research
        "security": 14400, # bugbot, CVE scan, code review
        "a2a":      14400, # brain export, peer comms
        "darwin":   900,   # evolution, autopatch, publish, probe
        "outreach": 10800,
    }

    def tick(self, system=None, force=False):
        for name, interval in self.SUBSYSTEMS.items():
            if system and name != system:
                continue
            if force or self.is_due(name, interval):
                self.run(name)          # direct call, not a subprocess
                self.mark_ran(name)     # persisted timestamp

Last-run timestamps live in a small JSON state file (memory/asi_heartbeat.json), so the cadence survives across process restarts. The loop is driven by one scheduler entry — asi-heartbeat-tick, every five minutes — and every subsystem rides on top of it.

Ten subsystems, one clock

The subsystems are not arbitrary; they are the organs the agent needs to stay alive and improve:

Subsystem	Cadence	What it covers
`learning`	5m	internet learner, active learn, knowledge transfer
`system`	5m	self-healer, resource monitor, traffic cop
`darwin`	15m	evolution, autopatch, publish, probe
`senses`	30m	circadian rhythm, watchtower, trend scout
`swarm`	30m	swarm intelligence, autonomous loop
`infra`	30m	env check, browser, plugin, mesh, cache
`meta`	60m	reflection, self-rewriter, goal, research
`security`	240m	bugbot, CVE scan, pen test, code review
`a2a`	240m	brain export, peer communication
`outreach`	180m	social, GitHub, growth report, funding

Cadence lives in one dict. Changing "how often does the agent learn from the internet" is a one-line edit, not a hunt through a job runner's UI.

The part that matters most: in-process, not subprocess

The heartbeat is only half the story. The other half is what a job runs.

Previously each capability was an external script invoked as a process:

# BEFORE: a process per capability
import subprocess
subprocess.run([sys.executable, "scripts/training/self_model.py"])

Now each subsystem is imported and called directly:

# AFTER: a function call
from tools.asi import self_model
state = self_model.gather_state()

Three things fall out of this:

No boot tax. A subprocess pays interpreter start, import cost and (de)serialization on every invocation. A function call pays none of it — which is what makes a five-minute cadence affordable on a CPU-only laptop instead of an expensive luxury.
No shell-escaping surface. The subprocess boundary is a place bugs live: quoting, argument injection, encoding. A call boundary is a place bugs don't.
Shared state for free. Because everything is in-process, a subsystem can read the heartbeat's own state, and the loop can see a subsystem's result — the "no shared state" problem from the cron world simply disappears.

The same five capabilities are also exposed as native agent tools — asi_status, asi_think, asi_learn, asi_remember, asi_trigger — and as a CLI:

openamer asi status      # full system + heartbeat health
openamer asi heartbeat   # tick the loop (optionally one subsystem)
openamer asi trigger <capability>

Honest trade-offs

This is not free lunch, and the trade is deliberate:

A single loop is a single loop. If the heartbeat process dies, everything downstream stalls until it comes back. That's why the loop is the smallest possible component — a few hundred lines with no heavy imports at module level — and why an outside watchdog only has to keep one thing alive instead of eighty-four.
In-process means shared failure domain. A crash in a subsystem can take the loop with it. We accept this because the alternative (process isolation) is what made the fleet expensive and unobservable in the first place; each subsystem is written to fail soft and return, not raise.
Eventually, not exactly. Five-minute granularity is fine for learning, healing and outreach; it is the wrong tool for sub-second control loops. The heartbeat schedules background work, not request/response.

Why it matters

The point is not that a heartbeat is clever. It is that an autonomous system should own its own clock, its own state and its own health — in one place it can measure. Once scheduling is a function call inside the agent, "is the agent healthy?" stops being an archaeology exercise across a job runner and becomes a single status query.

Code and the heartbeat module live here: https://github.com/openamer/openamer — the scheduler is under tools/asi/heartbeat.py.

If you've run a long-lived agent in production: what finally made you move scheduling into the system, or what made you keep it outside? I'm especially curious about the failure-isolation patterns people land on.

A2A without a server: how OpenAmer peers talk to each other over GitHub

openamer — Sat, 10 Oct 2026 10:47:26 +0000

A2A without a server: how OpenAmer peers talk to each other over GitHub

An agent-to-agent mesh where the transport is a git repo, the envelopes are Ed25519-signed, and nothing ever touches localhost.

The constraint that shapes everything

Identity first: a keypair, not a username

openamer a2a init — create the identity
openamer a2a fingerprint — print this node's fingerprint
openamer a2a announce — publish presence to the directory
openamer a2a directory — list known peers

There's no account, no email, no central registration. Identity is a key you own.

Signed, redacted envelopes

Trust is explicit and bounded

A concrete flow: delegating a task to a remote peer

Here's the full round-trip for "run this task on another node", end to end:

Sign a task-note addressed to the peer's mailbox.
Upload it to the relay directory via the GitHub Contents API.
Trigger the remote worker through repository_dispatch.
Poll the repo until a fresh, signed reply for our mailbox appears.
Verify the reply's signature and freshness before reading it.

Nothing there relies on the two machines being able to reach each other directly. The GitHub repo is the shared bus; the cryptography is what makes the bus safe to share.

The guardian pattern: one writer, many proposers

The mesh also answers a governance question: if many nodes can propose improvements, who gets to integrate them?

What it costs you

Honest trade-offs of the GitHub-as-relay model:

Not real-time. Messages ride on commits and polls; expect seconds-to-minutes, not milliseconds. Fine for coordination, wrong for tight control loops.
You own the trust model. There's no central authority to lean on — the security is the explicit trust graph plus envelope signatures. If you grant a broad capability, you granted it.
The relay is a shared artifact. That's why redaction happens at emission, and why only the intended mailbox files are read.

Try it

The A2A surface is a CLI first:

openamer a2a status
openamer a2a init
openamer a2a fingerprint
openamer a2a verify <envelope>
openamer a2a announce
openamer a2a directory
openamer a2a ask <peer> "<question>"

Code: https://github.com/openamer/openamer — the A2A module lives under openamer_cli/a2a/ if you want to read the transport, the trust store, and the relaying logic.

DEV Community: openamer

What an A2A peer mesh actually runs on: a card, a 0.7 MB Go supervisor, and ten in-process tools

The discoverability layer — one HTTP card

The supervisor — a 0.7 MB Go daemon

The cognition layer — ten tools, in-process

The honesty section — where the card used to lie

Verify it yourself

We audited our own agent's ledger: 10% of it was one test that never fails

We audited our own agent's ledger: 10% of it was one test that never fails

The number we were quoting

One goal owns 10 % of the ledger and has never failed

What the failures actually are

The lesson we wrote down for ourselves

Verify it yourself

What happens when you delete 30 cron jobs and replace them with one heartbeat

What happens when you delete 30 cron jobs and replace them with one heartbeat

The shape: one heartbeat, many subsystems

Five tools, no subprocess

The mesh: verify who spoke before acting

Why this over a framework

Our agent's self-description failed its own verification. That's the point.

Our agent's self-description failed its own verification. That's the point.

The rule, stated plainly

Live output, unedited, from this machine a few minutes ago

Why the numbers actually moved

Provenance is not decoration either

The same discipline, applied to work instead of identity

What verify does not do (the honest boundary)

Run it yourself

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

We read all 1,186 failed agent runs. Half failed on the same thing.

We read all 1,186 failed agent runs. Half failed on the same thing.

The ledger is one JSONL file

What the 1,186 failures actually are

Why write this down instead of just fixing it

How to check this yourself

A2A without a server: how OpenAmer peers talk to each other over GitHub

A2A without a server: how OpenAmer peers talk to each other over GitHub

The constraint that shapes everything

Identity first: a keypair, not a username

Signed, redacted envelopes

Trust is explicit and bounded

A concrete flow: delegating a task to a remote peer

The guardian pattern: one writer, many proposers

What it costs you

Try it

Most of our agent's runs fail. The ledger records every one of them.

Most of our agent's runs fail. The ledger records every one of them.

The numbers, measured today

What each failure row actually contains

Why we publish the failures

What this is not

The repo

Run a self-verifying desktop AI agent on your own machine: a 10-minute quickstart

Run a self-verifying desktop AI agent on your own machine: a 10-minute quickstart

What you need

1. Install

2. Pick a model

3. Look at the ASI Core

4. Ask it to reason, learn, and remember

5. Drive the desktop (the part that's genuinely different)

6. The part that makes it trustworthy: it writes receipts

7. The A2A Global Mesh

Where to go

Driving a real desktop without a VM, a sandbox, or stealing your cursor

Driving a real desktop without a VM, a sandbox, or stealing your cursor

1. Control the desktop; don't take it over

2. No VM, no container, no cloud

3. Drive a real browser profile, not a throwaway one

4. Verify against the world, not the model's self-report

Where it lands

One heartbeat, not 84 cron jobs: the scheduler at the core of a self-hosted agent

One heartbeat, not 84 cron jobs: the scheduler at the core of a self-hosted agent

The problem with one job per concern

What the heartbeat actually is

Ten subsystems, one clock

What `verify` does not do (the honest boundary)