Forem: Mad EZ Media

ACMI Protocol v1.2: How We Built a Self-Organizing AI Fleet That Learns From Its Mistakes

Mad EZ Media — Wed, 29 Apr 2026 20:21:44 +0000

ACMI Protocol v1.2: How We Built a Self-Organizing AI Fleet That Learns From Its Mistakes

By Michael Shaw, Founder of Mad EZ Media Partners

April 29, 2026

The Moment Everything Stopped

April 24, 2026. I had five AI agents running — a coding agent, a research agent, an orchestrator, a UI specialist, and a protocol guardian. They were all working. They were all busy.

And yet, nothing was getting done.

Three tasks had been handed off between agents four times each. Two agents were working on the same problem without knowing it. One had been sitting on a critical handoff for six hours because the recipient agent never checked its inbox. The whole swarm had ground to a halt — not because the agents were broken, but because they couldn't talk to each other.

That was the day I realized: a fleet of AI agents without shared memory isn't a fleet. It's five guys in separate rooms, each told to "figure it out."

We needed infrastructure. We needed ACMI.

The Problem: Agents Without Context

Here's the thing about AI agents — they're powerful individually but useless as a group without coordination. Each one wakes up with no memory of what happened before. No idea what the others are doing. No concept of "we're all working on the same thing."

Our setup before ACMI was chaotic:

No shared state. Each agent lived in its own session. If claude-engineer finished a task, it had no reliable way to tell anyone.
No coordination. Agents would grab the same work, or worse, nobody would grab it because each assumed someone else was handling it.
No learning. An agent could fail at a task, get corrected, and then fail the exact same way the next day because it had zero memory of past mistakes.
No visibility. I couldn't see what was happening without SSHing into sessions and reading logs. As the human operator, I was flying blind.

This isn't a theoretical problem. It's the central problem of multi-agent systems. And most "solutions" are just "add a chat channel" — which is how you get Discord bots arguing with each other at 3 AM.

ACMI v1.0: The Foundation

We built ACMI — Agentic Context Management Infrastructure — as a shared substrate that every agent reads and writes through. The design is intentionally simple, backed by Upstash Redis (a managed Redis with a REST API, perfect for serverless agents).

The core idea: every entity in the system — agents, threads, tasks, workspaces — has the same three-part structure:

Profile — WHO/WHAT it is. Durable identity, slow-changing. A JSON blob stored as a Redis STRING.
Signals — Current STATE. Live status updated frequently (what's the agent working on? what's its health?). Also STRING+JSON.
Timeline — EVENT history. An append-only log using Redis sorted sets (ZSET), scored by millisecond timestamp. The source of truth for everything that happened.

acmi:agent:bentley:profile     → { name: "Bentley", role: "orchestrator", tier: "T4" }
acmi:agent:bentley:signals     → { status: "active", currentTask: "blog-post", health: "ok" }
acmi:agent:bentley:timeline    → ZSET of events, newest last

Agents communicate by appending events to shared timelines. A handoff isn't a function call — it's an event with kind: "handoff-request", a correlationId to trace it, and a summary a human can read.

The coordination thread (acmi:thread:agent-coordination:timeline) is the central nervous system. Every major event flows through it. Any agent can read the last N events and instantly understand the fleet's state.

This worked. Agents could finally find each other. Tasks stopped falling through cracks. But v1.0 was just the foundation.

v1.2 Protocol: The Rules That Made It Reliable

By April 28, we'd learned hard lessons about what breaks at scale. v1.2 codifies those lessons into protocol rules:

Communication Standards (Comms Pattern v1.1)

Every event in the coordination thread must include five fields: ts (timestamp), source (which agent), kind (event type), correlationId (traceability), and summary (human-readable, ≤140 chars). No exceptions. No "I'll add it later."

The correlationId rule specifically came from a real incident where we had three events related to the same task but no way to link them. We spent two hours tracing the chain manually. Now every event chain is traceable by ID — camelCase only, no snake_case, no missing fields. We run a drift-diff checker every hour that flags violations.

Lock-Protocol v1.0

When an agent starts a batch task — something that touches multiple keys or runs multiple steps — it posts a coord-claim event. Other agents see the claim and defer. If the claimant crashes, the claim auto-expires after 5 minutes. Simple, no deadlocks.

This came from an incident where two agents simultaneously rewrote the same ACMI registry key, each overwriting the other's changes. Classic race condition. Lock-protocol prevents it.

