EGP Slack Multi-Agent Bridge Architecture (v1)

Authored: 2026-06-24 · Persona: Irma + Vesta + Gemma + Hakeem Unified · Classification: EGP INTERNAL (CF Access gated · Marc-only)

This document explains how the EGP PPMO Bridge (Slack) connects to the Search Atlas Coworker, exposes Gemma and Vesta as Slack personas, and invokes the 4BT parallel-dispatch protocol from inside Slack channels.

1. Executive Summary

The EGP PPMO Bridge becomes the single Slack-native orchestrator for Marc and the EGP team. Three things plug into it.

1. Search Atlas Coworker ("Atlas") · Search Atlas's official Slack app. Already authenticated to EGP Slack. DM-capable and channel-mentionable. Can connect to GSC, GA4, Google Ads, HubSpot, WordPress, Shopify, Notion, Google Sheets.
2. Gemma and Vesta (and the wider PPMO+ persona fleet) · currently dispatched via the Claude Agent SDK from local tools. Phase 2 surfaces them as Slack personas through a socket-mode bot owned by the Bridge.
3. 4BT protocol · the parallel multi-persona dispatch primitive. Phase 3 wires Slack directives into the 4BT dispatcher so Marc can fire a fan-out from any channel.

Pattern in 60 seconds. Marc DMs the Bridge a directive. The Bridge classifies intent, decides which persona or tool answers, optionally @-mentions Atlas to pull a data point, optionally invokes 4BT to fan out across Gemma, Vesta, Hakeem, Irma, and others, and threads the consolidated answer back to Marc with status, source citations, and 4BT outage fallbacks if any persona crashes.

2. Current-State Map

2.1 Search Atlas Coworker (Atlas)

• Identity: Search Atlas's official Slack app, branded "Atlas" inside EGP Slack.
• Surface: DM the app directly or @-mention in any channel where it is invited.
• Tool connectors: GSC, GA4, Google Ads, HubSpot, WordPress, Shopify, Notion, Google Sheets, and more from the Search Atlas marketplace.
• Authorization: per-connector OAuth bound to the installing Slack workspace user. EGP has authenticated.
• Strengths: SEO and GEO data retrieval, content-brief generation, ranking and traffic context, on-page recommendations, schema suggestions.
• Constraints: Atlas runs on Search Atlas's own LLM stack and credit ledger. Long sessions burn credits. Atlas is not aware of EGP's internal canon (Trust Center, billing canon, sender canon, brand canon).

2.2 EGP PPMO Bridge (existing)

• Identity: @EGP PPMO Bridge Slack bot, visible in #egp-ppmo and elsewhere.
• Implementation: tools/egp_slack_bridge.py (Slack Web API via bot token). One-shot post and read today. Continuous daemon requires per-tx Marc-GO.
• Persona surfacing: every post tags the speaking persona inline (Vesta, Betty, Gemma, etc.) since the bot is one Slack user.
• Transit-brief pattern: Marc-AM decisions emit short briefs ending with three-letter response codes (e.g., 1B 2B 3A) so Marc can reply with a single string and the Bridge parses each digit-letter pair as a decision.
• Audit: every post and read appends to state/slack_bridge_audit.jsonl.

2.3 Gemma, Vesta, and the PPMO+ persona fleet

• Where they live today: Claude Agent SDK dispatch from the working directory. Each persona is invoked through Agent(subagent_type=...) or through deterministic tool runs under tools/.
• Where they are NOT today: Slack. Marc cannot DM Vesta from Slack. Gemma cannot reply in a Slack thread under her own visible identity.
• Canon: persona codenames must never leak into customer-facing artifacts. Inside #egp-ppmo and other internal channels they are first-class.

2.4 4BT protocol

• Spec sources: feedback_4bt_protocol_llm_outage_api_resilience_2026_06_23.md and the parent dispatch protocol.
• Primitive: parallel sub-agent dispatch with deterministic Python (Layer 1), LLM-augmented runs (Layer 2), LLM-essential runs with queue (Layer 3), Marc-side surface (Layer 4).
• Resilience: 30-second checkpoints to disk, idempotent runners, auto-respawn three times, offline queue, outage tracker.
• Today's gap: 4BT runs are kicked off from terminal or Claude Code sessions. There is no Slack-side trigger and no Slack-side outage status post.

3. Target-State Architecture

The unified Slack-side stack.

Marc (Slack DM or channel)
        |
        v
