Olá pessoALL,

Semana passada publiquei um post sobre o GitHub Copilot Coding Agent, o tal colega de equipe autônomo que recebe issues, escreve código, roda testes e abre pull request sozinho. O retorno foi forte. Dois dias depois, o mesmo cliente ISV que me motivou a escrever aquele post mandou uma mensagem que resume o sentimento de muita gente:

"Rafael, gostei muito do Coding Agent. Mas 80% do nosso fluxo de desenvolvimento não acontece dentro do GitHub.com. A gente tem CLI interno, pipeline próprio, dashboard de qualidade que o time inteiro usa. Como é que eu coloco esse cérebro do Copilot dentro das minhas ferramentas?"

Pergunta legítima. E a resposta veio agora, em 1º de maio de 2026, quando a Microsoft anunciou em public preview o GitHub Copilot CLI ACP Server: a capacidade do Copilot CLI rodar como servidor de um protocolo aberto chamado Agent Client Protocol (ACP). Na prática, qualquer ferramenta sua (IDE proprietária, step de pipeline, bot de Slack, dashboard interno) passa a poder conversar com o Copilot por uma interface padronizada.

Se você lidera engenharia ou desenvolve plataformas internas, esse é um daqueles anúncios que parecem técnicos demais à primeira vista, mas que mudam o jogo de adoção corporativa de IA. Vou te explicar por quê.

O problema: cada ferramenta reinventando a roda

Antes de falar do ACP, vamos ser honestos sobre o estado atual. Hoje, integrar um agente de IA dentro de uma ferramenta sua é mais ou menos assim: o agente expõe a própria API REST (ou um SDK em alguma linguagem), e cada editor, IDE ou CLI escreve um cliente customizado pra falar com ele. Quando o agente muda, todo mundo refaz. Streaming, sessão, working directory, pedido de permissão pra rodar comando perigoso? Cada um resolve do seu jeito.

Resultado prático: lock-in. Você escolhe Copilot e fica preso aos pontos de integração que o GitHub oferece. Escolhe outro agente, refaz tudo. Quer que dois agentes colaborem dentro do mesmo workflow? Boa sorte.

Na faculdade chamam isso de problema N-para-N. Na vida real, é código de cola que ninguém quer manter.

ACP: USB-C para agentes de IA

O Agent Client Protocol é uma tentativa direta de resolver esse problema. A analogia que melhor explica é simples: ACP é o USB-C para agentes de IA.

Pense no que o USB-C fez no mundo do hardware. Antes dele, cada fabricante tinha seu conector. Apple com Lightning, Android com micro-USB, notebooks com plugues proprietários, câmeras com mini-USB. Você precisava de uma gaveta inteira de cabos. Hoje? Um conector, qualquer dispositivo, qualquer fabricante. Você não precisa saber se o cabo do seu carregador foi feito pela Anker ou pela Samsung. Desde que seja USB-C, funciona.

ACP propõe a mesma coisa para a conversa entre ferramentas e agentes. Qualquer cliente (IDE, CLI, pipeline, bot, dashboard) pode falar com qualquer agente que implemente o protocolo. Mensagens, streaming, sessões e permissões seguem um formato padrão. O agente não precisa saber quem está chamando, e o cliente não precisa saber qual modelo está respondendo.

Para quem quer uma analogia de software, vale lembrar do ODBC/JDBC dos anos 90. Antes do ODBC, cada aplicação que queria conversar com banco de dados precisava de driver específico para Oracle, SQL Server, DB2, Informix. Depois do ODBC, qualquer aplicação fala com qualquer SGBD através de um driver padrão. ACP faz o equivalente para o ecossistema de agentes de IA.

GitHub Copilot CLI como servidor ACP

Aqui entra o anúncio em si. O GitHub Copilot CLI, aquela ferramenta de linha de comando que executa o Copilot fora do editor, agora pode rodar em modo servidor ACP. Ou seja: deixa de ser apenas um CLI interativo e passa a ser um serviço de IA backend que qualquer ferramenta sua pode consumir.

Subir o servidor é literalmente um flag:

# Modo stdio (recomendado para integração com IDEs)
copilot --acp --stdio

# Modo TCP (para sistemas distribuídos / acesso remoto)
copilot --acp --port 3000

