DEV Community: Shashi Kanth

Build a Vendor-Neutral A2A Agent That Works With Any LLM Provider

Shashi Kanth — Fri, 27 Feb 2026 22:24:59 +0000

One of the most common mistakes in AI system architecture is building point-to-point integrations with specific LLM providers.

You choose Anthropic. You integrate Claude directly. Six months later you want to benchmark against GPT-4.1, or a new model drops that changes the playing field. Now you're rewriting integration code.

a2a-opencode solves this with a different approach:

Wrap OpenCode — which already supports Anthropic, OpenAI, GitHub Copilot, and more — behind the A2A protocol
Your orchestration layer speaks A2A, not "Claude API" or "OpenAI API"
Swap model providers in one config line. Your orchestrator never changes.

GitHub: https://github.com/shashikanth-gs/a2a-wrapper
npm: https://www.npmjs.com/package/a2a-opencode

What is A2A?

The A2A (Agent-to-Agent) protocol is an open standard for agent interoperability. It defines how agents:

Advertise capabilities via Agent Cards (/.well-known/agent-card.json)
Accept tasks via JSON-RPC and REST
Stream responses via SSE
Maintain task lifecycle (submitted → working → completed)

When an agent speaks A2A, any orchestrator that understands the protocol can discover and call it — without knowing anything about the underlying model or provider.

Prerequisites

Node.js 18+
OpenCode installed (npm install -g opencode-ai or equivalent)
A supported LLM provider API key (Anthropic, OpenAI, or GitHub Copilot via gh auth login)

Step 1: Start OpenCode

opencode serve
# OpenCode starts on http://localhost:4096 by default

Step 2: Install a2a-opencode

npm install -g a2a-opencode

Or run without installing:

npx a2a-opencode --config path/to/config.json

Step 3: Configure Your Agent

Create my-agent/config.json:

{
  "agentCard": {
    "name": "My OpenCode Agent",
    "description": "A vendor-neutral AI agent with MCP tool support",
    "version": "1.0.0",
    "protocolVersion": "0.3.0",
    "streaming": true,
    "skills": [
      {
        "id": "code-review",
        "name": "Code Review",
        "description": "Analyze, review, and refactor code",
        "tags": ["code", "review", "refactor", "security"]
      }
    ]
  },
  "server": {
    "port": 3001,
    "advertiseHost": "localhost"
  },
  "opencode": {
    "baseUrl": "http://localhost:4096",
    "model": "anthropic/claude-sonnet-4-20250514",
    "systemPrompt": "You are a code review expert. Analyze code for bugs, performance, and security issues.",
    "autoApprove": true,
    "autoAnswer": true
  }
}

Step 4: Start the A2A Wrapper

a2a-opencode --config my-agent/config.json

Output:

[info] A2A server started
[info] Agent Card: http://localhost:3001/.well-known/agent-card.json
[info] JSON-RPC:   http://localhost:3001/a2a/jsonrpc
[info] REST:       http://localhost:3001/a2a/rest
[info] Health:     http://localhost:3001/health

Step 5: Discover Your Agent

curl http://localhost:3001/.well-known/agent-card.json | jq .

Response:

{
  "name": "My OpenCode Agent",
  "description": "A vendor-neutral AI agent with MCP tool support",
  "version": "1.0.0",
  "protocolVersion": "0.3.0",
  "url": "http://localhost:3001",
  "capabilities": { "streaming": true },
  "skills": [...]
}

This is the A2A Agent Card — the agent's identity and capability manifest. Any A2A-compatible orchestrator can read this and immediately understand what the agent can do.

Step 6: Send a Task

Via REST:

curl -X POST http://localhost:3001/a2a/rest \
  -H "Content-Type: application/json" \
  -d '{
    "message": {
      "role": "user",
      "parts": [{"kind": "text", "text": "Review this TypeScript function for bugs and performance issues."}]
    }
  }'

Via JSON-RPC:

curl -X POST http://localhost:3001/a2a/jsonrpc \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": "1",
    "method": "tasks/send",
    "params": {
      "message": {
        "role": "user",
        "parts": [{"kind": "text", "text": "Explain the difference between debounce and throttle."}]
      }
    }
  }'

The response streams back in full A2A format with task lifecycle events and artifacts — identical to any other A2A agent, regardless of which LLM is powering it.

Switching Providers = One Line Change

Want to switch from Claude to GPT-4.1?