+----------------------------+
| EGP PPMO Bridge (router)   |  intent classifier · audit · 5-format hooks
+----------------------------+
   |          |          |          |
   v          v          v          v
+--------+ +--------+ +---------+ +------------------+
| Atlas  | | Gemma  | | Vesta   | | 4BT dispatcher   |
| (SA)   | | persona| | persona | | (parallel fan-out)|
+--------+ +--------+ +---------+ +------------------+
   |          |          |          |
   +----------+----+-----+----------+
                  v
        Threaded response back to Marc
        with citations, 5-format artifacts (when authored),
        and 4BT outage fallbacks if any path failed

Roles.

• Slack is the human-facing surface for Marc and the EGP team.
• The EGP PPMO Bridge is the meta-orchestrator. It owns intent classification, persona routing, transit-brief composition, outage status posts, and audit.
• Atlas is a tool-of-record for SEO and GEO surfaced through the Bridge. Bridge can call Atlas via DM relay or via @-mention in a shared channel.
• Gemma and Vesta (and other PPMO+ personas) are exposed as Slack identities via a socket-mode bot fronted by the Bridge router. Each persona has its own bot token and scoped identity, so Slack shows the right name and avatar.
• 4BT is the dispatch primitive the Bridge invokes when a directive requires parallel work across personas.

4. Specific Integration Patterns

Pattern A · Marc DMs the Bridge

1. Marc DMs @EGP PPMO Bridge a directive.
2. Bridge runs intent classification (Layer 1 deterministic rules first, then Layer 2 LLM-augmented if rules miss).
3. Bridge picks the route.
   - SEO and GEO data point: relay to Atlas, parse response, return.
   - Synthesis or writing: route to Gemma persona.
   - Execution or tool run: route to Vesta persona.
   - Multi-stream directive: fire 4BT parallel dispatch.
4. Bridge threads the consolidated answer back to Marc with citations, persona tags, and (when artifacts are produced) the canonical 5-format pipeline links (md, html, pdf, CF, Mailgun).

Pattern B · Bridge pulls Atlas data into a multi-persona thread

1. A persona (say Gemma) is composing a content brief.
2. Bridge @-mentions Atlas in a working channel with a structured ask ("Atlas: top 10 ranking pages for keyword X on enroutegrowthplatform.io").
3. Atlas posts the data back into the thread.
4. Bridge captures Atlas's reply, hands it to Gemma's synthesis run, and Gemma replies in the same thread.

Pattern C · 4BT outage triggers a Bridge status post

1. The 4BT outage handler (_egp_llm_outage_handler.py per the 4BT canon) detects an LLM 500 or API failure.
2. The handler signals the Bridge outage status poster.
3. Bridge posts a status message to #egp-ppmo summarizing the outage, the affected sub-agents, the queue depth, and the expected resume time.
4. When the outage clears, the Bridge posts a resume notice and links to the digest of work completed after recovery.

Pattern D · Atlas finding triggers Gemma synthesis and Vesta dispatch

1. Atlas surfaces a finding (e.g., new ranking dropped 10 positions on a target keyword).
2. Bridge captures the event (via scheduled poll or by parsing Atlas posts in monitored channels).
3. Bridge invokes 4BT with a two-lane dispatch.
   - Gemma: synthesize the issue, draft a content remediation brief.
   - Vesta: execute the tool runs to update llms.txt, schema, and citability scores; queue a re-crawl.
4. Bridge threads both outputs back to Marc with a single brief and a 1A 2B response prompt.

5. Implementation Plan (phased)

Phase 1 · Bridge to Atlas relay (week 1)

• Extend tools/egp_slack_bridge.py to support DM relay to the Atlas app user.
• Build tools/slack/_egp_atlas_relay.py that wraps conversations.open + chat.postMessage + conversations.history polling.
• Define a structured ask grammar so Bridge requests are machine-parseable.
• Add audit lines for every Atlas exchange.

Phase 2 · Gemma and Vesta as Slack personas (week 2)

• Provision two Slack apps inside the EGP workspace: EGP-Gemma and EGP-Vesta. Each has a dedicated bot token, scoped icon, and display name.
• Build tools/slack/_egp_gemma_vesta_slack_personas.py running in socket mode (Slack Socket Mode app token for each persona).
• Route inbound DMs and @-mentions through the Bridge router so the persona surface remains consistent with internal canon (no internal references leaking, 5-format pipeline triggers respected, em-dash lint enforced).

