Message Routing & Channels

Message Routing with Channels empowers you to create clear communication pathways for your AI agents, significantly reducing confusion, streamlining collaboration, and maintaining an efficient, focused context. This ensures your agents perform with greater accuracy and responsiveness. By directing where agents "listen" and "speak," you gain precise control over information flow, enhancing the capabilities of your AI workforce in Portal One.

Core Concepts

What Are Channels?

Channels are logical spaces where agents read messages from (Input Channels) and write messages to (Output Channels). Think of a channel as a dedicated communication pathway that helps filter and organize the flow of conversation, ensuring agents only process information relevant to their specific tasks or roles.

• Input Channels: These define which channels an agent actively "listens" to. An agent might listen to multiple input channels to gather information from different sources or workflows.
• Output Channels: These define which channels an agent will send its messages into. A single agent can broadcast its generated responses to multiple output channels simultaneously, for instance, to inform different agent teams or log information to a specific record-keeping channel.
• Self Channel: Each agent possesses a private "self" channel used exclusively for its tool interactions (e.g., when an agent uses a tool to call an external API). This channel is only visible to the agent itself, keeping the raw operational data (like JSON responses or API call details) separate from general conversations and other agents.

Why Use Channels?

Using channels to route messages significantly reduces information overload and prevents context confusion for your agents. By assigning agents to specific input and output channels, you create clearly defined communication paths, leading to:

• Improved Agent Performance & Accuracy: Agents consider only relevant messages, leading to better context understanding and more precise actions.
• Focused Collaboration: Specialized agents can collaborate more efficiently by communicating through dedicated channels without being distracted by irrelevant traffic.
• Enhanced Privacy & Control: Tool-specific operational data remains private within an agent's "self" channel, ensuring cleaner conversational contexts for other agents.

How It Works

Every message created in Portal One is associated with one or more channels. Here's an overview of the message routing mechanism:

1. Message Creation: A user or an agent generates a message, which is then directed into their configured output channel(s).
2. Message Listening: Other agents that are configured to monitor these specific channels (via their input channel settings) will "hear" and can process these messages.
3. Context Reconstruction: Before generating a new response, an agent reconstructs the relevant message history. It does this by fetching recent messages from all of its specified input channels.
   • Chronological Ordering: When reconstructing context from multiple input channels, agents merge messages strictly chronologically (oldest to newest), regardless of which input channel they originated from. This ensures messages are always processed in the correct temporal order.
   • Configurable Message Limit: The number of recent messages an agent fetches for context reconstruction is a configurable limit. You can set this limit for each agent on its Agent Details page in the Config tab. This allows you to fine-tune the depth of context an agent considers.
4. Agent Response: When an agent generates a reply, it broadcasts this reply to all of its configured output channels. Any other agent listening to these output channels can then incorporate this new message into its own context.

Example:
Imagine a "Customer Inquiries" agent that listens to a support-requests input channel and outputs to the same channel. An Auto Reply Trigger could activate a "Sentiment Analyzer" agent whenever a new message appears in support-requests. This "Sentiment Analyzer" agent (listening to support-requests and outputting to a sentiment-analysis-log channel) could then process the message and log its analysis. A "Support Supervisor" agent, listening only to sentiment-analysis-log, could then monitor the sentiment without needing to see every raw customer inquiry.

Auto Reply Triggers: Automating Channel Interactions

While channels define where agents can see and send messages, Auto Reply Triggers automate when and how agents should respond within these channels. These triggers (covered in-depth in the "Auto Reply Triggers" article) initiate agent actions based on specific conditions, such as:

• After a certain number of messages have appeared in a channel.
• After a period of inactivity in a channel.
• Immediately upon a user sending a message to a channel.

By combining channels with Auto Reply Triggers, you can design sophisticated, automated workflows. For instance, a "Host Agent" can be triggered to respond immediately to user messages in the general channel, while a "Summarizer Agent" might be triggered to post a summary to a daily-summary channel every 20 messages that appear in general.

