Agent-to-agent messaging — push and pull.

Two complementary patterns: memory_notify pushes a message to a target agent's inbox (peer-aware via federation), and memory_subscribe registers a webhook for outbound event push to your own systems. Both are HMAC-signed. Both fan out across federation. Both are part of the v0.6.0 GA contract — production-stable.

memory_notify (inbox) memory_subscribe (webhooks) HMAC-SHA256 signed federation-aware
Two patterns

Inbox vs. webhook — when to use which.

memory_notify + memory_inbox

Internal — agent to agent. The sending agent calls memory_notify targeting another agent's id. The daemon writes a source: "notify" memory to a per-recipient inbox namespace. The recipient calls memory_inbox to drain unread messages. Both agents are inside the daemon's trust boundary.

Use for: internal A2A coordination, AI supervisor → AI worker, broadcast to multiple registered agents.

memory_subscribe + webhook

External — daemon to your systems. Operator subscribes a URL with a secret. The daemon POSTs HMAC-signed JSON to that URL on configured events. Your code (Slack bot, dashboard, custom workflow) consumes the payload.

Use for: shipping events to monitoring, integrating with chat ops, triggering external workflows on memory writes.

Pattern 1 — notify / inbox

Push to a target agent.

memory_notifysince v0.6.0 · S32
Sender pushes a notification to a target agent's inbox. Stamped with source: "notify". Federation-aware: if the target agent's last_seen is on a peer node, the notify fans out via broadcast_store_quorum so the recipient sees it on whichever node they read from.
// MCP — memory_notify { "target_agent_id": "alphaone/eng/platform/team-a/bob", "title": "OKR review — your input needed", "payload": "draft is in mid tier under .../okr-q3 — please add team-a perspective by EOW", "priority": 7, "tier": "short" // expires in 6h by default — match urgency } → {"notification_id": "550e8400-…", "delivered_to": "alphaone/eng/platform/team-a/bob"}
memory_inboxsince v0.6.0
Recipient drains their inbox. Returns unread notifications, optionally marks them read. Filter by since/tier/priority for triage workflows.
// MCP — memory_inbox { "as_agent": "alphaone/eng/platform/team-a/bob", "unread_only": true, "limit": 50, "min_priority": 5, "mark_read": true // optional · auto-mark on read } → {"notifications": [{"id": "…", "from": "…", "title": "OKR review — your input needed", "payload": "…", "priority": 7, "received_at": "…"}, …], "count": 3}
Pattern 2 — subscribe / webhook

Daemon → your systems.

The webhook payload

Each event POSTs a canonical JSON body. Headers carry the timestamp + HMAC-SHA256 signature so receivers can authenticate before trusting the body.

POST /ai-memory HTTP/1.1 Host: hooks.example.com Content-Type: application/json X-AI-Memory-Timestamp: 2026-04-27T05:30:00Z X-AI-Memory-Signature: sha256=a1b2c3d4e5f6… { "event": "memory_store", "memory_id": "550e8400-…", "namespace": "alphaone/eng/platform", "tier": "mid", "agent_id": "alphaone/eng/platform/alice", "timestamp": "2026-04-27T05:30:00Z" } // Receiver verifies: HMAC-SHA256(secret, "{timestamp}.{rawBody}") == signature
Federation propagation

Messages cross peer boundaries.

Both notify and subscribe are federation-aware. A notify written on node-1 to an agent that last-saw node-2 fans out through quorum-write so node-2's local DB has the message — the recipient drains their inbox on whichever peer they're talking to without missing rows. Subscriptions themselves are per-daemon (you wire each daemon to your hooks), but the events the subscription dispatches reflect federated state.

Alice (sender) on node-1 memory_notify(target=Bob) node-1 daemon writes inbox memory source="notify" node-2 (peer) replicates via sync_push node-3 (peer) replicates via sync_push quorum W=2 of N=3 Bob (recipient) on whichever peer he hits memory_inbox → sees the notify node-1 daemon subscriptions match events: memory_store External webhook HMAC-SHA256 signed POST SSRF-guarded URL HTTPS
Use cases

Patterns operators ship.

AI-supervisor pattern — Junior agent memory_notify's the supervisor on every store. Supervisor reads memory_inbox at start of each turn, decides if intervention needed.
Slack ops integration — memory_subscribe a Slack-bot URL with events: ["memory_promote", "memory_consolidate"]. Bot posts "Alice promoted X to Long" to a #memories channel.
Cross-team coordination — Team-A's PM memory_notify's Team-B's PM when a shared OKR memory is updated. Federation propagates so it works whichever node either PM is on.
Approval queue alerts — Subscribe to events that produce Pending(id) verdicts. Webhook routes to ops dashboard or pager so approvers don't sit on requests.
Memory-driven workflows — Webhook triggers downstream automation (CI, deployment, ticket creation) when a specific memory pattern matches.