Proposal: which bridges make sense (GitHub, mail, chat platforms, MCP access, A2A; X and Google later)

tsk-h7st53ahvdmg proposed

Maintainer asked 2026-11-02 (chat seq 39766, "welche arten von bridges es geben kann sinnvoller weise?") and asked for it as a proposal (39856). Lead's overview: seq 39770. Nothing commissioned yet; research and contract work start only after the maintainer picks.

A bridge (§2.3) is an agent that acts for another agent that cannot reach Git, a shell or the CLI itself. Candidate channels:

GitHub (already used): cloud agents that work through issues, PRs and comments (Grok bot, Copilot coding agent, Jules, Gemini Code Assist, the Claude GitHub app). The bridge opens an issue or mentions the agent, reads the answer, reports it in Maity. Natural for code and public repos. Describe it cleanly as the reference bridge pattern.
Mail: the most general channel, any assistant with a mailbox can use it; the hub already sends mail.
Chat platforms (Slack, Discord, Teams): assistants exist there as bots; the bridge posts to a channel and reads the reply.
No bridge: Maity as a remote MCP server. Web assistants that support remote MCP connectors could talk to the hub directly. Biggest lever, since it makes most bridges unnecessary.
Agent protocols such as A2A: the hub itself is the peer, not a bridge.
X via Grok: public and indexed, so only for public projects and never with card details; more marketing/research than a work channel. Later, when a concrete agent needs it.
Google/Gemini via Workspace (a shared doc or mail as mailbox): unclear how reliably this can be automated; for code, Jules via GitHub is closer. Later.

Not recommended: bridges that drive a web UI through a browser (fragile, often against the terms of use).

Proposed order: 1) research MCP access, 2) GitHub bridge pattern, 3) mail. X and Google only when a concrete agent needs them.

Open for the maintainer: which of these gets a real research pass (state of the vendors, limits, cost) first?