[FEATURE] Slackbot integration

[marcinkubica]

📋 Prerequisites

• I have searched the existing issues to avoid creating a duplicate
• By submitting this issue, you agree to follow our Code of Conduct

📝 Feature Summary

No response

❓ Problem Statement / Motivation

As a Platform Engineer I need teams in my company (ie development, operation, support) to prompt-query @slack-bot to my kagent platform.

This opens wide area of possibilities, primarily augmenting rapid root cause analysis for a product which runs on my platform along with entirety of the context I will provide - ie. MCPs I use (Datadog), propose code changes for developers (Github MCP)

💡 Proposed Solution

• As discussed during community meetup approach should consider future chat-platforms like Teams so we don't couple tightly
• Slack MCP sounds like a way forward as the intermediary
• Have solution to be officially supported by kagent
• Start slow: let the text communication work but also consider Slack can send voice messages

🔄 Alternatives Considered

No response

🎯 Affected Service(s)

Not Sure

📚 Additional Context

No response

🙋 Are you willing to contribute?

• I am willing to submit a PR for this feature

[christian-posta]

This works out great for me, would love to hear your feedback on it? Or have suggestions to improve the experience?

https://kagent.dev/docs/examples/slack-a2a

[marcinkubica]

@christian-posta very nice POC!

I'd lilke to turn it into more prod grade ux, if that's fine wih you.

[peterj]

We could think about creating an "official" kagent Slack app (and/or Teams/Discord apps) -- basically something that would give users access to agents running in the cluster. @marcinkubica would you be interested in working on this?

[marcinkubica]

@peterj yes, happy to look into Slack to kick it off

[marcinkubica]

A "tiny" problem here - MCP server has been archived =)

[marcinkubica]

adding consideration Agents and AI apps

...
imho - this part should be left to user decision or if enabled clearly documented - ie. not everyone's might want to allow chat with bot via DMs - it also involves bot's code to support certain events.

https://api.slack.com/docs/apps/ai#get-started

[marcinkubica]

adding consideration for listing on Slack Marketplace

Details

gemini

Navigating the Slack App Marketplace: No Commercial Mandate and No Listing Fees
For developers eyeing the Slack App Marketplace as a distribution platform, the good news is that your application does not need to be a commercial product to be listed. Slack welcomes a diverse range of applications, including free and open-source tools, as long as they meet the platform's quality and user experience standards.

While it is recommended that apps intended for wide commercial distribution go through the Marketplace, there is no requirement for an app to have a price tag. The primary focus of Slack's review process is to ensure that any application offered to its users is of high quality, secure, and provides a valuable function. This opens the door for a variety of apps, from those with subscription-based pricing models to completely free tools that enhance a team's productivity or workflow within Slack.

Key Submission Requirements Focus on Quality, Not Commerce

Instead of commercial viability, Slack's submission guidelines emphasize:

A high-quality user experience: The app should be well-designed, intuitive, and free of bugs.
Compliance with Slack's policies: This includes their API terms of service, developer policy, and brand guidelines.
Security: The app must be secure and protect user data.
Clear purpose and value: The app's listing should clearly articulate what it does and the problem it solves for users.
No Financial Barrier to Entry for Developers

A significant advantage for developers is that there are no direct costs or fees associated with listing an app in the Slack App Marketplace. Slack does not charge developers to have their applications reviewed or published on the platform.

The costs that are often discussed in relation to Slack are tied to their user-facing subscription plans (such as Pro and Business+). These plans offer users benefits like an increased number of app integrations they can install in their workspace. However, this is a cost for the user or organization using Slack, not a fee levied on the developer for making their app available.

Developers do, of course, bear the costs of developing and maintaining their applications, including any hosting or server expenses. Furthermore, if a developer chooses to offer a paid version of their app, they are responsible for setting up their own payment and subscription systems. Slack itself does not currently offer a built-in monetization feature for Marketplace apps.

In conclusion, the Slack App Marketplace provides a cost-effective and accessible platform for developers to reach a large user base, regardless of whether their application is a commercial venture or a free tool. The emphasis is squarely on the quality and utility of the app, not its business model.

[marcinkubica]

