GitHub Agent HQ: O que é, para quem é e o que fica de fora

Você descreve uma funcionalidade, entrega a tarefa a um agente de código e vai cuidar da sua vida enquanto ele abre um pull request. Depois faz o mesmo com um segundo agente, e com um terceiro. Não demora muito e o verdadeiro problema deixa de ser criar agentes e passa a ser acompanhá-los. O GitHub Agent HQ é a resposta do GitHub para essa bagunça: uma central de comando que reúne agentes de código de vários fornecedores em um único ponto de controle dentro do GitHub. A ideia é genuinamente forte, e este guia mostra o que ele é, para quem serve e a linha que a maioria dos artigos ignora: o Agent HQ coordena trabalho que vive dentro do ecossistema GitHub, não as ferramentas que ficam fora dele.

Essa fronteira importa no momento em que seu time não está 100% no GitHub. Se o seu rastreador de tarefas é o Jira, seus repositórios estão no GitLab, ou metade dos seus agentes roda em notebooks e terminais que nunca tocam a nuvem do GitHub, você precisa de uma camada que fique acima de todas as ferramentas, e não dentro de uma delas. Essa camada é o Sharkly, uma plataforma tudo-em-um de comando e gestão de agentes. Este artigo mostra onde o Agent HQ se destaca, exatamente onde está o seu limite e como uma camada neutra mantém uma frota heterogênea visível da solicitação até a entrega.

Vamos assumir a melhor versão possível do Agent HQ ao longo de todo o texto, porque ele merece isso. Depois vamos traçar a fronteira com clareza, para que você consiga dizer em cerca de dois minutos se o Agent HQ basta por si só ou se você já superou um hub de ecossistema único.

Resumo rápido

O GitHub Agent HQ é um plano de controle dentro do GitHub, batizado de Mission Control, para atribuir, direcionar e acompanhar agentes de código de vários fornecedores (Claude, Codex, Google, Cognition, xAI) como parte de uma assinatura paga do GitHub Copilot. Ele é agnóstico em relação aos modelos e excelente quando o seu trabalho já vive em repositórios, pull requests e Actions do GitHub. Seu limite é o ecossistema, não o fornecedor do agente: ele coordena agentes que trabalham dentro do GitHub, portanto não gerencia execuções no GitLab, em um quadro do Jira, no Bitbucket ou em agentes rodando localmente em Computadores fora da nuvem do GitHub. Use o Agent HQ quando sua empresa estiver totalmente integrada ao GitHub. Use uma camada neutra como o Sharkly quando seu time mistura rastreadores, hosts e runtimes e precisa de um registro compartilhado com revisão humana em todos eles.

O que o GitHub Agent HQ realmente é

O GitHub Agent HQ é uma central de comando dentro do GitHub para atribuir, direcionar e acompanhar agentes de código de vários fornecedores, entregue por meio de uma assinatura paga do GitHub Copilot. Essa única frase carrega toda a ideia. Em vez de cada agente viver na sua própria ferramenta com sua própria interface de lançamento, o Agent HQ os reúne em um único lugar que o GitHub chama de Mission Control, acessível pelo próprio GitHub, pelo VS Code, pelo aplicativo móvel e pela linha de comando.

O ponto de virada que vale destacar é que o Agent HQ não é o agente de um único fornecedor. O GitHub o abriu para agentes de código da Anthropic, OpenAI, Google, Cognition e xAI, então você pode escolher o Claude para uma etapa e o Codex para outra sem sair do hub. Você atribui uma tarefa a um agente, ele trabalha em uma branch no ambiente do GitHub, executa suas verificações e devolve um pull request que você revisa da mesma forma que já revisa código. O Mission Control é onde você acompanha várias dessas execuções ao mesmo tempo, e recursos como o Plan Mode ajudam a moldar o trabalho antes de o agente começar.

O propósito do hub é a coordenação. Você não fica pulando entre cinco ferramentas de agentes diferentes tentando lembrar qual está fazendo o quê. Se você leu nosso explicativo sobre o que significa orquestração de agentes de IA, o Agent HQ é a orquestração na sua forma de ecossistema único: vários fornecedores de agentes, uma plataforma, e essa plataforma é o GitHub.

O que o Agent HQ faz bem

Considere o recurso na sua melhor forma, porque a melhor versão é forte. Aqui está onde o Agent HQ conquista seu espaço.

Escolha de agente neutra em relação ao fornecedor. A maioria dos hubs de agentes prende você a um único criador de modelos. O Agent HQ não. Você pode rodar Claude, Codex e outros lado a lado e ir da ideia à implementação usando agentes diferentes para etapas diferentes, sem trocar de ferramenta nem perder contexto. Essa é uma resposta real ao aprisionamento a um modelo, e é o recurso que o lançamento destaca em primeiro lugar, com razão.