"opencode": {
  "model": "openai/gpt-4.1"
}

Switch to GitHub Copilot?

"opencode": {
  "model": "github/gpt-4.1"
}

The A2A interface is identical. Restart the agent. Your orchestrator doesn't change.

Multi-Agent Example

One orchestrator routing tasks to three specialized agents across providers

Run three specialized agents on different ports:

# Terminal 1: Code review agent (Claude)
a2a-opencode --config agents/code-review/config.json --port 3001

# Terminal 2: Documentation agent (GPT-4.1)
a2a-opencode --config agents/docs/config.json --port 3002

# Terminal 3: Security analysis (Claude Opus)
a2a-opencode --config agents/security/config.json --port 3003

Your orchestrator routes to whichever agent fits the task — by capability, skill tags, or load. Each agent is independently swappable.

Architecture

Full request flow from A2A client through OpenCode to any LLM provider and MCP tools

A2A Client / Orchestrator
        │
        │  JSON-RPC / REST / SSE
        ▼
a2a-opencode (Express + A2A SDK)
  ├─ SessionManager     (contextId → OpenCode session)
  ├─ EventStreamManager (SSE polling + auto-reconnect)
  ├─ PermissionHandler  (auto-approves tool calls)
  └─ EventPublisher     (OpenCode events → A2A events)
        │
        │  HTTP + SSE
        ▼
OpenCode Server (opencode serve)
  ├─ LLM inference (Anthropic / OpenAI / GitHub Copilot / ...)
  └─ MCP tool execution
        │
        │  MCP Protocol
        ▼
MCP Servers (filesystem, database, custom tools...)

Adding MCP Tools (Optional)

Want your agent to read and write files, query databases, or call custom APIs? Add an MCP section to your config:

stdio (child process):

"mcp": {
  "filesystem": {
    "type": "stdio",
    "command": "npx",
    "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/workspace"]
  }
}

HTTP MCP server:

"mcp": {
  "my-api-tools": {
    "type": "http",
    "url": "http://localhost:8002/mcp"
  }
}

Restart the agent. OpenCode handles MCP execution and tool results flow back through the A2A response stream.

a2a-copilot vs a2a-opencode — Which Should You Use?

	a2a-copilot	a2a-opencode
LLM backend	GitHub Copilot models only	Any provider via OpenCode
Auth	GitHub account / `gh` CLI token	Provider-specific (set in OpenCode)
External dependency	None (uses `gh` CLI)	OpenCode server must be running
Multi-provider support	No	Yes
Best for	Teams already on GitHub Copilot	Multi-provider or vendor-neutral setups

Both expose the same A2A interface. Your orchestrator integrates once and can use either — or both.

What You Just Built

You now have a vendor-neutral AI agent running as a standalone, fully A2A-compliant service:

Discoverable via Agent Card
Callable via JSON-RPC and REST
Streaming via SSE
Multi-turn conversations via persistent sessions
Any LLM provider swappable in one config line
MCP tool access (if configured)
Docker-deployable

Any A2A orchestrator can call it without any provider-specific code.

What's Next

Switch models: Change "model" to "openai/gpt-4.1" or "github/gpt-4.1" in your config
Add MCP tools: Filesystem connectors, database clients, HTTP API tools
Run multiple specialized agents on different ports, each with a different provider and system prompt
Use an A2A orchestrator to route tasks dynamically across agents by capability or load
Check out a2a-copilot for a zero-dependency alternative that wraps GitHub Copilot directly

GitHub: https://github.com/shashikanth-gs/a2a-wrapper
npm: npm install -g a2a-opencode
Also see: https://github.com/shashikanth-gs/a2a-wrapper (for the GitHub Copilot variant)

Turn GitHub Copilot into an A2A-Compliant Agent in Under 5 Minutes

Shashi Kanth — Fri, 27 Feb 2026 22:07:02 +0000

GitHub Copilot is one of the most capable AI coding agents available today. But out of the box, it's only accessible through VS Code, GitHub.com, or the Copilot SDK embedded in your own application.

What if you could expose Copilot as an independent, discoverable agent one that any A2A orchestrator or AI framework can call, without any Copilot-specific integration code?

That's exactly what a2a-copilot does.

GitHub: https://github.com/shashikanth-gs/a2a-wrapper
npm: https://www.npmjs.com/package/a2a-copilot

What is A2A?