São dois modos pra cenários bem diferentes. Em --stdio o cliente sobe o copilot como subprocesso e conversa por stdin/stdout. É o que você quer pra extensão de IDE, plugin de editor ou CLI customizado: ambiente isolado, baixa latência, autenticação herdada do CLI já logado. Em --port o servidor abre um socket TCP e vários clientes podem conectar. Faz sentido em arquitetura distribuída, tipo um worker no Kubernetes expondo o Copilot CLI pra múltiplos consumidores.

Confesso uma coisa. A primeira reação quando vi --stdio foi torcer o nariz: "sério, stdio? Em 2026? Por que não REST/HTTP?". Perdi uns 20 minutos remoendo isso até cair a ficha. Stdio parece coisa de Unix dos anos 80 só na superfície. Na prática, é o que permite o protocolo rodar em qualquer linguagem, qualquer sistema operacional, qualquer pipeline, sem depender de runtime HTTP, sem CORS, sem porta aberta, sem certificado TLS pra gerenciar. É o mesmo motivo pelo qual CI/CD do mundo inteiro continua orquestrando coisas com pipes Unix em vez de microserviços HTTP. Funciona em qualquer lugar e dá pra debugar com cat.

Como cliente e agente conversam por baixo dos panos

Antes do exemplo prático, vale entender a arquitetura, porque ela explica decisões que à primeira vista parecem estranhas.

A comunicação acontece em JSON-RPC sobre NDJSON (Newline-Delimited JSON). Cada mensagem é um JSON em uma linha, separado da próxima por \n. Isso permite streaming bidirecional: o agente vai mandando pedaços de resposta enquanto pensa, o cliente vai consumindo em tempo real e renderizando para o usuário.

O ciclo de vida de uma interação ACP é mais ou menos esse. Cliente e agente começam trocando capabilities e versionando o protocolo (initialize). Depois o cliente cria uma sessão (newSession) com working directory próprio e a configuração de MCP servers que ela vai usar. Aí manda o prompt (texto, e em breve outros tipos), e o agente vai mandando de volta um stream de sessionUpdates: chunks de resposta, anúncios de tool call, atualizações de progresso. Quando o agente quer executar uma ferramenta sensível (rodar comando, escrever arquivo), ele dispara um requestPermission e fica esperando o cliente decidir. No fim, vem um stopReason (end_turn, cancelled, etc.) e a sessão termina.

Dois detalhes que fazem diferença aqui. O primeiro é que permissão é parte do protocolo, não um add-on. O cliente sempre tem a palavra final sobre execução de ferramenta. Isso só vai fazer sentido pra você quando segurança perguntar pela quarta vez como dá pra controlar o que o agente pode fazer no ambiente. O segundo é que sessões são isoladas: cada uma tem seu próprio cwd e seus próprios MCP servers, então dá pra ter várias sessões paralelas no mesmo processo do Copilot, cada uma trabalhando em um repo diferente, sem vazamento de contexto entre elas.

Para os curiosos: ACP reusa as representações JSON do MCP sempre que possível. Os dois protocolos são complementares, não concorrentes. MCP padroniza como agentes consomem ferramentas externas. ACP padroniza como clientes consomem agentes. Mas isso é assunto pra outro post.

Mão na massa: conectando em 5 minutos

Vamos ao código. O exemplo abaixo é a versão condensada do snippet oficial em TypeScript. Sobe o Copilot CLI como subprocesso ACP, abre uma sessão e envia um prompt, imprimindo a resposta em streaming:

import * as acp from "@agentclientprotocol/sdk";
import { spawn } from "node:child_process";
import { Readable, Writable } from "node:stream";

const proc = spawn("copilot", ["--acp", "--stdio"], {
  stdio: ["pipe", "pipe", "inherit"],
});

const output = Writable.toWeb(proc.stdin!) as WritableStream<Uint8Array>;
const input = Readable.toWeb(proc.stdout!) as ReadableStream<Uint8Array>;
const stream = acp.ndJsonStream(output, input);

const client: acp.Client = {
  async requestPermission() {
    return { outcome: { outcome: "cancelled" } }; // nega tools neste exemplo
  },
  async sessionUpdate({ update }) {
    if (update.sessionUpdate === "agent_message_chunk"
        && update.content.type === "text") {
      process.stdout.write(update.content.text);
    }
  },
};