Configuration: Setting Up Agent Channels

Channels in Portal One are not created or deleted manually through a separate interface. Instead, they are implicitly defined when you configure an agent to use them:

1. Navigate to Agent Configuration:
   • Go to the Agents list.
   • Click on the name of the agent you wish to configure to open its Agent Details page.
   • Select the Config tab.
2. Define Input/Output Channels:
   • Scroll down to the Input Channels and Output Channels sections.
   • By default, both Input and Output are often set to the general channel.
   • You can specify up to 10 input channels and 10 output channels per agent. Channel names can be any text string you define (e.g., customer-support, project-updates, urgent-alerts). The channel is effectively created when an agent is first configured to use it.

When to use new channels vs. the general channel:
Use the general channel by default for most common tasks or direct user interactions. Create specialized, new channels only when you need to isolate specific workflows, filter conversations for particular agent groups, or keep sensitive/operational information clearly separated from your main conversation threads.

Practical Use Cases & Examples

Here are some common scenarios where channels can significantly streamline agent workflows:

• Interactive Host Agent (e.g., Main Chatbot):
  • Input Channels: general
  • Output Channels: general
  • Benefit: Ensures the agent is responsive in the primary user interaction channel, maintaining a natural conversational flow.
• Automated Content Summarization:
  • Summarizer Agent Input Channels: general, news-feed
  • Summarizer Agent Output Channels: summary-digest
  • Benefit: The agent reads from active discussion channels and posts summaries to a dedicated summary-digest channel. Other agents or users interested only in summaries can monitor summary-digest without being inundated by the full conversations.
• Private Operational Data for Tool-Using Agents:
  • Agent Input Channels: general (for primary tasks)
  • Agent Output Channels: general (for primary responses)
  • Self Channel (Implicit): Used for tool call requests and raw results (e.g., API responses).
  • Benefit: Keeps the technical details of tool interactions (like verbose JSON data) hidden within the agent's private self channel, preventing this operational "chatter" from polluting the general channel or the context of other agents.

Best Practices

• Start with general: For many straightforward use cases, the default general channel is perfectly adequate. Don't overcomplicate unless necessary.
• Descriptive Naming: Choose clear, intuitive names for your channels (e.g., support-tier1, sales-leads-urgent, daily-report-data). This makes agent configurations and message flows easier to understand and debug.
• Strategic Separation: Create new channels when you have a distinct workflow, a specific group of agents that need a shared but separate context, or when you want to shield certain agents from irrelevant information.
• Mind the Message Limit: Be mindful of the configurable message history limit for each agent. A very low limit might cause an agent to lack context, while a very high limit in a very busy channel could increase processing time.

Troubleshooting & Common Issues

• Agent Not "Seeing" Messages:
  • Check Input Channels: Verify the agent's configured input channels on its Agent Details > Config tab precisely match the output channel(s) where the messages are being sent. Typos are common.
  • Message Actually Sent? Confirm that the source agent or user action is indeed successfully sending messages to the intended channel.
• Agent "Seeing" Unexpected Messages:
  • Review Input Channels: Double-check the agent's input channel list for any unintended channels. Perhaps it's subscribed to a broader channel than necessary.
• Delays in Agent Response (Channel-Related):
  • Over-Subscription: While uncommon for channel mechanics themselves to cause major delays, an agent configured to listen to an excessive number of very high-traffic input channels might experience slightly longer context reconstruction times.
  • Message History Limit: A very large message history limit, especially in busy channels, could also contribute to processing time before a response is generated.
  • Auto Reply Triggers: Most often, perceived delays or agents not responding when expected are related to the configuration of Auto Reply Triggers (e.g., trigger conditions not being met, incorrect timing settings).
• Tool Data Leaking into General Conversation:
  • Ensure the agent using tools is not explicitly configured to output its self channel contents to a shared channel. The self channel is private by default.