The A2A (Agent-to-Agent) protocol is an open standard for agent interoperability. It defines how agents:

Advertise capabilities via Agent Cards (/.well-known/agent-card.json)
Accept tasks via JSON-RPC and REST
Stream responses via SSE
Maintain task lifecycle (submitted → working → completed)

When an agent speaks A2A, any orchestrator that understands the protocol can discover and call it without knowing anything about the agent's internals.

Prerequisites

Node.js 18+
A GitHub account with Copilot access
gh CLI authenticated (gh auth login) OR a GITHUB_TOKEN environment variable set

Step 1: Install

npm install -g a2a-copilot

Or run without installing:

npx a2a-copilot --config path/to/config.json

Step 2: Create Your Agent Config

Create my-agent/config.json:

{
  "agentCard": {
    "name": "My Copilot Agent",
    "description": "A GitHub Copilot-powered coding agent exposed via A2A",
    "version": "1.0.0",
    "protocolVersion": "0.3.0",
    "streaming": true,
    "skills": [
      {
        "id": "coding",
        "name": "Coding Assistant",
        "description": "Full-stack coding, architecture, and debugging",
        "tags": ["code", "typescript", "python", "architecture"]
      }
    ]
  },
  "server": {
    "port": 3000,
    "hostname": "0.0.0.0",
    "advertiseHost": "localhost"
  },
  "copilot": {
    "model": "gpt-4.1",
    "streaming": true,
    "systemPrompt": "You are a senior software engineer. Help with code, architecture, and debugging."
  }
}

Step 3: Start the Agent

a2a-copilot --config my-agent/config.json

Output:

[info] A2A server started
[info] Agent Card: http://localhost:3000/.well-known/agent-card.json
[info] JSON-RPC:   http://localhost:3000/a2a/jsonrpc
[info] REST:       http://localhost:3000/a2a/rest
[info] Health:     http://localhost:3000/health

Step 4: Discover Your Agent

curl http://localhost:3000/.well-known/agent-card.json | jq .

Response:

{
  "name": "My Copilot Agent",
  "description": "A GitHub Copilot-powered coding agent exposed via A2A",
  "version": "1.0.0",
  "protocolVersion": "0.3.0",
  "url": "http://localhost:3000",
  "capabilities": { "streaming": true },
  "skills": [...]
}

This is the A2A Agent Card the agent's identity and capability manifest. Any A2A-compatible orchestrator can read this and immediately understand what the agent can do.

Step 5: Send a Task

Via REST:

curl -X POST http://localhost:3000/a2a/rest \
  -H "Content-Type: application/json" \
  -d '{
    "message": {
      "role": "user",
      "parts": [{"kind": "text", "text": "Write a TypeScript function that debounces a callback with a configurable delay."}]
    }
  }'

Via JSON-RPC:

curl -X POST http://localhost:3000/a2a/jsonrpc \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": "1",
    "method": "tasks/send",
    "params": {
      "message": {
        "role": "user",
        "parts": [{"kind": "text", "text": "Explain the difference between debounce and throttle."}]
      }
    }
  }'

Copilot responds in full A2A format with task lifecycle events and streaming artifacts.

Adding MCP Tools (Optional)

Want your agent to also read and write files? Add an MCP section to your config:

stdio (child process):

"mcp": {
  "filesystem": {
    "type": "stdio",
    "command": "npx",
    "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/workspace"]
  }
}

HTTP MCP server:

"mcp": {
  "my-tools": {
    "type": "http",
    "url": "http://localhost:8002/mcp"
  }
}

Restart the agent. Copilot now has access to those tools as part of its reasoning loop.

Architecture

Full request flow from A2A client through to GitHub Copilot and MCP tools

What You Just Built

You now have GitHub Copilot running as a standalone, fully A2A-compliant agent:

Discoverable via Agent Card
Callable via JSON-RPC and REST
Streaming via SSE
Multi-turn conversations via persistent sessions
MCP tool access (if configured)
Docker-deployable

Any A2A orchestrator can call it without any Copilot-specific code.

What's Next

Switch models: Change "model" to "claude-sonnet-4-5" in your config
Add MCP tools: Database connectors, HTTP APIs, custom tool servers
Run multiple specialized agents on different ports with different system prompts
Use an A2A orchestrator to route tasks dynamically across agents
Check out a2a-opencode for a vendor-neutral alternative that supports any LLM provider

