[Discussion] App Channel & CLI Integration in AgentScope 2.0 — Do We Need Native Support?

[DavdGao]

Background

The emergence of projects like OpenClaw has highlighted a growing demand for agents that can run persistently and connect across different applications. This raises an important question for AgentScope 2.0: should we provide native support for app channel and CLI integration?

We'd love to hear your thoughts before committing to any direction.

Current State

AgentScope 2.0's agent service currently does not provide built-in support for connecting to external applications such as Discord, Lark (Feishu), DingTalk, WeChat Work, Reddit, etc.

Two Directions We Are Considering

Direction 1: Agent → App (Agent as the initiator)

This covers the scenario where an agent actively uses or interacts with external apps and CLI tools.

One natural approach is to expose these integrations as tools. However, we're not sure this adds much value over:

• Providing a generic Bash tool or custom skill
• Leveraging existing App MCP servers (e.g., a Lark MCP or Discord MCP)

For well-supported platforms like Discord, Lark, DingTalk, and WeChat Work, connecting via their respective MCP servers may already be sufficient — without requiring us to build and maintain dedicated SDK-level integrations.

Open question: Is there a compelling reason to go beyond MCP here?

Direction 2: App → Agent (App as the initiator)

This is the reverse direction — where a message from an app (e.g., a user mentioning a bot in Discord or Lark) triggers an agent, or where an app acts as a routing layer dispatching messages to the right agent.

This goes beyond what MCP covers today. It requires building an active inbound channel from the app to the agent service — similar to the "channel gateway" pattern seen in OpenClaw.

The challenge here is that AgentScope 2.0's agent service is designed as a multi-tenant, multi-session service. So the key questions become:

• How should inbound app channels integrate with the agent service?
• What does the end-to-end user experience look like?
• Should this be a first-class feature or left to users to implement?

Share Your Thoughts 👇

• Do you have use cases that require native app channel support?
• Which direction (Agent→App or App→Agent) is more relevant to your needs?
• Would MCP-based integration be sufficient for your use case, or do you need deeper native support?

We're in the early stages of evaluating this and your feedback will directly shape our roadmap.

[ttaid]

Do you have use cases that require native app channel support?

Yes, especially for long-running enterprise agents and production-grade multi-agent systems.

In our experience, the demand is not primarily about agents calling external applications (Discord, DingTalk, Feishu, WeCom, WeChat, etc.), but rather about external applications becoming the entry point and event source of the agent system.

Typical examples include:

• A user mentioning an agent in DingTalk, Feishu, Discord, or WeChat, which automatically triggers a workflow.
• Messages from different channels being routed to different agents based on organizational context.
• Persistent agents that continuously monitor conversations and respond asynchronously.
• Multi-user collaborative scenarios where conversations from different channels are mapped into isolated agent sessions.
• Enterprise workflows where notifications, approvals, monitoring alerts, and operational events become agent inputs.

These scenarios require app channels to function as first-class inbound communication layers rather than simple tool integrations. MCP alone does not fully address this interaction pattern.

---

Which direction (Agent→App or App→Agent) is more relevant to your needs?

App → Agent is significantly more important for us.

For Agent → App:

• Current AgentScope capabilities are already sufficient.
• Generic Bash tools, custom skills, HTTP tools, and MCP servers can already cover most requirements.
• Any additional integrations tend to be highly application-specific and can be implemented by users themselves.
• The integration depth with AgentScope is relatively shallow.

In contrast, App → Agent requires much deeper integration with the runtime architecture:

• Session management
• Tenant isolation
• User identity mapping
• Event routing
• Agent lifecycle management
• Long-running memory and context persistence
• Multi-agent dispatching

These capabilities are difficult to implement consistently outside the framework and are closely related to AgentScope Runtime itself.

Therefore, if engineering resources are limited, I would strongly prioritize App → Agent over Agent → App.

---

Would MCP-based integration be sufficient for your use case, or do you need deeper native support?

For Agent → App, MCP is generally sufficient.

For App → Agent, deeper native support is needed.

The reason is that MCP primarily standardizes tool invocation and service access. It is excellent for:

• Calling external systems
• Accessing APIs
• Operating applications
• Tool interoperability

However, App → Agent introduces a different problem space:

• Event ingestion
• Message routing
• Session creation and recovery
• User-agent binding
• Multi-tenant isolation
• Channel abstraction
• Asynchronous communication
• Persistent agent execution

These are runtime-level concerns rather than tool-level concerns.

A useful analogy is:

• MCP is similar to an agent's "hands" (how the agent acts on external systems).
• App Channels are more like an agent's "ears" and communication network (how the agent receives and routes information).

The latter is foundational infrastructure and is difficult to build consistently on top of MCP alone.

---

Additional Suggestion

Instead of implementing individual native integrations for every platform (Discord, Feishu, DingTalk, WeCom, WeChat, Reddit, etc.), AgentScope could introduce a generic Channel Gateway abstraction.

For example:

Channel
├── Discord Channel
├── Feishu Channel
├── DingTalk Channel
├── WeCom Channel
├── WeChat Channel
├── Reddit Channel
├── Email Channel
└── Custom Channel

Each channel would produce a unified event format:

Channel Event
├── tenant_id
├── user_id
├── channel_id
├── session_id
├── message
└── metadata

The AgentScope Runtime would then be responsible for:

Channel Event
↓
Channel Gateway
↓
Session Router
↓
Agent Service
↓
Agent Instance

This approach aligns naturally with AgentScope's multi-tenant and multi-session architecture. It also avoids building platform-specific logic directly into the runtime while still providing a first-class inbound communication layer.

More importantly, it enables AgentScope to support future channels with minimal changes to the core architecture. New channels only need to implement the gateway interface and event schema, while the downstream routing, session management, memory, and agent execution logic remain unchanged.

From an architectural perspective, App → Agent is not simply another integration. It is part of the agent runtime infrastructure.

Agent → App is fundamentally a tool invocation problem and can be addressed through MCP, HTTP tools, custom skills, or user-defined integrations.

App → Agent, however, is a runtime orchestration problem involving event ingestion, session lifecycle management, tenant isolation, identity mapping, routing, and persistent execution. These capabilities are difficult for users to implement consistently outside the framework and therefore provide much higher value as a native AgentScope feature.

In summary, I believe native support should focus on App → Agent, because that is where framework-level infrastructure provides the most value, while Agent → App can largely remain MCP- and tool-based.