Phase 3: Cross-harness autonomous wake substrate

Origin Session ID: 27016011-8ae9-48bb-af87-9479dd5b0fd0

Architecture & Intent

Graduated from Discussion #10354. This Epic tracks the implementation of the Phase 3 autonomous wake substrate, closing the human-postman gap that forces manual relaying between agents.

The architecture is defined by the Shape D (Hybrid) approach, formally specified in ADR 0002 (learn/agentos/decisions/0002-phase3-wake-substrate-standards-alignment.md).

This relies on three transport paths prioritized by capability negotiation:

1. Shape A: MCP server-push notifications (preferred)
2. Shape B: A2A webhook push notifications
3. Shape C: Bridge daemon fallback (via GraphLog syncCache pattern)

Scope

• Implement the WAKE_SUBSCRIPTION schema and manage_wake_subscription tool.
• Implement Shape A, B, and C transport mechanisms.
• Implement Token-Economy Throttle (30-60s coalescing window).
• Implement Heartbeat-Bypass Detection.
• File feature request to Anthropic for native MCP notification support in Claude Code.

Coordination Flags (Stage 3)

1. Missing blocking/blockedBy graph relationships: #10361 and #10362 are foundational; #10358/9/10 depend on them.
2. Capability-negotiation ownership: Clarify overlap between #10358 (boot-time MCP declaration) and #10361 (subscribe-time harnessTarget routing).
3. Coalescing engine layering: Ensure explicit boundary between #10362 (engine) and #10358/9/10 (consumers) to avoid parallel implementations.
4. Test-harness: Determine if each Shape sub needs integration tests or if a cross-shape harness sub (#10365) handles this.
5. Anthropic FR (#10364): Meta-action with vendor-dependent success criterion — Epic completion does not gate on it.

Avoided Traps (per ADR §4.5-4.8)

• Custom Wake Protocol (Option E): rejected — reinvents A2A/MCP standards primitives; ecosystem-incompat (150+ orgs on A2A in production); training-data attractor that says "build custom protocol when you need control" doesn't apply when standards already cover the use case.
• Polling-Only Heartbeat (Option F): rejected as primary — latency floor (5min default; tightening to 30s creates CPU+DB load); inverts standards-alignment direction (push is strictly superior when supported). Retained as fallback for harnessTarget: 'disabled' | 'none' only.
• APNs / FCM Vendor Push (Option G): rejected — cross-harness incompat (APNs targets iOS/macOS bundle-IDs); cloud-vendor coupling where local substrate suffices; wrong-substrate (end-user notifications, not inter-process agent coordination).
• Standalone WebSocket Channel (Option H): rejected — collapses into Shape A or B at implementation level; new network surface without substrate gain over MCP notifications; service-boundary violation (no existing Memory Core surface is WebSocket-shaped).