GitHub: https://github.com/shashikanth-gs/a2a-wrapper
npm: npm install -g a2a-copilot
Also see: https://github.com/shashikanth-gs/a2a-wrapper (for the OpenCode / any-provider variant)

The Missing Piece for AI-Assisted Infrastructure Management

Shashi Kanth — Wed, 31 Dec 2025 11:52:38 +0000

I have been managing my homelab for years now, and it handles a lot. Two Kubernetes clusters, a mix of physical machines and VMs, a few components running in the cloud, reverse proxies managing traffic across all of it, databases, caches the usual sprawl that happens when you actually use your infrastructure for real workloads.

Deploying something new is never just one step. It's a choreographed sequence: update the config on the reverse proxy, deploy to the right Kubernetes cluster, make sure the database migration ran, verify the cache invalidated properly, check that the monitoring picked it up. Miss a step, and something breaks in a way that takes an hour to debug.

When Claude and ChatGPT started getting genuinely good at understanding infrastructure, I had a thought: what if I could just describe what I want deployed, and have an AI coordinate across all these systems?

The problem? I'm not handing my SSH keys or kubeconfig files to anyone. Or any AI.

So I built something to solve this. It's called SSH MCP Bridge, and I'm open-sourcing it today.

The Real Problem: Coordination Across Heterogeneous Infrastructure

If you have a single server, infrastructure management is straightforward. SSH in, run commands, done.

But real infrastructure even a homelab is rarely a single server. It's a collection of machines with different purposes, different access patterns, and different failure modes. Deploying a new service might touch five different systems. Troubleshooting a problem means correlating logs and metrics across multiple hosts.

This is where AI assistance could genuinely help. Not by being smarter than me at any individual task, but by handling the coordination overhead. The AI can SSH into the reverse proxy, check the config, hop over to the app server, verify the deployment, query the database to confirm the migration ran, and report back all while I describe what I'm trying to accomplish in plain English.

But current AI integrations with infrastructure are either too locked down to be useful, or they require you to paste credentials into places that make security folks nervous. I wanted something different. I wanted to tell Claude "deploy the new version to production" and have it actually coordinate across my systems without ever seeing a single IP address, password, or private key.

That's not paranoia. That's just good architecture.

The Solution: SSH MCP Bridge

MCP (Model Context Protocol) is how modern AI assistants like Claude, ChatGPT, and VS Code Copilot connect to external tools. Instead of copy-pasting command outputs back and forth, you expose tools that the AI can call directly. The ecosystem is still young, but it's maturing fast.

SSH MCP Bridge is an MCP server that sits between your AI assistant and your infrastructure:

AI Assistant (Claude/ChatGPT/VS Code)
           |
           v
    SSH MCP Bridge
           |
           v
Your Servers (web, db, cache, etc.)

The AI talks to the bridge using MCP. The bridge holds your SSH credentials and maintains connections to your servers. When the AI wants to run a command, it asks the bridge. The bridge executes it and returns the results.

What the AI sees:

A list of friendly server names ("web-server", "database", "redis-cache")
Descriptions of what each server does
Tools to execute commands and manage sessions

What the AI never sees:

IP addresses
SSH private keys
Passwords
Network topology

This isn't just about security (though that's the main point). It also makes the AI's job easier. Instead of reasoning about "192.168.1.47", it thinks about "the production database server." That's closer to how we think about infrastructure anyway.

Two Ways to Deploy

I designed this for two different use cases, because my needs are different depending on context.

STDIO Mode is for local deployments. If you're running Claude Desktop on your laptop and your laptop can already SSH into your servers, this is the simplest path. The bridge runs as a subprocess that Claude talks to directly. No network exposure, no authentication complexity.

HTTP Mode is for remote deployments. Deploy the bridge on a server in your network (or in a container), and connect to it over HTTP/SSE. This is what you need for ChatGPT integration, or if you want a centralized MCP server that multiple clients can connect to. It supports API key auth for simple setups, and full OAuth 2.0/OIDC for enterprise environments.

What You Can Actually Do With This

Let me give you some real examples from my own usage.

Troubleshooting: "Check disk usage and memory on all servers, and tell me if anything looks concerning." The AI queries each host, aggregates the results, and gives you a summary. No more opening four terminal tabs.

Deployments: "Pull the latest code on the app server, run migrations on the database, restart the application, and verify it's responding." That's one sentence that coordinates multiple servers in the right order.

