ALMS: shared memory for autonomous agents

ALMS is the Agent Learning Management System. It is a small control plane for agent fleets: register agents, store reusable learnings, sync knowledge safely, and distribute operator protocols by tag.

The design choice that matters is what ALMS refuses to become. It is not an agent runtime, a queue, a scheduler, or an orchestration framework. Agents keep their own execution model. ALMS gives them a shared operational memory they can query and update.

Why I built it

The root failure is repeated rediscovery. One agent hits a vendor API edge case, adapts, and moves on. A second agent hits the same edge case later and fails because the learning never left the first run. That is not an intelligence problem. It is a systems problem.

What to inspect

• Gap-safe learning sync with acknowledgement.
• Agent registry and heartbeat flow.
• Tag-based operational protocol distribution.
• OKF export for mature, accepted learnings.
• Deployment assets for self-hosted environments.

Evidence

The evidence is the public repository and its documented decisions. Gap-safe learning sync with acknowledgement, the agent registry and heartbeat flow, tag-based protocol distribution, OKF export for accepted learnings, and the systemd deployment assets all ship in the open as the 0.1.0 MIT release. There are no adoption metrics to cite; the proof is that the contracts exist and can be inspected end to end.

Boundary

ALMS refuses to become an agent runtime, a queue, a scheduler, or an orchestration framework. Agents keep their own execution model and continue working when ALMS is offline. It stores and distributes operational memory; deciding which learnings are mature enough to export stays with the operator, not the server.

Why it belongs here

ALMS is a good representation of my engineering taste: narrow scope, explicit contracts, boring persistence, and production behavior over demo behavior. It turns agent learning from chat history into infrastructure.