Optional messaging bridges for Teams, Slack and Discord #13

New issue

Open

opened 2026-10-26 08:44:14 +00:00 by rosa · 0 comments

rosa commented

2026-10-26 08:44:14 +00:00

Member

Motivation

Companies using TreeGent may already communicate through Microsoft Teams, Slack or Discord. Optional integrations would let humans interact with persistent TreeGent agents from those platforms without adopting another chat interface for everyday work.

TreeGent’s own chat backend would remain authoritative, and its web interface would remain available for administration, approvals, shared resources and history.

Proposal

Introduce a bidirectional messaging adapter layer:

Microsoft Teams ──┐
Slack ────────────┼── Platform adapters ── TreeGent chat ── Agents
Discord ──────────┘

Adapters would translate incoming platform messages into TreeGent messages and deliver outgoing messages to the appropriate external conversations.

This would preserve TreeGent’s existing runtime model:

One continuous session per agent.
Inbox delivery at the next available turn.
Internal agent-to-agent communication.
Authorization through TreeGent’s actor and permission model.

Suggested capabilities

Provide a common integration contract, with platform-specific implementations for Teams, Slack and Discord:

Map external users to authorized TreeGent human actors.
Route DMs, mentions and configured channels to the intended agents.
Deliver replies to the originating conversation, preserving thread context where supported.
Allow agent-initiated messages where the platform’s permissions and installation requirements permit them.
Support attachments and formatting where practical.
Configure which conversations are bridged rather than mirroring everything.

Where supported, integrations could expose agents as separate bot identities. A shared bot that routes messages to named agents would be an alternative. The integration contract should accommodate both without assuming every platform offers identical identity capabilities.

Security and delivery

Authenticate incoming platform events.
Enforce actor mappings and conversation permissions.
Prevent agents from impersonating other agents or messaging unauthorized recipients.
Deduplicate incoming events and prevent forwarding loops.
Retry transient delivery failures and expose permanent failures.
Keep platform credentials outside agent-accessible context.

Scope and trade-offs

The proposal is for optional messaging interoperability, not replacing TreeGent’s chat service or reproducing every external platform feature.

Teams, Slack and Discord have different app registration, installation, permission and bot identity models. Adapters should document those differences while presenting consistent messaging behavior to TreeGent.

A text-only integration could establish the shared contract first, with richer content and additional adapters added incrementally.

Questions for maintainers

Would optional external messaging adapters fit TreeGent’s direction?
What extension point would you prefer for inbound messages and outbound delivery?
Should adapters live in this repository or be independently deployable integrations?

Migrated from the dead GitHub tracker per Felix's request 2026-10-26 — this issue was filed there by fmorgens on 2026-10-05 and never carried over (the migration imported git history only: 0 issues). Original text verbatim below. --- ## Motivation Companies using TreeGent may already communicate through Microsoft Teams, Slack or Discord. Optional integrations would let humans interact with persistent TreeGent agents from those platforms without adopting another chat interface for everyday work. TreeGent’s own chat backend would remain authoritative, and its web interface would remain available for administration, approvals, shared resources and history. ## Proposal Introduce a bidirectional messaging adapter layer: Microsoft Teams ──┐ Slack ────────────┼── Platform adapters ── TreeGent chat ── Agents Discord ──────────┘ Adapters would translate incoming platform messages into TreeGent messages and deliver outgoing messages to the appropriate external conversations. This would preserve TreeGent’s existing runtime model: - One continuous session per agent. - Inbox delivery at the next available turn. - Internal agent-to-agent communication. - Authorization through TreeGent’s actor and permission model. ## Suggested capabilities Provide a common integration contract, with platform-specific implementations for **Teams, Slack and Discord**: - Map external users to authorized TreeGent human actors. - Route DMs, mentions and configured channels to the intended agents. - Deliver replies to the originating conversation, preserving thread context where supported. - Allow agent-initiated messages where the platform’s permissions and installation requirements permit them. - Support attachments and formatting where practical. - Configure which conversations are bridged rather than mirroring everything. Where supported, integrations could expose agents as separate bot identities. A shared bot that routes messages to named agents would be an alternative. The integration contract should accommodate both without assuming every platform offers identical identity capabilities. ## Security and delivery - Authenticate incoming platform events. - Enforce actor mappings and conversation permissions. - Prevent agents from impersonating other agents or messaging unauthorized recipients. - Deduplicate incoming events and prevent forwarding loops. - Retry transient delivery failures and expose permanent failures. - Keep platform credentials outside agent-accessible context. ## Scope and trade-offs The proposal is for **optional messaging interoperability**, not replacing TreeGent’s chat service or reproducing every external platform feature. Teams, Slack and Discord have different app registration, installation, permission and bot identity models. Adapters should document those differences while presenting consistent messaging behavior to TreeGent. A text-only integration could establish the shared contract first, with richer content and additional adapters added incrementally. ## Questions for maintainers - Would optional external messaging adapters fit TreeGent’s direction? - What extension point would you prefer for inbound messages and outbound delivery? - Should adapters live in this repository or be independently deployable integrations?