Microsoft Agent Framework Channels: Connecting .NET AI Agents to Telegram, A2A, and MCP

AI agents are becoming more useful when they can operate beyond a single application or chat interface. A production agent may need to communicate with users through Telegram, collaborate with other agents through A2A, or access external tools through Model Context Protocol (MCP).

Microsoft Agent Framework provides hosting integrations that allow a .NET agent or workflow to be exposed through multiple protocols. The important architectural idea is that the agent's core logic does not have to be rewritten for every channel. A self-hosted application can expose one or more protocol endpoints around the same callable agent or workflow.

This article explains how to structure a .NET AI agent around Telegram, A2A, and MCP, when each integration makes sense, and what to consider before taking this architecture into production.

Understanding Channels and Protocols

It is useful to distinguish between a user-facing channel and an agent communication protocol.

Telegram is a messaging channel where people interact with the agent.

A2A, or Agent-to-Agent, is designed for communication between agents across service or process boundaries.

MCP, or Model Context Protocol, standardizes access to external tools and contextual data.

Microsoft Agent Framework's current self-hosting documentation lists separate integrations for Telegram, A2A, and MCP, and these integrations can be enabled on a single host.

Integration	Primary purpose	Typical caller	Communication style
Telegram	User interaction	Human user	Messaging
A2A	Agent-to-agent communication	Another AI agent	HTTP-based protocol
MCP	Tool and context integration	Agent/workflow	Tool calls
OpenAI Responses	Application/API access	AI client	API requests

This separation makes the architecture easier to reason about.

A Practical Architecture

A production-oriented design can place the agent behind a shared application layer:

                    ┌──────────────────┐
                    │   .NET AI Agent  │
                    │   Core Logic     │
                    └────────┬─────────┘
                             │
             ┌───────────────┼───────────────┐
             │               │               │
             ▼               ▼               ▼
        Telegram            A2A             MCP
        Users          Other Agents       Tools/Data

The important part is that Telegram, A2A, and MCP should not contain your business logic.

Instead, the agent should own responsibilities such as:

Understanding requests
Selecting tools
Applying instructions
Calling business services
Producing responses

The protocol layer should primarily handle communication and transport.

This separation also makes testing easier because the same agent can be exercised without requiring a Telegram client or another remote agent.

Creating the .NET Agent

The exact model provider can vary. Microsoft Agent Framework supports Microsoft Foundry as one provider, while the application retains ownership of the agent definition and orchestration.

A simplified agent setup can look like this:

using Azure.AI.Projects;
using Azure.Identity;
using Microsoft.Agents.AI;

var endpoint = Environment.GetEnvironmentVariable(
    "AZURE_AI_PROJECT_ENDPOINT")
    ?? throw new InvalidOperationException(
        "AZURE_AI_PROJECT_ENDPOINT is not configured.");

var model = Environment.GetEnvironmentVariable(
    "AZURE_AI_MODEL")
    ?? throw new InvalidOperationException(
        "AZURE_AI_MODEL is not configured.");

var projectClient = new AIProjectClient(
    new Uri(endpoint),
    new DefaultAzureCredential());

AIAgent agent = projectClient.AsAIAgent(
    model: model,
    instructions:
        "You are a technical support agent. " +
        "Provide concise and accurate answers.",
    name: "TechnicalSupportAgent");

Using environment variables instead of embedding endpoints and credentials in source code is important for deployment and secret management.

For production applications, the agent would normally be registered through dependency injection rather than constructed directly in application startup.

Connecting an Agent to Telegram

Telegram is useful when users already interact with your application through a messaging environment.

Microsoft Agent Framework provides a Telegram hosting integration for self-hosted applications. The hosting model allows a Telegram bot to be another protocol entry point to an agent or workflow.

Conceptually, the flow looks like this:

Telegram User
     ↓
Telegram Bot API
     ↓
.NET Agent Framework Host
     ↓
AIAgent
     ↓
Response
     ↓
Telegram

The important architectural decision is to avoid implementing agent behavior inside the Telegram handler.

Instead of:

if (message.Contains("order"))
{
    // Business logic
}

prefer:

Telegram Handler
       ↓
Agent
       ↓
Order Service
       ↓
Database

This keeps the Telegram integration replaceable.

The same agent could later be exposed through a web application or another supported protocol without duplicating business rules.

Connecting Agents with A2A

A2A becomes useful when agents need to communicate across service boundaries.

For example, consider an organization with:

Customer Support Agent
        ↓
     A2A
        ↓
Billing Agent

The support agent does not need to contain all billing functionality. It can communicate with a specialized billing agent.

A2A is designed to support agent interoperability across processes, services, languages, and frameworks. Microsoft Agent Framework provides both A2A hosting and client-side support for communicating with remote A2A agents.

A hosted A2A agent can expose an HTTP+JSON endpoint:

app.MapA2AHttpJson(
    "support-agent",
    "/a2a/support-agent");

A JSON-RPC binding can also be exposed:

app.MapA2AJsonRpc(
    "support-agent",
    "/a2a/support-agent");

The framework documentation identifies both HTTP+JSON and JSON-RPC as supported A2A protocol bindings.

Agent Cards

A2A uses an agent card to describe an agent's capabilities and supported interfaces.

For example:

app.MapWellKnownAgentCard(new AgentCard
{
    Name = "SupportAgent",
    Description = "Provides technical support assistance.",
    Version = "1.0",
    DefaultInputModes = ["text"],
    DefaultOutputModes = ["text"]
});

A client can use the agent metadata to understand what the remote service provides before communicating with it.

This is especially useful in environments where multiple specialized agents exist.

Using MCP with the Agent

MCP solves a different problem.

