Goal
Maintain two compact, source-backed capability matrices that help readers answer:
- Which integration entry points and delivery modes does AgentConnect support?
- Which ACP runtimes can AgentConnect discover and launch, and which runtime-specific controls does it integrate?
Keep these as independent axes. Do not build an integration × runtime cross-product: platform integrations route work to agents, while ACP runtimes execute the selected agent.
Matrix 1: integrations
Use short cells and link every row to its setup guide.
Recommended columns:
- Platform or entry point
- Supported conversations or events
- Ingress owner: daemon direct or Relay
- Public callback required
- Shared bot or App behavior
- Setup guide
Cover the current chat platforms, GitHub, generic webhooks, schedules, Playground, and agent API where each has verified behavior. Show Cloud versus OSS only when setup or delivery genuinely differs.
Matrix 2: ACP runtimes
Use daemon-reported capabilities as the live source of truth. The docs matrix is a stable product summary, not a hard-coded copy of dynamic model lists.
Recommended columns:
- Runtime or adapter
- Discovery and launch status
- AgentConnect-managed runtime controls
- MCP transport support
- Shared-login support
- Runtime-native tool sandbox integration
- Notes or guide
Use explicit terms such as Available, Pending, and Not integrated. Group dynamic or unverified adapters under Other ACP runtimes instead of implying support that the daemon has not reported.
Source of truth and maintenance
- Verify integration behavior against current connector, Relay, and daemon ingress code plus the corresponding platform guide.
- Verify runtime availability and controls against daemon-reported ACP capabilities and the runtime adapter implementation.
- Do not hard-code model names, model versions, or provider-specific option values that are discovered at runtime.
- Update a matrix when an integration boundary changes or AgentConnect adds/removes runtime-specific integration.
- Keep each cell scan-friendly; move caveats into prose or the linked guide.
Acceptance criteria
Goal
Maintain two compact, source-backed capability matrices that help readers answer:
Keep these as independent axes. Do not build an integration × runtime cross-product: platform integrations route work to agents, while ACP runtimes execute the selected agent.
Matrix 1: integrations
Use short cells and link every row to its setup guide.
Recommended columns:
Cover the current chat platforms, GitHub, generic webhooks, schedules, Playground, and agent API where each has verified behavior. Show Cloud versus OSS only when setup or delivery genuinely differs.
Matrix 2: ACP runtimes
Use daemon-reported capabilities as the live source of truth. The docs matrix is a stable product summary, not a hard-coded copy of dynamic model lists.
Recommended columns:
Use explicit terms such as Available, Pending, and Not integrated. Group dynamic or unverified adapters under Other ACP runtimes instead of implying support that the daemon has not reported.
Source of truth and maintenance
Acceptance criteria