Why this matters now
Channel ecosystems are changing fast, and some channels are best handled as plugin-only paths.
If you keep every channel tightly coupled to core flow, maintenance cost rises every quarter.
Reference:
When to move to plugin-only
Move when at least two are true:
- protocol changes are frequent
- auth model differs across channels
- one workflow must serve multiple channels
- you want channel-specific release cadence
3-phase migration plan
Phase 1: define boundaries
- separate channel I/O, auth, and retry from core orchestration
- define one plugin contract for input and output
- keep core flow channel-agnostic
Phase 2: run dual paths
- route new channels through plugins
- keep old channels on legacy path temporarily
- run A/B regression on identical tasks
Phase 3: cut over safely
- migrate low-risk channels first
- migrate high-volume channels second
- replay historical incidents after each migration
Governance minimum
- version and changelog required per plugin
- explicit permissions and external dependency declaration
- circuit-breaker and fallback behavior required
- regression checklist required before release
Handling emerging ecosystems
For Matrix, Nostr, and Zalo style integrations, keep them in experiment plugins first.
Do not merge them directly into core runtime before observing:
- auth stability
- message ordering consistency
- retry and failure control
Pass criteria
- core orchestration no longer depends on channel-specific details
- single channel failures do not cascade globally
- adding one channel requires plugin-layer changes only
Next step: Channel reliability runbook.