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.