5K

Multi-Platform Communication Aggregation

Queries every communication platform in parallel through adapters that share one schema, then merges, deduplicates, and ranks the results

emerging Updated 2026-10-13 By Lucas Carlson Based on Lucas Carlson (practitioner-contributed skill setup)
View .md Edit on GitHub
Add to Pack
or

Saved locally in this browser for now.

Cite This Pattern
APA 
Lucas Carlson (2026). Multi-Platform Communication Aggregation. In *Awesome Agentic Patterns*. Retrieved October 14, 2026, from https://agentic-patterns.com/patterns/multi-platform-communication-aggregation
BibTeX 
@misc{agentic_patterns_multi-platform-communication-aggregation,
  title = {Multi-Platform Communication Aggregation},
  author = {Lucas Carlson},
  year = {2026},
  howpublished = {\url{https://agentic-patterns.com/patterns/multi-platform-communication-aggregation}},
  note = {Awesome Agentic Patterns}
}

Use when

  • Users search for messages without knowing which platform holds them
  • Each platform has a CLI or API with search support
  • Cross-platform audit or compliance searches

Avoid when

  • All communication is on one platform
  • Privacy rules do not allow aggregating data across platforms

Problem

Users communicate across multiple platforms (email, Slack, iMessage, etc.) and need to search for information that might exist in any of them. Searching each platform manually is slow and error-prone. An agent tasked with "find what X said about Y" must know which platform to check—or check all of them.

Solution

Create a unified search interface that queries all communication platforms in parallel and aggregates results into a single, consistent format. Also known academically as Federated Search or Mediator-Based Integration.

graph TD A["User Query: find messages about project deadline"] --> B[Aggregator Agent] B --> C[iMessage Search] B --> D[Slack Search] B --> E[Email Search] B --> F[Other Platforms...] C --> G[Result Collector] D --> G E --> G F --> G G --> H[Unified Results Table]

Key components:

  1. Platform Adapters: Each platform has a CLI/API wrapper with consistent interface
  2. Parallel Dispatcher: Spawns searches concurrently (sub-agent pattern or background jobs)
  3. Result Normalizer: Converts platform-specific formats to unified schema
  4. Aggregator: Combines, deduplicates, and ranks results
# Example: Unified search skill implementation
search_all() {
    query="$1"

    # Spawn parallel searches
    messages search "$query" > /tmp/messages.json &
    slack-messages search "$query" > /tmp/slack.json &
    fastmail.sh search "$query" > /tmp/fastmail.json &
    gmail.sh search "$query" > /tmp/gmail.json &

    wait  # All complete

    # Aggregate and normalize
    aggregate_results /tmp/*.json
}

Architectural variants:

  • Adapter Pattern: Platform abstraction layer with unified API (single codebase, easy platform addition)
  • Gateway/Bridge Pattern: Bidirectional message synchronization between platforms
  • Unified Inbox Pattern: Customer-centric aggregation for support/engagement workflows
  • Event-Driven Architecture: Async message brokering for scalability

How to use it

When to apply:

  • User asks "where did someone mention X"
  • User needs to find a conversation but doesn't remember the platform
  • Cross-platform audit or compliance searches
  • Building unified inbox or communication hub features

Implementation steps:

  1. Create CLI wrappers for each platform with consistent output format (JSON)
  2. Define a common schema: {platform, sender, timestamp, content, url}
  3. Build parallel dispatch mechanism (bash background jobs, sub-agents, or async)
  4. Implement result ranking (by recency, relevance, or platform priority)
  5. Present in unified table format with platform badges

Skill definition example:

## Unified Communication Search

**Proactive triggers:** "search everywhere", "find across all", "where did someone say"

Searches in parallel:

- Apple Messages
- Slack
- Fastmail
- Gmail

Results presented in unified table, grouped by platform.

Trade-offs

Pros:

  • Single query searches all platforms—no context switching
  • Parallel execution minimizes latency (total time ≈ slowest platform)
  • Unified format makes comparison and filtering easy
  • Extensible: add new platforms without changing interface
  • Reduces "which platform was that on?" friction

Cons:

  • Requires maintaining adapters for each platform
  • Rate limits may apply across platforms simultaneously
  • Result ranking across platforms is subjective (is a Slack message more relevant than an email?)
  • Privacy/security: aggregating data across platforms increases exposure
  • Some platforms have poor search APIs (result quality varies)

References

  • Sub-Agent Spawning pattern for parallel execution
  • LLM Map-Reduce pattern for result aggregation
  • Academic: Shokouhi, M. (2013). Federated Search. Foundations and Trends in Information Retrieval 6(4-5) - the standard survey of federated search; the earlier "Callan (2020)" citation in this file could not be found in any index and has been removed
  • Practitioner-contributed: the aggregation design and the /search-all skill example come from the author's personal Claude Code skill setup; Anthropic documents no such built-in skill, and the source repository below is the CLI the skill runs in, not a description of this pattern