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?
Top comments (0)