Uma central de comando em todas as superfícies. O Mission Control oferece uma visão única da atividade dos agentes no GitHub, no VS Code, no celular e na CLI. Você atribui, direciona e acompanha de onde já estiver. Para um time que costumava gerenciar execuções paralelas na mão, nosso guia sobre como rodar vários agentes do Claude Code em paralelo mostra o quão trabalhosa fica a versão faça-você-mesmo. O Agent HQ elimina esse malabarismo dentro do GitHub.

Trabalho que chega onde a revisão já acontece. Os agentes trabalham em branches e devolvem pull requests. O resultado se encaixa direto no fluxo de revisão do GitHub em que seu time confia, com a mesma revisão de código, as mesmas verificações e as mesmas regras de merge que você já usa. Nenhum lugar novo para procurar um diff.

Nativo da plataforma em que os times já vivem. Se o GitHub é a sua casa, o Agent HQ não é um acessório acoplado. Ele compartilha sua identidade, suas permissões, suas Actions e seus repositórios. Instruções e controles personalizados de agentes ficam ao lado do código sobre o qual atuam, então a configuração fica perto do trabalho em vez de isolada em um console separado.

Para um time padronizado no GitHub de ponta a ponta, esse é um ciclo organizado e poderoso. Descreva o trabalho, escolha um agente, revise o pull request, faça o merge. Se esse é o seu caso, o Agent HQ pode ser toda a orquestração de que você precisa, e você pode parar de ler aqui com a consciência tranquila.

Para quem o Agent HQ é indicado

O Agent HQ foi criado para a empresa totalmente integrada ao GitHub, e atende muito bem esse perfil. O encaixe mais claro é este: seu código-fonte vive em repositórios do GitHub, sua CI roda no GitHub Actions, seu time revisa e faz merge por pull requests do GitHub, e você tem uma assinatura paga do Copilot. Tudo o que um agente precisa para ler, alterar, testar e entregar já está dentro de uma única plataforma, então um hub dentro dessa plataforma tem alcance total sobre o trabalho.

O valor se acumula para esse time conforme a implementação avança ao longo de 2026. Cada novo fornecedor de agente e cada novo recurso do Mission Control chega no lugar onde seu trabalho já está. Você não integra nada. Você apenas liga mais partes de uma plataforma que já usa. Para uma organização de engenharia centrada no GitHub, esse é o caminho mais curto entre uma tarefa descrita e uma alteração revisada e integrada.

A questão não é se o Agent HQ é bom nisso. É se a realidade do seu time cabe dentro do GitHub, por inteiro. E é aí que entra a fronteira.

A fronteira honesta: ele orquestra o ecossistema GitHub, não as suas outras ferramentas

Aqui está a linha que os anúncios raramente traçam para você, e não é a que as pessoas esperam. O limite não é o fornecedor do agente. Nesse ponto, o Agent HQ é surpreendentemente aberto. O limite é o ecossistema. O Agent HQ coordena agentes que trabalham dentro do GitHub: repositórios, pull requests, Actions e identidade do GitHub, sob uma assinatura do GitHub Copilot. Cada parte disso é uma parte do GitHub. Isso não é um defeito. É o projeto. Mas isso estabelece uma barreira rígida no dia em que o trabalho do seu time deixa de viver inteiramente no GitHub.

O Agent HQ não gerencia trabalho no GitLab ou no Bitbucket. Se parte dos seus repositórios ou pipelines está fora do GitHub, os agentes coordenados pelo Agent HQ não chegam até eles. Essas execuções vivem em um mundo separado, sem linha do tempo compartilhada.

O Agent HQ não é o seu rastreador de projetos. Ele coordena agentes em relação a código e pull requests. Se seu time planeja e distribui trabalho no Jira ou no Linear, a questão de quem é o responsável por uma tarefa, do que ela depende e o que está bloqueado vive em um sistema que o Agent HQ não opera. Um pull request é uma superfície de revisão, não uma camada de atribuição e contexto.

O Agent HQ não coordena agentes que rodam fora da sua nuvem. Se um colega roda o Claude Code em um terminal local, ou o Codex no próprio Computador, ou um agente em um runtime que você mesmo hospeda, esse trabalho não aparece no Mission Control. O hub vê os agentes que ele lança dentro do GitHub, não os que seu time roda em outros lugares.

Nada disso é uma crítica ao GitHub. Diga o que uma ferramenta não é, de forma clara, exatamente no ponto em que o leitor poderia supor errado: o Agent HQ é um plano de controle de ecossistema único, não uma camada de coordenação neutra entre todos os rastreadores, hosts e runtimes que seu time usa. Se toda a sua stack é GitHub, a fronteira nunca incomoda. No momento em que parte dela não é, incomoda.

O par de decisão: empresa totalmente no GitHub ou time com ferramentas mistas