const conn = new acp.ClientSideConnection(() => client, stream);
await conn.initialize({ protocolVersion: acp.PROTOCOL_VERSION, clientCapabilities: {} });

const { sessionId } = await conn.newSession({ cwd: process.cwd(), mcpServers: [] });
await conn.prompt({
  sessionId,
  prompt: [{ type: "text", text: "Explique o que é SNAT em uma frase." }],
});

Pré-requisitos: ter o GitHub Copilot CLI instalado, autenticado e com subscription ativa. O cliente herda essa autenticação automaticamente. Você não precisa repassar token nenhum no código.

Repare no requestPermission retornando cancelled. Esse é o handler que decide o que fazer quando o agente quer executar uma ferramenta. Em um cliente real (sua extensão de VS Code, seu pipeline) é aqui que você implementa a lógica de aprovação. Pode ser um diálogo interativo, uma allowlist de comandos, uma chamada para API de aprovação corporativa. Você é dono do comportamento.

Dica útil: rode copilot --acp --stdio | cat em um terminal e mande JSON-RPC manualmente. É terapêutico ver o protocolo bruto antes de embrulhar com SDK.

Onde isso é útil de verdade

Alguns cenários onde já estou vendo (ou conversando com clientes que querem fazer):

O primeiro é CI/CD com auto-fix. Um step do pipeline detecta falha de teste, abre uma sessão ACP com o Copilot CLI, manda contexto do erro e pede uma correção. O agente edita, roda os testes no runner, e se passar abre PR. Em vez de "alguém olha isso amanhã", o ticket já chega revisado.

O segundo é editor ou CLI corporativo. Sua empresa tem uma IDE proprietária ou um CLI interno que ninguém vai trocar. Antes do ACP, integrar Copilot ali era um projeto. Agora é um plugin que sobe o copilot --acp --stdio como subprocesso e implementa o cliente. Reaproveita autenticação, billing e governança que sua empresa já tem com o GitHub.

O terceiro, e mais interessante na minha opinião, é multi-agent. Como ACP é padrão, dá pra ter um orquestrador que conversa com vários agentes diferentes pela mesma interface. Um especializado em código, outro em análise de log, outro em testes. Sem cliente específico para cada um. Esse cenário ainda está mais no papel do que em produção, mas a base já está aí.

O quarto é ChatOps. Bot de Slack que recebe /copilot revisa esse PR. Dashboard de qualidade que mostra sugestões do Copilot lado a lado com métricas de SonarQube. Comando interno meu-cli ai diagnose que delega para o Copilot. Tudo conectando no mesmo servidor.

ACP vs integração tradicional: síntese

Se você precisa convencer um arquiteto ou um comitê técnico, segue a tabela comparativa que costumo usar:

Aspecto	Integração tradicional	ACP
Modelo de conexão	Custom por par cliente-agente	Padronizado (qualquer cliente × qualquer agente)
Streaming	Cada API resolve diferente	Nativo (NDJSON sobre stdio/TCP)
Permissão de execução de ferramenta	Ad-hoc ou inexistente	Parte do protocolo
Multi-agent	Difícil, integração N-para-N	Suportado por design
Lock-in de fornecedor	Alto	Baixo (basta trocar o servidor)
Curva de adoção em ferramenta nova	Implementar SDK proprietário	Implementar cliente ACP, reutilizar em todas

A mensagem é clara: ACP não substitui o que o Copilot faz. ACP muda como você consome o que o Copilot faz.

Limitações honestas: estamos em public preview

Pra não cair na armadilha do hype, alguns pontos pra calibrar expectativa. Public preview é public preview: a especificação pode mudar e breaking changes são possíveis, então não coloque isso no caminho crítico de produção sem plano B. O suporte a agentes remotos hospedados em cloud ainda tem gaps, segundo a própria documentação do ACP; o caso de uso forte hoje é local (subprocesso) ou TCP em rede confiável.

Debugar fluxo assíncrono é chato. Quando algo dá errado entre cliente e agente, você está lendo NDJSON cru no log. Tenha logging robusto desde o dia 1, você vai precisar. Os SDKs oficiais cobrem TypeScript, Python, Rust e Kotlin; outras linguagens vão ter que implementar o protocolo na mão, e isso não é difícil mas é trabalho.