Slowly moving on to have hosted mvp on my GKE + GatewayAPI (as I don't use kagent yet)

adding consideration for a2a vs langchain implementation

Details

LangChain vs A2A Protocol: Slack Bot Architecture Decision

Last Updated: June 9, 2025

Executive Summary

When building Slack bots for the kagent ecosystem, A2A Protocol is the recommended approach over LangChain due to better performance and native integration

🤔 The Question

Should we use LangChain or A2A Protocol when building Slack bots that integrate with kagent agents?

📊 Comparison Matrix

Factor	A2A Protocol	LangChain	Winner
Performance	⭐⭐⭐⭐⭐	⭐⭐⭐	A2A
kagent Integration	⭐⭐⭐⭐⭐	⭐⭐	A2A
Ecosystem	⭐⭐⭐	⭐⭐⭐⭐⭐	LangChain
Production Stability	⭐⭐⭐⭐⭐	⭐⭐⭐	A2A
Development Speed	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	LangChain
Maintenance	⭐⭐⭐⭐⭐	⭐⭐	A2A
Security Integration	⭐⭐⭐⭐⭐	⭐⭐	A2A

🚀 A2A Protocol (Recommended)

✅ Advantages

Native kagent Integration

• Purpose-built for kagent's architecture
• Direct JSON-RPC communication with agents
• Full type safety with Pydantic models

Performance & Reliability

• Lightweight dependencies (aiohttp, httpx, pydantic)
• No abstraction overhead
• Built-in streaming support via Server-Sent Events

❌ Disadvantages

• kagent-specific (not portable to other LLM providers)
• Smaller ecosystem compared to LangChain
• Learning curve for A2A protocol specifics

Code Example

from a2a.client import A2AClient

async def invoke_kagent(query: str) -> str:
    """Simple A2A invocation"""
    client = A2AClient(url=os.getenv("KAGENT_A2A_URL"))
    response = await client.send_task({
        "id": str(uuid.uuid4()),
        "sessionId": str(uuid.uuid4()),
        "message": {
            "role": "user", 
            "parts": [{"type": "text", "text": query}]
        }
    })
    
    # Extract response from artifacts
    text = ""
    for artifact in response.result.artifacts:
        for part in artifact.parts:
            text += part.text
    return text

🔗 LangChain Approach

✅ Advantages

Rich Ecosystem

• Extensive integrations (OpenAI, Anthropic, vector databases)
• Large community with tutorials and examples
• Pre-built chains and agents

Development Velocity

• Rapid prototyping capabilities
• Easy LLM provider switching
• Built-in memory and retrieval systems

Flexibility

• Multi-provider support
• Extensive tooling ecosystem
• Rich agent frameworks

❌ Disadvantages

Production Challenges

• Heavy dependency tree (slower cold starts)
• Frequent breaking changes between versions
• Known memory leaks in long-running applications
• Complex for production deployments

Integration Issues

• Multiple abstraction layers

Code Example

from langchain.agents import initialize_agent
from langchain.llms import OpenAI

# Would require additional kagent integration
llm = OpenAI(temperature=0)
agent = initialize_agent(tools, llm, agent="zero-shot-react-description")
response = agent.run("Your query here")

🏗 Architecture Comparison

A2A Flow

User → Slack Bot → A2A Protocol → kagent Agent → Response

Advantages:

• Direct communication path
• Minimal latency
• Full observability
• Consistent security model

LangChain Flow

User → Slack Bot → LangChain → Agent Framework → kagent → Response

Disadvantages:

• Additional abstraction layers
• Potential latency overhead
• Complex error handling
• Separate monitoring needed

🛠 When to Choose LangChain

Consider LangChain only if you need:

1. Multi-Provider Strategy: Supporting multiple LLM providers (OpenAI, Anthropic, etc.)
2. Rapid Prototyping: Building quick proof-of-concepts
3. Complex RAG: Heavy retrieval-augmented generation requirements
4. Third-party Tools: Extensive external API integrations

🔄 Hybrid Approach (Advanced)

If you need LangChain's ecosystem while keeping A2A performance:

from langchain.tools import Tool
from a2a.client import A2AClient

def create_kagent_tool():
    """Wrap A2A as a LangChain tool"""
    async def invoke_kagent(query: str) -> str:
        client = A2AClient(url=os.getenv("KAGENT_A2A_URL"))
        response = await client.send_task({
            "message": {"role": "user", "parts": [{"type": "text", "text": query}]}
        })
        return extract_response_text(response)
    
    return Tool(
        name="kagent",
        description="Invoke kagent for complex tasks",
        func=invoke_kagent
    )

# Use in LangChain agent
from langchain.agents import initialize_agent
agent = initialize_agent([create_kagent_tool()], llm)

📈 Performance Analysis

A2A Protocol

• Cold Start: ~100ms
• Response Time: 200-500ms (direct)
• Memory Usage: ~50MB baseline
• Dependencies: 5 core packages

LangChain

• Cold Start: ~2-5s
• Response Time: 300-800ms (with overhead)
• Memory Usage: ~200MB baseline
• Dependencies: 50+ packages

🔒 Security Considerations

A2A Integration

# Integrates with existing auth
headers = {
    "Authorization": f"Bearer {jwt_token}",
    "X-Security-Context": "slack-webhook"
}

LangChain Challenges

• Separate authentication setup needed
• Multiple API keys to manage
• Complex rate limiting across providers
• Additional security surface area

🎯 Final Recommendation

Use A2A Protocol for Slack bots because:

1. Proven Infrastructure: Already production-ready in our platform
2. Performance: Superior speed and resource efficiency
3. Security: Seamless integration with existing security stack
4. Maintenance: Lower operational overhead
5. Consistency: Aligns with platform architecture decisions

📚 Next Steps

1. For New Slack Bots: Use the existing A2A template
2. Security: Follow the Slack Bot Security Guide
3. Deployment: Use Terraform and Kubernetes manifests
4. Monitoring: Leverage existing metrics and alerting