IAMP vs CloudEvents: Why We Built a New Message Protocol

We considered adopting CloudEvents when designing OwlMQ's message format. It's a CNCF standard, well-supported, and widely understood. Ultimately, we built our own — IAMP — and this post explains the decision.

What CloudEvents gets right

CloudEvents solves interoperability. If you're integrating Kafka, Pub/Sub, EventBridge, and Knative in the same architecture, CloudEvents gives you a common envelope. The spec is clean: id, source, specversion, type, data. That's it.

For event-driven architectures where the events cross system boundaries and need to be understood by multiple platforms, CloudEvents is the right choice.

What CloudEvents doesn't do

CloudEvents is silent on three things that matter deeply for a message queue:

• Intent: What does this message mean semantically? CloudEvents has type (a string), but no standard for expressing intent in a way a router can reason about.
• Priority: Should this message be processed before others? CloudEvents has no priority concept.
• SLA: How long can this message wait? There's no deadline or SLA expression in the spec.

These aren't minor omissions. They're the core inputs to AI-powered routing, priority queuing, and self-healing playbooks.

The IAMP envelope

IAMP adds a metadata block to every message:

{
  "intent": "payment.process",
  "metadata": {
    "priority": "high",
    "ttl": 3600,
    "sla": { "maxLatencyMs": 200 }
  }
}

This is enough for OwlMQ's router to make AI-powered routing decisions, enforce SLAs, and trigger playbooks — all without any per-tenant configuration.

Compatibility

IAMP is a superset of CloudEvents. If you publish a CloudEvents-formatted message to OwlMQ, it works — the router uses best-effort intent inference from the type field. You can opt into the full IAMP envelope incrementally. We provide migration tooling to add IAMP fields to existing publishers without changing your consumer contracts.