Python: Channels

Tracking issue for the Python hosting protocol-helper work (formerly tracked as “channels”).

The accepted direction is helper-first: protocol packages convert protocol-native input/output into Agent Framework run values and protocol-native responses/events. App code owns the web framework routes, native SDK clients, authN/authZ, commands, delivery, deployment shape, and session/checkpoint storage policy.

The earlier host/channel registry model is no longer the v1 boundary. Issue titles that still say “channel” should be read as “protocol helper package + samples” until each slice is renamed or rewritten.

Current Sprint 5 work

• #6585 — Core state + Responses protocol helpers — PR #6891 🔍
• #6588 — Telegram protocol helpers and samples — follow-up after #6891 🔍

Merged / retained prior work

• #6584 — ADRs and implementation spec — original PR #6578; helper-first ADR update in #6837 ✅
• #6586 — Minimal Foundry Hosted Agent helper — PR #6593 ✅

Remaining protocol-helper slices

• #6587 — Invocations helpers and Foundry hosted agent sample
• #6589 — Activity Protocol helpers
• #6590 — Discord helpers
• #6591 — A2A helpers and sample
• #6592 — MCP helpers and sample

Split rules

• Each protocol slice should provide only the Agent Framework-specific seam: helpers such as <protocol>_to_run(...), <protocol>_from_run(...), <protocol>_from_streaming_run(...), <protocol>_session_id(...), and command/media helpers when useful.
• App/web-framework code owns routes, auth, native SDK clients, webhook registration, background work, deployment shape, and response delivery.
• Samples ship with the protocol helper package they use, or with the last not-yet-landed helper package when a sample spans multiple protocols.
• New non-core package tests must use tests/<unique_name>/ and must not include tests/__init__.py.
• New packages should follow the current typing setup: Pyright for source, no package-local source mypy task.
• Do not reintroduce the old host/channel registry, route aggregation, linking, multicast, cross-channel delivery, or durable delivery implementation into the v1 helper surface.
• If an older issue or PR references feature/python-hosting or the old host/channel API, reconcile it against the helper-first model before implementation.

Follow-up / proposed work

Tracked by ADR-0028 rather than v1 implementation PRs:

• Identity linking and unlink flows
• Multicast and cross-channel delivery
• Active-channel routing
• Background continuations and durable delivery
• Retry/replay and delivery observability
• Payload serialization for durable cross-channel delivery