A escolha não é “hub bom contra hub ruim”. É “qual formato de coordenação combina com o seu time”. Aqui está o par de decisão honesto.

Use o GitHub Agent HQ quando sua empresa estiver totalmente integrada ao GitHub. Repositórios, Actions, pull requests e assinaturas do Copilot, sem trabalho relevante fora desse ecossistema. Nesse mundo, o Agent HQ é o caminho mais curto de uma tarefa até uma branch revisada, e adicionar outra camada seria uma sobrecarga desnecessária. O hub tem alcance total porque o trabalho tem uma única casa.

Use uma camada neutra quando seu time mistura rastreadores, hosts e runtimes. No instante em que sua realidade inclui um quadro do Jira, um repositório no GitLab ou agentes rodando em Computadores que você controla fora da nuvem do GitHub, o que falta não são mais agentes. É um registro compartilhado. Você precisa de uma única Task que guarde o objetivo, o diff, a discussão e a revisão humana, não importa qual host, rastreador ou runtime tenha feito o trabalho. Essa é uma função para uma camada que fica acima de todas as ferramentas, e não dentro de uma delas.

Essa é a mesma bifurcação que os desenvolvedores encontram em qualquer hub de fornecedor único, que abordamos no caso do editor em agentes em segundo plano do Cursor, explicados, e para quadros locais no guia de alternativa ao Vibe Kanban. A orquestração de ecossistema único é confortável até o momento em que o ecossistema deixa de ser a história inteira.

Onde o Sharkly se encaixa: a camada neutra em torno de cada runtime e rastreador

O Sharkly não substitui o GitHub, o Copilot, o Claude Code, o Codex ou outras ferramentas de execução. Ele adiciona a camada compartilhada de Task, Computador, contexto, controle e revisão em torno das ferramentas que seu time já usa. Essa frase resume toda a relação, então leia duas vezes. Você mantém o GitHub. Você mantém o Agent HQ onde ele se encaixa. O Sharkly é o que coordena a frota quando a frota é maior do que um único ecossistema.

A divisão do trabalho é limpa. GitHub, Copilot, Claude Code, Codex e ferramentas semelhantes executam. O Sharkly gerencia a atribuição no nível do time, os Computadores conectados, o contexto da Task, o progresso, os bloqueios, os resultados e a revisão humana entre essas ferramentas. Os agentes pesquisam, executam, testam e reportam. As pessoas definem a direção, concedem autoridade e aceitam o resultado. A automação para onde o julgamento do time é necessário.

Na prática, uma Task no Sharkly é a unidade principal de trabalho, e ela guarda tudo sobre uma peça de trabalho em um só lugar. Você a atribui a um Agente rodando em um Computador que você controla, com o Runtime da sua escolha. A execução, os bloqueios, os resultados e a discussão de acompanhamento voltam para a linha do tempo da Task, em vez de se espalharem pela nuvem de uma plataforma, por um rastreador separado e por um punhado de terminais privados. O objetivo, o diff, a discussão e a revisão de cada execução ficam juntos, seja essa execução feita pelo Agent HQ dentro do GitHub, pelo Claude Code no Computador de um colega ou por algo que você adote no ano que vem.

E ele não exige que você reconstrua nada. Mantenha os projetos, tarefas, status e fluxos de trabalho que seu time já entende, conecte o Sharkly aos rastreadores e hosts que você já usa e comece a direcionar o trabalho sem refazer o processo que seu time já adota. O uso dos modelos continua pelas assinaturas ou chaves de API configuradas nessas ferramentas, então você traz a sua própria assinatura e o Sharkly adiciona a coordenação por cima. Se você é novo na plataforma, conheça o Sharkly apresenta as ideias centrais, e o tutorial da primeira tarefa mostra a menor versão útil de ponta a ponta. Você pode baixar o Sharkly e conectar um Computador para testá-lo com trabalho real.

Erros comuns a evitar

• Supor que “neutro em relação ao fornecedor” significa “neutro em relação à ferramenta”. O Agent HQ é aberto quanto a qual agente executa o trabalho, e isso é uma força real. Ele não é aberto quanto a onde o trabalho vive. Os agentes continuam operando dentro do GitHub. Leia a fronteira como ecossistema, não como criador de modelo.
• Adotar o hub de um ecossistema como se fosse toda a sua estratégia. Se você padronizar no Agent HQ hoje e mantiver um repositório no GitLab ou um quadro no Jira no próximo trimestre, você terá dividido sua superfície de coordenação sem perceber. Decida desde cedo se você está realmente 100% no GitHub ou se é um time com ferramentas mistas.
• Tratar pull requests como a camada de coordenação. Pull requests são uma superfície de revisão, não uma camada de atribuição e contexto. Quem é o responsável pela Task, do que ela depende e por que está bloqueada não cabem em um diff.
• Esquecer os agentes que nunca passam pelo hub. Qualquer execução iniciada fora do GitHub, em um terminal local ou em um Computador que você hospeda, não aparecerá no Mission Control. Conte essas execuções antes de chamar um único hub de fonte única da verdade.

