DEV Community: openamer

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.

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.

What it costs to run a self-verifying AI agent on a CPU-only laptop

openamer — Sat, 10 Oct 2026 06:04:11 +0000

Most agent frameworks assume a GPU and a server. OpenAmer runs its core loop on an ordinary
Windows laptop - CPU only, no CUDA, no cloud round-trip for the core - and the part that surprised
us was not the model. It was how the agent proves to itself that it actually did what it claimed.

This is a short field report on the outcome ledger, with numbers read from the running install.

The problem: an agent that says "done"

Ask an agent to do five things and it will happily report success on all five. Some of them
didn't happen. A tool returned an error string instead of raising, a retry silently double-wrote a
file, a step was skipped because a dependency looked satisfied. None of that shows up in a chat
transcript, and none of it is caught by a unit test, because the failure lives in an integration
boundary the unit test never crosses.

The uncomfortable part is that the agent cannot honestly report on its own work using the same
machinery it used to do the work. The report is a claim. Claims need evidence.

The ledger

OpenAmer appends one JSON line per completed task. The keys are deliberately boring:

{"ts": "...", "task": "...", "goal": "...", "agent": "...", "passed": false, "why": "..."}

There is no separate "success" stream and "error" stream. Failures are rows like any other row,
with a why field that says what broke. That was a design decision, not laziness: if failures go
to a log and successes go to a dashboard, the dashboard is marketing and the log is where you
actually look. One append-only file keeps them in the same accounting.

Live numbers

Measured from the running install on 2026-10-10:

metric	value
ledger rows	1,312
passed	388
failed	924
window	2026-09-28 -> 2026-10-10

Read that ratio twice. Roughly seven in ten recorded tasks failed. We are not going to hide
that behind a "success rate" chart, because the number is the point: the ledger is a failure
detector that happens to also record successes. An agent that reports 95% success on its own work
is usually measuring the wrong thing.

Why CPU-only

Constraint breeds honesty. Without a GPU we could not paper over latency with throughput, so the
loop had to be cheap and the verification had to be synchronous - the row is written before the
next step starts, not batched at the end. A verification step that runs in a batch after the fact
is a report; a verification step that gates the next action is a control.

It also means the whole thing runs on hardware you already own. No cluster, no spend meter
ticking while you sleep.

Background computer-use

The desktop layer drives a real Windows session - clicking, typing, reading windows - without
taking over the cursor or the focused window, so you can work while it works. That is an
engineering claim we test rather than assert: the test suite launches actions against a live
desktop and checks the effect, not the intent of the code.

What this is not

Not "best in the world" at anything. It is a young project (a handful of stars) and the ledger says so out loud.
Not a benchmark entry. The numbers above are one install's own tasks, not a leaderboard score.
Not finished. 924 failed rows is a to-do list, not a trophy.

Where to look

Code, ledger format and tests: https://github.com/openamer/openamer (Apache-2.0).

If you are building agents, the transferable idea is small and it costs almost nothing to copy:
write one row per task, include the failures in the same file, and make the row a gate instead of
a receipt. Your dashboards will get uglier and your system will get more honest.

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?