E cuidado com a autenticação herdada do CLI. Ótimo pra workstation de desenvolvedor, problemático em servidor multi-tenant. Se for esse seu cenário, planeje arquitetura por sessão ou por processo desde o início.

Como isso conversa com o Copilot Coding Agent

Pergunta inevitável pra quem leu o post anterior: e aí, é a mesma coisa? Não. São duas peças do mesmo quebra-cabeça.

O Coding Agent é o agente em si: o cérebro que recebe issue, lê o repo, escreve código, roda teste e abre PR. Vive dentro do GitHub.com, em containers do GitHub Actions. Funciona muito bem quando o trabalho começa e termina como uma issue: backlog de UX, refactor, bugfix, atualização de dependência.

O Copilot CLI ACP Server é a interface padronizada que expõe a inteligência do Copilot pra qualquer ferramenta consumir, fora do GitHub.com. Faz sentido quando o trabalho começa em outro lugar: trigger de pipeline, comando no CLI corporativo, ação num dashboard interno, evento de incidente do PagerDuty.

Não competem. Resolvem extremos diferentes do mesmo eixo. E na prática, você provavelmente vai usar os dois.

O que levar pra discussão com seu time

Se você lidera engenharia, alguns pontos que valem entrar no radar.

Padronização tende a vencer integração ponto-a-ponto no longo prazo. Foi assim com OpenAPI, ODBC, LDAP. Não quer dizer que você precisa apostar tudo em ACP hoje, mas acompanhar de perto vale o investimento.

O modelo de permissão dentro do protocolo é o que mais costuma facilitar conversa com segurança. Em ambiente regulado, já vi muito comitê destravar uma POC só quando viu que existe um lugar do código onde dei aprovação ou neguei a ação do agente. Isso vale ouro.

E não tenha vergonha de stdio. Subprocesso isolado com pipes é mais simples, mais seguro e mais portátil que microserviço HTTP pra maioria dos casos de IA local. Já vi gente perder semana inventando wrapper REST onde --stdio resolveria em meia hora.

Por último: public preview não é sinônimo de "esperar". É "experimentar com escopo controlado". Escolhe um caso de uso interno onde o blast radius é pequeno, prova valor, e quando virar GA você já tem aprendizado e governança no lugar.

Próximos passos

Lembra do cliente ISV do começo do post? A resposta para ele foi a seguinte: comece habilitando o Copilot CLI em uma máquina, suba o servidor ACP em modo stdio, escreva um cliente de 50 linhas no seu CLI corporativo e prove o conceito em uma semana. Não tenta refatorar o mundo. Pega um fluxo onde a integração com IA hoje é manual e torna isso uma chamada ACP. O resto sai naturalmente.

Se você quer ajuda para desenhar essa adoção dentro da sua empresa (seja escolhendo o primeiro caso de uso, configurando governança ou conectando o ACP Server à sua plataforma interna) entra em contato com a gente da AzureBrasil.cloud. Como Microsoft Solutions Partner especializada em Azure e GitHub, ajudamos times a sair do "vimos uma demo legal" para "está rodando em produção com guardrails".

Referências

Documentação oficial

• Copilot CLI ACP Server (GitHub Docs) — Referência oficial dos flags --acp, --stdio e --port, com exemplo TypeScript completo
• GitHub Copilot CLI — Página do produto Copilot CLI

Agent Client Protocol

• ACP — Introduction — Visão geral do protocolo, motivação e modelo conceitual
• ACP — Architecture — Detalhes de transport, ciclo de vida e mensagens
• ACP — Protocol Overview — Especificação técnica completa
• TypeScript SDK — SDK oficial usado no exemplo deste post
• Repositório do ACP no GitHub — Código-fonte e issues

Posts relacionados

• GitHub Copilot Coding Agent: Como a IA Autônoma Está Transformando a Produtividade de Times de Desenvolvimento — Post anterior sobre o agente que vive dentro do GitHub.com

Artigo original

• From Terminal to Autonomous Coding: Mastering GitHub Copilot CLI ACP Server — Ravindra Kumar Vishwakarma (Microsoft) — Artigo que motivou este post

[]s e até a próxima!