GitHub Agent HQ vs. uma camada de orquestração neutra

Leia isto como uma divisão de trabalho, não como um placar.

Nenhuma das colunas está “errada”. Se a sua resposta linha a linha cair majoritariamente na coluna da esquerda, o Agent HQ serve. Se ela tender para a direita, especialmente nas linhas sobre onde o trabalho vive, rastreador e registro compartilhado, você já superou a orquestração de ecossistema único.

Principais conclusões

• O GitHub Agent HQ é um plano de controle dentro do GitHub, batizado de Mission Control, para atribuir, direcionar e acompanhar agentes de código de vários fornecedores como parte de uma assinatura paga do Copilot.
• Ele faz isso bem: escolha de agente neutra em relação ao fornecedor, uma central de comando no GitHub, no VS Code, no celular e na CLI, e trabalho que chega ao fluxo de revisão de pull requests em que você já confia.
• Seu limite é o ecossistema, não o fornecedor do agente: ele coordena agentes que trabalham dentro do GitHub, então repositórios no GitLab, quadros no Jira e agentes rodando fora da nuvem do GitHub ficam de fora.
• Use o Agent HQ quando sua empresa estiver totalmente integrada ao GitHub. Use uma camada neutra quando seu time mistura hosts, rastreadores e runtimes e precisa de um registro compartilhado com revisão em todos eles.
• O Sharkly atua junto com o GitHub, não no lugar dele: mantenha suas ferramentas, traga a sua própria assinatura e deixe cada execução voltar para uma única Task, da solicitação até a entrega.

O próximo passo é pequeno de propósito. Conecte um Computador, crie um Agente e atribua a ele algo bem trivial. A documentação aprofunda cada conceito em docs.sharkly.ai.

Perguntas frequentes

O que é o GitHub Agent HQ em uma frase? É uma central de comando dentro do GitHub, batizada de Mission Control, que atribui, direciona e acompanha agentes de código de vários fornecedores como parte de uma assinatura paga do GitHub Copilot, com os agentes trabalhando em branches e devolvendo pull requests.

Quais agentes podem rodar no Agent HQ? O GitHub o abriu para agentes de código da Anthropic, OpenAI, Google, Cognition e xAI, então você pode escolher o Claude para uma etapa e o Codex para outra sem sair do hub. A lista exata cresce conforme a implementação avança ao longo de 2026.

O GitHub Agent HQ é gratuito? Não. Ele é entregue por meio de uma assinatura paga do GitHub Copilot, com disponibilidade vinculada a planos como o Copilot Pro+ e o Copilot Enterprise. Consulte as próprias páginas do GitHub para detalhes atuais dos planos, já que eles mudam conforme a implementação avança.

O Agent HQ funciona com GitLab ou Jira? O Agent HQ coordena agentes que trabalham dentro do ecossistema GitHub: repositórios, Actions e pull requests. Trabalho no GitLab ou no Bitbucket, e planejamento no Jira ou no Linear, ficam fora dele. Uma camada neutra acima de todas as ferramentas é o que conecta esses pontos. Veja nosso explicativo sobre os agentes em segundo plano do Cursor para a versão dessa mesma fronteira no caso do editor.

Preciso substituir o GitHub para usar o Sharkly? Não. O Sharkly não substitui o GitHub nem qualquer ferramenta de execução. Ele adiciona a camada compartilhada de Task, contexto e revisão em torno das ferramentas que você já usa, então GitHub, Copilot e Agent HQ continuam funcionando exatamente como antes.

Quando eu não deveria adicionar uma camada de orquestração sobre o Agent HQ? Se toda a sua stack é GitHub — repositórios, Actions, pull requests e Copilot — sem trabalho relevante em outros lugares, o Agent HQ pode ser toda a orquestração de que você precisa. Adicione uma camada neutra apenas quando você usar vários hosts, rastreadores ou runtimes e precisar de um registro compartilhado entre eles.

O Sharkly muda a forma como eu pago pelos modelos? Não. Você traz a sua própria assinatura. O uso dos modelos continua pelas assinaturas ou chaves de API configuradas nas ferramentas conectadas, e a cota de modelo depende dos planos e contas de API que seu time conectar.

Como experimentar a abordagem de camada neutra sem uma grande migração? Comece pelo menor fluxo de trabalho útil: conecte um Computador, crie um Agente e atribua a ele uma Task de baixo risco. O tutorial da primeira tarefa cobre isso passo a passo, e rodar vários agentes do Claude Code em paralelo mostra o lado da frota.