Configuration changes: "Add a new upstream server to the nginx config and reload." The AI can read the current config, make the edit, validate it, and apply it.

Investigation: "Show me the last 50 lines of the application log, and check if there are any related errors in the nginx access log." Cross-referencing logs across servers becomes conversational.

The key insight here is that the AI can maintain context across multiple commands and multiple servers. It remembers what it just checked, notices patterns, and can reason about the overall state of your system.

Session Management

SSH connections are relatively expensive to establish. You don't want to open a new connection for every command.

The bridge maintains a session pool. Once a connection to a host is established, it stays open and gets reused. Sessions automatically close after a configurable idle timeout (default is 30 minutes). There's also a cap on how many concurrent sessions per host, to prevent resource exhaustion.

For shell mode sessions (where you want working directory and environment to persist between commands), the bridge keeps a persistent shell channel open. For exec mode sessions (stateless, isolated commands), each command runs independently.

Security Considerations

I'm going to be direct about security, because infrastructure access is serious.

Credential isolation is the core principle. The bridge holds credentials; clients don't. Period.

Command-level control gives you multiple layers of restriction. First, the SSH username you configure determines what's possible at the OS level if you use a non-root user, root commands will fail even if the AI generates them. The operating system enforces this, not the bridge. On top of that, you can configure allowed or disallowed command patterns in the bridge itself. Want to block any command containing rm -rf or sudo? Add it to the deny list. Want to restrict execution to only a specific set of commands? Use an allow list. The AI never gets to run something you haven't permitted.

Authentication for HTTP mode uses either API keys (for simpler setups) or OAuth 2.0/OIDC (for enterprise). The OAuth integration works with Auth0, Azure AD, Okta, Keycloak anything that speaks standard OIDC.

Audit logging captures every command executed, with timestamp, user identity (from JWT tokens in OAuth mode), target host, and result. If you need to answer "who did what, when" for compliance or incident investigation, it's all there.

Container security: the Docker image runs as a non-root user. Mount your config and SSH keys as read-only volumes. Set resource limits. Standard practices, but important to mention.

Network isolation: in HTTP mode, put the bridge behind a reverse proxy with TLS. Restrict access at the firewall level. Consider deploying it on an internal network accessible only via VPN.

What you should NOT do: expose this to the public internet with only API key auth. That's asking for trouble.

Getting Started

If you want to try it out:

git clone https://github.com/shashikanth-gs/mcp-ssh-bridge.git
cd ssh-mcp-bridge
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

Create a config file:

server:
  enable_stdio: true
  log_level: "INFO"

hosts:
  - name: my-server
    description: "Development server"
    host: "your-server.com"
    username: "your-user"
    private_key_path: "~/.ssh/id_rsa"
    execution_mode: "shell"

session:
  idle_timeout: 30

For Claude Desktop, add to your config:

{
  "mcpServers": {
    "ssh-bridge": {
      "command": "/path/to/venv/bin/python",
      "args": ["-m", "ssh_mcp_bridge", "/path/to/config.yaml"]
    }
  }
}

Restart Claude Desktop, and ask it to list your SSH hosts. If everything's configured correctly, you should see your server listed.

Docker deployment is also available if you prefer containers. Check the repo for docker-compose examples.

Why Open Source This?

I've been using this for my own infrastructure for a while. It started as a weekend project to scratch an itch, then grew as I added OAuth support, then got more polished as I realized other people might find it useful.

The MCP ecosystem needs more tools. Right now, most examples are simple file readers, web scrapers, basic API wrappers. Infrastructure management is a harder problem, but it's also where AI assistance can provide real leverage.

I'm also hoping to get feedback and contributions. There are features I want but haven't built yet: SCP/SFTP file transfers, bastion host (jump host) support, MCP resources for exposing server state. If any of those interest you, PRs are welcome.

Wrapping Up

AI-assisted infrastructure management is coming whether we like it or not. The question is whether we do it in a way that's secure and auditable, or in a way that we'll regret later.

SSH MCP Bridge is my attempt at the former. It's not the only approach, and it might not be right for everyone. But if you've been looking for a way to let AI help with server management without compromising your security posture, give it a try.

The repo is at github.com/shashikanth-gs/mcp-ssh-bridge. Docker images are on Docker Hub. Documentation covers everything from quick start to OAuth setup to security hardening.

Questions, feedback, or war stories about AI and infrastructure? I'm interested in hearing them.