Phase 3 · 4BT protocol invocation from Slack (week 3)

• Build tools/slack/_egp_4bt_slack_dispatcher.py that accepts a directive from Slack, packages it as a 4BT dispatch payload, fires the parallel fan-out, and streams lane status back into the originating thread.
• Wire checkpoint events so lane progress posts back to the thread every 30 seconds.
• Honor the autonomous-no-reask canon: the dispatcher proceeds without confirmation on safe-reversible directives and queues unsafe ones to the AM question queue.

Phase 4 · Cross-persona handoff via the Bridge (week 4)

• Add handoff primitives so Gemma can hand a draft to Vesta for execution, Vesta can hand a finding to Atlas for data enrichment, and Atlas results can flow back into Gemma's working thread.
• Build tools/slack/_egp_ppmo_bridge_router.py as the canonical router that owns intent classification, persona selection, handoff state, and 5-format artifact emission triggers.

6. Auth and Identity Model

• Slack Bot tokens: one per app (Bridge, Gemma, Vesta, future Hakeem, Irma, Betty). Stored in .env under SLACK_BOT_TOKEN, SLACK_BOT_TOKEN_GEMMA, SLACK_BOT_TOKEN_VESTA, etc.
• Slack App tokens (socket mode): one per persona running socket mode. SLACK_APP_TOKEN_GEMMA, SLACK_APP_TOKEN_VESTA.
• Scopes (minimum per persona): chat:write, chat:write.customize, channels:history, groups:history, im:history, im:write, users:read, app_mentions:read.
• Atlas: Atlas is a tenant of the EGP workspace owned by Search Atlas. EGP grants Atlas the connectors it needs (GSC, GA4, etc.) via per-connector OAuth bound to a designated EGP service identity, never Marc's personal identity.
• Channel access controls: every persona is invited only to channels it needs. #egp-ppmo is the canonical operations channel. Customer-facing channels (if any) keep PPMO+ personas out per the no-internal-references canon.
• Audit: every persona write appends to state/slack_bridge_audit.jsonl with persona, channel, ts, intent, payload_hash, and (if applicable) 4bt_dispatch_id.

7. Failure Modes and 4BT Resilience

• Atlas API down or rate-limited. Bridge marks the lane degraded, posts a status note in the originating thread, queues the ask for retry, and returns the best partial answer from cache or Gemma.
• Slack socket disconnect. Each persona socket has a watchdog that reconnects within 5 seconds. Three failures escalates to launchd respawn.
• Gemma or Vesta dispatch crashes. 4BT auto-respawn (three times) per the parent canon. After three failures, the Bridge posts an outage status to #egp-ppmo and writes a P1 to the Marc question queue.
• Slack bot token expiry. SLACK_REFRESH_TOKEN rotation runs daily via egp_slack_token_auto_refresh.py. On 401 the Bridge triggers a forced refresh before failing the call.
• 4BT outage. The Bridge outage poster surfaces the status; the offline queue drainer replays work when LLM is back. No work is dropped.
• LLM 500 storm. Layer 1 deterministic routes still answer simple intents (status, lookup, audit). The user sees a degraded-mode badge in the Bridge reply.

8. Tooling Owed (BUILD list)

Build sequence mirrors the phased plan: Phase 1 ships _egp_atlas_relay.py, Phase 2 ships personas, Phase 3 ships dispatcher and outage poster, Phase 4 ships the router and handoff state machine.

9. Risk Register

10. Recommendation

• Approve Phase 1 immediately. The Bridge to Atlas relay is low risk and unlocks Atlas as a programmable tool for Marc.
• Approve Phase 2 (Gemma and Vesta as Slack personas) once Phase 1 audit shows no spam or rate-limit issues.
• Schedule Phase 3 (4BT Slack dispatcher) for the week after Phase 2 ships clean.
• Phase 4 follows once handoff patterns are observed in real traffic.
• Cutover date proposal: Phase 1 by 2026-07-01. Phase 2 by 2026-07-08. Phase 3 by 2026-07-15. Phase 4 by 2026-07-22.
• Go and no-go gates: each phase requires zero P0 incidents in the prior phase, full audit coverage, and Marc sign-off before the next phase ships.
• Canon to commit: Slack is the primary human surface for EGP PPMO+ operations going forward. All persona work that touches Marc routes through the Bridge unless an explicit out-of-band channel is approved.

Document end. Internal only. CF Access gated. Marc-only.