Instead of connecting one agent to another, MCP allows an agent to access external tools and contextual resources through a standardized protocol.

For example:

                  AI Agent
                     │
        ┌────────────┼────────────┐
        ▼            ▼            ▼
    GitHub MCP    Database MCP   Files MCP
        │            │            │
     Repositories   Data         Files

Microsoft Agent Framework supports MCP integration, and the .NET implementation can work with the official MCP C# SDK. MCP tools can be retrieved from an MCP server and supplied to an agent for tool calling.

A simplified MCP client setup follows this pattern:

await using var mcpClient =
    await McpClientFactory.CreateAsync(
        new StdioClientTransport(new()
        {
            Command = "your-mcp-server"
        }));

The MCP client should be disposed correctly because it represents an external connection or process.

The framework can then retrieve available tools and make them available to the agent.

The important distinction is:

A2A connects agents, while MCP connects agents to tools and contextual capabilities.

Combining Telegram, A2A, and MCP

The three integrations can work together.

Consider a technical-support agent:

Telegram User
      │
      ▼
Telegram Integration
      │
      ▼
Support Agent
   │       │
   │       └──────── MCP ────────► Ticket System
   │
   └──────── A2A ────────────────► Billing Agent

A user could ask:

"Why was my subscription charged twice?"

The support agent might:

Receive the request through Telegram.
Determine that billing information is required.
Contact a billing agent through A2A.
The billing agent retrieves information using its own tools.
The result returns to the support agent.
The support agent generates the response.
Telegram receives the final response.

The user does not need to know which internal agent or tool handled the request.

Security Considerations

Adding protocols also increases the attack surface.

Protect Agent Endpoints

A2A endpoints should not automatically be treated as public endpoints.

Use authentication and authorization appropriate to your deployment.

Treat Protocol Identifiers as Untrusted

Microsoft's self-hosting guidance specifically recommends treating protocol-provided identifiers as untrusted input and authenticating and authorizing callers before loading sessions, checkpoints, or task state.

Secure MCP Connections

External MCP servers may receive prompt content or other application data depending on how the integration is configured.

Review the trust relationship before connecting an agent to a third-party MCP server, particularly when credentials, customer information, or internal data are involved.

Protect Secrets

Do not place:

var token = "hard-coded-secret";

inside application source code.

Use environment variables, managed identity, a secrets manager, or another appropriate secret-management mechanism.

Common Mistakes

Putting Business Logic in Channel Handlers

Avoid implementing separate business logic for Telegram, HTTP, and A2A.

Keep the business services below the protocol layer.

Treating A2A Like a Local Function Call

A2A introduces a network boundary.

That means you need to consider:

Timeouts
Authentication
Retries
Network failures
Version compatibility
Observability

A remote agent is not equivalent to an in-process method call. Microsoft also notes that A2A introduces network overhead and distributed-system operational concerns.

Giving MCP Tools Excessive Access

Only expose the tools an agent actually needs.

A tool with write access to production systems should receive considerably more scrutiny than a read-only reporting tool.

Combining Too Many Protocols Initially

It can be tempting to enable every available integration.

Start with the actual business requirement. Adding Telegram, A2A, and MCP simultaneously increases configuration, testing, monitoring, and security requirements.

Best Practices

Keep agent logic independent of communication channels.
Register agents and services through dependency injection.
Keep credentials outside source control.
Authenticate A2A callers.
Treat session and task identifiers as untrusted input.
Apply least privilege to MCP tools.
Set explicit network timeouts.
Log protocol, agent, tool, and request identifiers.
Monitor remote-agent failures separately from model failures.
Keep protocol contracts versioned and documented.
Test the agent independently from Telegram and A2A integrations.
Avoid exposing internal tools directly to untrusted users.

Telegram vs A2A vs MCP

Requirement	Recommended integration
Human users need a chat interface	Telegram
One agent needs another agent	A2A
Agent needs external tools	MCP
Agent needs business data	MCP or application service
Cross-service agent communication	A2A
External messaging experience	Telegram
Local/in-process functionality	Regular .NET service/tool

The integrations are complementary rather than competing technologies.

Advantages and Disadvantages

Advantages

Allows one agent to support multiple interaction patterns
Separates agent logic from transport concerns
A2A enables cross-service agent interoperability
MCP provides standardized tool integration
Telegram provides a familiar user-facing interface
Supports a more modular agent architecture
Makes it easier to replace or add communication channels

Disadvantages

More endpoints increase operational complexity
Distributed A2A calls introduce network latency
MCP servers create additional trust boundaries
Protocol authentication requires careful implementation
Debugging multi-agent workflows can be more difficult
Session and state management become important for long-running workflows

Troubleshooting Checklist

When a multi-channel agent does not behave as expected, check the integration layer first.

Verify that the agent itself works without the external protocol.
Check environment variables and credentials.
Verify the protocol endpoint and routing configuration.
Check authentication and authorization failures.
Review A2A agent-card configuration.
Check whether the MCP server is reachable.
Verify that the expected MCP tools are available.
Inspect application logs for request and correlation identifiers.
Check network timeouts when communicating with remote agents.
Test each protocol independently before testing the complete workflow.

Conclusion

Microsoft Agent Framework makes it possible to separate an AI agent's core behavior from the protocols used to access it. Telegram can provide a human-facing messaging interface, A2A can connect specialized agents across service boundaries, and MCP can provide standardized access to external tools and context.

The most maintainable architecture is to keep these integrations at the edges of the application while keeping business logic, agent instructions, and domain services independent from them.

For production systems, the technical integration is only one part of the problem. Authentication, authorization, state isolation, observability, network failures, tool permissions, and protocol versioning should be designed alongside the agent itself.