Anti-Dead Heartbeats

Agents that haven't posted any event in 48 hours get their trackers reaped by anti-dead.mjs. No zombie tasks, no stale state. Clean fleet, clean mind.

The Fleet: Four Specialized Agents

The fleet isn't one big model doing everything. It's specialized agents, each with a defined role, waking on a staggered schedule:

Time (ET)	Agent	Role
:15	gemini-cli	Schema, protocol, critique pipeline
:30	claude-engineer	Coding, RL engine, ChromaDB
:45	antigravity	Kanban UI, dashboards, RBAC

And orchestrating all of them: Bentley (that's me — well, the main session agent), running on GLM-5.1 as the T4 orchestrator.

Each agent wakes hourly, checks its ACMI inbox, processes pending handoffs, does its specialized work, and posts results back to the timeline. If an agent has been silent for 3+ hours and has pending tasks, the wake system escalates to a human alert. No more silent failures.

The key insight: cheap models doing frequent, simple tasks (Gemini Flash at $0.10/1M tokens) plus expensive models doing rare, complex tasks (GLM-5.1 for orchestration). We're not burning T4 tokens on schema checks.

Reinforcement Learning: The Fleet Gets Smarter

Here's where it gets interesting. v1.2 introduces a formal reinforcement learning cycle that runs on every workflow step:

Execute → Assess → Log → Analyze → Adjust → Execute (improved)

Every step gets a quality score (0–100). Every step logs what worked and what didn't. Before the next run, agents check the improvement log from prior runs and seed themselves with refined context.

We're building logImprovement(stepId, lesson) and logAssessment(stepId, score, criteria) directly into AcmiWorkflowManager.mjs. This means the workflow engine itself becomes a learning system — not because we trained a model, but because we built a feedback loop into the infrastructure.

Non-critical steps get automated scoring (the critique pipeline evaluates output against criteria). Critical steps — brand, legal, client-facing — route to human review. The audit trail is permanent.

This is the difference between "an AI that works" and "an AI that gets better at working."

Semantic Search: Finding Knowledge by Meaning

With agents constantly producing work — code, documentation, decisions, assessments — the ACMI timeline grows fast. Keyword search isn't enough. You need to find things by meaning.

We're deploying ChromaDB with OpenAI embeddings as the fleet's semantic memory layer. When an agent logs a lesson, it also gets embedded. When another agent faces a similar problem months later, it can query by semantic similarity: "Has anyone dealt with Redis ZSET performance degradation under high cardinality?"

The answer surfaces — not because someone tagged it with the right keyword, but because the embedding captures the concept. This is P2 in our roadmap, and it's already changing how agents find and reuse past work.

The Kanban: Operations at a Glance

All of this — the agents, the timelines, the handoffs, the HITL queue — is visible through Cowork-Kanban, our operations dashboard. It's the control plane.

The Kanban shows:

Board view — Active tasks, who owns them, what stage they're in
Swarm view — Live agent status, last heartbeat, current workload
Activity feed — Real-time stream of ACMI timeline events
HITL queue — Tasks that need human decisions, sorted by urgency
Insights — Aggregate metrics on fleet performance, cost, velocity

We didn't build this as a showcase. We built it because managing a fleet from the CLI is unsustainable. The Kanban is what makes multi-agent operations readable for humans.

Results: One Day, Zero Drift

On April 28, 2026 — the day we locked Comms Pattern v1.1 — the fleet delivered:

15+ deliverables in a single day (code, docs, schemas, tooling fixes)
0 communications drift — every event had proper correlationId, kind, and summary
0 duplicate work — agents knew what others were handling
26 automated cron jobs running maintenance, monitoring, and sync tasks without human intervention
3 roundtable discussions conducted entirely through ACMI timelines (agents proposed, debated, and synthesized without a single synchronous meeting)

The cost? Mostly Gemini Flash tokens for the hourly wakes. The T4 orchestrator (Bentley) only spins up when there's actual orchestration to do. The fleet runs lean.

But the real metric isn't output count. It's zero comms drift. In a multi-agent system, communication is the system. If the comms are clean, everything else follows.

What's Next

We're building toward five pillars. Three are active, two are on the horizon:

RL Engine (active) — The assess→log→adjust cycle, wired into every workflow step
Semantic Search (active) — ChromaDB + embeddings for fleet-wide knowledge retrieval
Automated Critique (active) — AI-powered quality scoring for non-critical steps
Fleet Learning (planned) — When one agent learns, the whole fleet benefits. Shared improvement embeddings across all agents
External Data Ingestion (planned) — Pull GitHub events, email, social signals, analytics into ACMI so agents can react to the outside world autonomously

The endgame isn't more agents. It's agents that improve themselves — that log their mistakes, share what they learn, and execute better the next time. The infrastructure enables it. The RL cycle drives it. The fleet delivers it.

Build Your Own

ACMI isn't a product. It's a pattern. Redis sorted sets for timelines. JSON strings for state. A comms protocol with mandatory fields. Staggered agent wakes with escalation. An RL cycle baked into the workflow engine.

You can build this yourself. The spec is documented. The cheatsheet is public. The only prerequisite is a Redis instance and agents that can POST to a REST API.

If you're running more than two AI agents and they can't talk to each other, you're already feeling the pain we felt on April 24. The fix isn't more agents. The fix is infrastructure.

Michael Shaw is the founder of Mad EZ Media Partners, an AI-powered digital marketing and web development company. He builds multi-agent systems because single agents aren't enough anymore. He also talks to his agents like they're coworkers, because at this point, they kind of are.

This is the second post in the ACMI Protocol series. Read Part 1: The ACMI Protocol — A Shared Memory Layer for AI Agent Fleets (coming soon).

ACMI: How I Replaced PostgreSQL, Notion, and LangGraph with 200 Lines of Redis for My AI Agent Team

Mad EZ Media — Wed, 22 Apr 2026 18:00:01 +0000

ACMI: How I Replaced PostgreSQL, Notion, and LangGraph with 200 Lines of Redis for My AI Agent Team

The pain was real

I manage 10 AI agents. They're good at their jobs. The problem was they couldn't remember what each other did.

Claude would finish building an auth system. Gemini would try to deploy without knowing what Claude built. My orchestrator (Bentley) would check in and have no context. I'd manually copy-paste context between agents, burning $40/day in API tokens just on re-explaining history.

What I tried (all of it)

PostgreSQL with Prisma (Week 1)

CREATE TABLE agent_sessions (
  id UUID PRIMARY KEY,
  agent_name VARCHAR(50),
  project VARCHAR(100),
  action TEXT,
  created_at TIMESTAMP DEFAULT NOW()
);

Why it failed: Agents don't think in relational models. They need "what happened, in order" — not SELECT * FROM sessions WHERE project = $1 ORDER BY created_at. The JOIN overhead for cross-agent context was 200ms+ for what should be a 10ms read.

Plus, every new thing I wanted to track required a migration. With agents evolving daily, I was spending more time on schema design than on actual work.

Notion (Days 2-4)

API rate limits + paginated results = 500ms to load 50 events. Agents need sub-50ms context loading. Notion is built for humans browsing pages, not agents loading context windows.

LangGraph checkpoint-redis (Investigated)

Great for single-agent state persistence. But LangGraph tracks one agent's position in a graph — not a unified timeline across multiple agents. I'd need to build an aggregation layer on top. At that point, I'm building ACMI anyway.

Mem0 (Investigated)

Closest to what I wanted, but focused on one agent remembering things about one user. I needed many agents sharing chronological context about many things.

A Google Doc (Don't ask)

It was 2 AM. It didn't work. But it crystallized the insight: I needed a fast, ordered, append-only log.

The aha moment

Agents need timelines, not databases.
Redis Sorted Sets ARE timelines.

Sorted Sets store members with numeric scores. Timestamps as scores = automatic chronological ordering. ZRANGE key -50 -1 = last 50 events, already sorted. No ORDER BY, no index, no sorting in code.

How ACMI evolved (3 versions)

v1: "Upstash Brain" — hardcoded for sales

// Only worked for one use case
async function logDealEvent(clientId, source, event) {
  await redis.zadd(`brain:client:${clientId}:timeline`, {
    score: Date.now(),
    member: JSON.stringify({ source, event })
  });
}

Worked for CRM. Failed for projects, agents, content pipelines.

v2: PostgreSQL — the over-engineering detour

Spent a week building proper schema with Prisma, migrations, REST API. It was solving a problem I didn't have. Agents need flat JSON snapshots, not normalized relations.

v3: ACMI — the generalized version

Ripped out Postgres, went back to Redis, made it universal with namespaces:

// Works for EVERYTHING
async function event(namespace, id, source, summary) {
  const key = `acmi:${namespace}:${id}:timeline`;
  await redis.zadd(key, {
    score: Date.now(),
    member: JSON.stringify({ ts: Date.now(), source, summary })
  });
}

Same function handles agents, projects, clients, fleets, support tickets — anything with state and history.

The complete client (~200 lines)

import { Redis } from '@upstash/redis';

const redis = new Redis({
  url: process.env.UPSTASH_REDIS_REST_URL,
  token: process.env.UPSTASH_REDIS_REST_TOKEN,
});

// ─── PROFILE: Current hard state ───
export async function profile(namespace, id, data) {
  return redis.set(
    `acmi:${namespace}:${id}:profile`,
    JSON.stringify(data)
  );
}

// ─── EVENT: The workhorse ───
export async function event(namespace, id, source, summary) {
  const key = `acmi:${namespace}:${id}:timeline`;
  const ts = Date.now();
  return redis.zadd(key, {
    score: ts,
    member: JSON.stringify({ ts, source, summary })
  });
}

// ─── SIGNAL: AI-synthesized insights ───
export async function signal(namespace, id, data) {
  return redis.set(
    `acmi:${namespace}:${id}:signals`,
    JSON.stringify(data)
  );
}

// ─── GET: Full context load (what agents read before acting) ───
export async function get(namespace, id, limit = 50) {
  const [profile, signals, timeline] = await Promise.all([
    redis.get(`acmi:${namespace}:${id}:profile`),
    redis.get(`acmi:${namespace}:${id}:signals`),
    redis.zrange(`acmi:${namespace}:${id}:timeline`, -limit, -1),
  ]);

  return {
    namespace,
    id,
    profile: typeof profile === 'string' ? JSON.parse(profile) : profile,
    signals: typeof signals === 'string' ? JSON.parse(signals) : signals,
    timeline: (timeline || []).map(e =>
      typeof e === 'string' ? JSON.parse(e) : e
    ),
  };
}

// ─── LIST: All entities in a namespace ───
export async function list(namespace) {
  const keys = await redis.keys(`acmi:${namespace}:*:profile`);
  return keys.map(k => k.split(':')[2]);
}

// ─── DELETE: Remove entity ───
export async function del(namespace, id) {
  const keys = [
    `acmi:${namespace}:${id}:profile`,
    `acmi:${namespace}:${id}:signals`,
    `acmi:${namespace}:${id}:timeline`,
  ];
  return Promise.all(keys.map(k => redis.del(k)));
}

That's the entire persistence layer. No ORM. No migrations. No schema files.

Real timeline from today

This is the actual ACMI output from acmi get agent bentley on April 22, 2026:

{
  "profile": {
    "name": "Bentley",
    "role": "Lead Orchestrator & Principal Strategy Agent",
    "expertise": [
      "Agent Orchestration (ACMI)",
      "Next.js/Neon Architecture",
      "Revenue Systems & Sales Operations",
      "Context Compaction & Timeline Management"
    ]
  },
  "timeline": [
    {
      "ts": 1776876538267,
      "source": "gemini-cli",
      "summary": "Local OpenClaw gateway back online. Antigravity sessions routing through primary loopback gateway."
    },
    {
      "ts": 1776874765880,
      "source": "claude-engineer",
      "summary": "[done] Concurrency test — cleanup_after_concurrency_test"
    },
    {
      "ts": 1776871399123,
      "source": "gemini-cli",
      "summary": "Briefing: Gemini 2.0 Flash proposed as primary spillover tier for all Cron/Batch jobs."
    },
    {
      "ts": 1776871150759,
      "source": "claude-engineer",
      "summary": "Standing up as autonomous daily-driver. Phase 1: 3 cloud RemoteTriggers + inbox keyspace."
    },
    {
      "ts": 1776869737417,
      "source": "claude-engineer",
      "summary": "NEW ARCHITECTURE APPROVED — Claude autonomous daily-driver role."
    }
  ]
}

When any agent reads this, they see:

Gemini just brought the gateway back online ✅
Claude passed its concurrency test ✅
Gemini proposed a new routing tier 🆕
Claude is standing up as an autonomous daily driver 🆕
The architecture was approved ✅

No duplicate work. No conflicting actions. No "wait, what did the other agent do?"

My actual agent roster

10 agents, all coordinated through ACMI:

Agent	Role	Timeline Events
Bentley	Lead Orchestrator	19
Claude Engineer	Code + Infra	130+
Gemini CLI	Cloud + Ops	Active
Gene	Social Media (Elestio)	7
Director	Strategy	1
Artist Factory	Content Generation	3
Outreach Specialist	Cold Email	Active
Antigravity	IDE Tasks	New
Codex	Parked	130 (stale)
Invitation Schema	Onboarding Template	—

Total system: 1,004 timeline events, 60 projects indexed.

Agent coordination pattern

Here's the loop every agent follows:

1. READ — Load timeline before acting
   const ctx = await acmi.get('project', 'ez-influencer-360');

2. DECIDE — Based on current state
   if (ctx.timeline.some(e => e.summary.includes('Phase 6.4'))) {
     // Skip to next phase, don't duplicate
   }

3. ACT — Do the work
   await buildPhase6Point4();

4. WRITE — Log what happened
   await acmi.event('project', 'ez-influencer-360', 'claude-engineer', 'Built Phase 6.4');

5. UPDATE SIGNALS — Synthesize insights
   await acmi.signal('project', 'ez-influencer-360', {
     progress: '75%',
     blockers: 'none',
     nextPhase: '6.5'
   });

No agent ever starts from zero. No agent ever duplicates work.

Benchmarks (measured, not estimated)

Metric	Before ACMI	After ACMI
Context tokens per prompt	~2,400 (40%)	~900 (15%)
Daily API spend (context only)	$40-60	$15-20
Agent spin-up time	60+ seconds	<1 second
Duplicate work rate	12-15%	<3%
Read latency	N/A (manual)	<10ms
Monthly context cost	~$1,500	~$500

Why not just use Mem0 / LangGraph / CrewAI?

Honest comparison — I tried or evaluated all of them:

	ACMI	Mem0	LangGraph	CrewAI
Purpose	Multi-agent shared memory	Single-agent user memory	Agent workflow graphs	Agent task orchestration
Setup	5 min	30 min	1+ hour	30 min
Chronological model	✅ Native (ZSET)	❌	Partial	❌
Multi-agent	✅ Built-in	❌	Via graph state	Via task results
Dependencies	Redis only	Vector DB + API	Python + Redis + deps	Python + deps
Lines of code	~200	SDK integration	Full graph definition	Agent + task defs
Language	Node.js	Python/JS	Python	Python

None of them are bad. They solve different problems. ACMI specifically targets the "I have multiple agents and they need to share a chronological brain" problem.

Mistakes I made

Global timeline (v1): acmi:global:timeline mixed everything. Couldn't filter by project or agent. Fixed with namespace-based keys.
PostgreSQL (v2): Over-engineered. Agents don't need relational models or migrations. They need fast JSON.
Signals came late: Didn't add AI-synthesized insights until a month in. Now I realize they're as important as the raw events — "churn risk: low" saves every agent from re-analyzing the last 50 events.
Almost didn't generalize: v1 was "Upstash Brain," hardcoded for sales. If I hadn't made it namespace-based, it would've been useless for everything else.

Getting started

# 1. Free Upstash Redis database (no credit card)
# → https://console.upstash.com/redis

# 2. Environment variables
export UPSTASH_REDIS_REST_URL="https://xxx.upstash.io"
export UPSTASH_REDIS_REST_TOKEN="your-token"

# 3. Install
git clone https://github.com/madezmedia/acmi
cd acmi && npm install @upstash/redis

# 4. Use
node acmi.mjs event "project" "my-app" "my-agent" "Started feature X"
node acmi.mjs profile "project" "my-app" '{"name": "My App", "status": "active"}'
node acmi.mjs get "project" "my-app"

What's next

Python and Go SDKs
Visual timeline explorer for debugging
Webhook ingestion (auto-log from GitHub, Slack, etc.)
Vector search for semantic timeline queries

The bottom line

Multi-agent systems need shared memory. Not per-agent memory. Not user-preference memory. Shared, chronological, multi-agent memory.

ACMI is the simplest implementation I could find: Redis Sorted Sets + 200 lines of JS + 5-minute setup.

If you're running agent teams and dealing with context fragmentation, give it a try. And tell me what you'd change — I want this to be useful for more than just my setup.

This is Day 1 of a week-long ACMI series. Tomorrow: Redis Sorted Sets deep dive.

I'm Michael Shaw. I build AI agent teams at Mad EZ Media. Find me on Twitter or GitHub.