Do laptop ao pipeline: escalando agents personalizados com GitHub Copilot

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: From Your Laptop to the Pipeline: Scaling Custom Agents with GitHub Copilot · Canal: AI Engineer · 19:02 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Ferramentas de desenvolvimento com IA, Infraestrutura e hardware de IA

Resumo

Jose Palafox apresenta duas formas de usar agents com GitHub Copilot: localmente, para tarefas sob demanda, e no pipeline, para trabalho autônomo em repositórios. Ele demonstra como criar agents personalizados, distribuí-los por marketplaces ou pela organização e coordenar tarefas entre repositórios. Também explica como executar agents em GitHub Actions com etapas de aprovação humana. Levar esse trabalho para o pipeline permite observar o desempenho, otimizar custos e ajustar modelos e instruções.

Pontos-chave

O Copilot oferece diferentes interfaces para interagir com agents, incluindo IDE, GitHub CLI e SDK.
O harness do Copilot gerencia tarefas de infraestrutura como autenticação, envio de solicitações aos modelos, filtragem de respostas e registro de métricas.
Agents personalizados podem ser criados com instruções, critérios de sucesso e modelos escolhidos para tarefas específicas.
Marketplaces e repositórios da organização permitem compartilhar e atualizar agents, promovendo reutilização e padronização.
O comando Orchestrate coordena subagents para trabalhar em issues e fazer alterações em vários repositórios.
Agentic Workflows permite executar o Copilot CLI em modo headless dentro de GitHub Actions ou de outros sistemas de CI.
Etapas com participação humana podem revisar resultados antes de avançar para planejamento, implementação ou aceitação.
Executar agents no pipeline, em vez de apenas em laptops, facilita monitorar uso de tokens, falhas de tool calls e custos.

Capítulos

Início	Capítulo	Resumo
00:01	Agents na plataforma e interfaces do Copilot	Jose Palafox apresenta agents locais e autônomos, as interfaces disponíveis e o papel do harness no fluxo entre usuários e modelos.
03:41	Criar agents personalizados	A demonstração aborda agents integrados, seleção de modelos e criação guiada de agents com instruções e critérios ajustáveis.
07:17	Compartilhar agents e coordenar repositórios	O palestrante explica como distribuir agents por marketplaces e pela organização e como usar Orchestrate para tarefas entre repositórios.
12:37	Executar agents em workflows de pipeline	Agentic Workflows executa agents em CI e pode incluir etapas de revisão humana antes de avançar tarefas de manutenção e implementação.
16:24	Exemplos e otimização de agents	O palestrante apresenta exemplos de agents de pipeline e explica como observabilidade e métricas ajudam a melhorar desempenho e custos.
18:30	Recapitulação e encerramento	A apresentação recapitula a criação local, o compartilhamento e a execução de agents no pipeline, antes do convite para conversar.

Citações

Isso é o que chamamos de Cappy, ou serviço de API do Copilot, e também é chamado de harness. — 02:39

A próxima questão é: como compartilho esse agent? — 07:17

Orchestrate é nossa forma de escalar horizontalmente entre repositórios. — 11:02

Se não consigo ver o que está acontecendo, não consigo otimizar. — 17:26

Tudo isso se torna possível quando levo os agents para o pipeline. — 18:30

Conceitos e entidades

Jose Palafox (pessoa): Profissional do GitHub que apresenta formas de criar, compartilhar e escalar agents.
GitHub Copilot (ferramenta): Plataforma apresentada para desenvolver e executar agents em diferentes interfaces e pipelines.
Copilot CLI (ferramenta): Interface de linha de comando do Copilot, que também pode ser executada em modo headless.
Copilot SDK (ferramenta): SDK que permite criar aplicações e integrações com agents, inclusive em Slack ou Teams.
Harness (conceito): Camada que processa as entradas, encaminha solicitações aos modelos e cuida de tarefas de infraestrutura.
marketplace (conceito): Repositório com configuração adicional que permite distribuir, versionar e atualizar agents.
Orchestrate (ferramenta): Recurso que coordena agents e subagents para executar tarefas associadas a issues em diferentes repositórios.
Agentic workflows (ferramenta): Framework para executar agents em pipelines, por exemplo, em tarefas acionadas por eventos do repositório.
GitHub Actions (ferramenta): Sistema de automação no qual é possível executar agents como parte de um pipeline.
awesome-copilot (repo): Repositório citado como fonte de agents e exemplos que podem ser disponibilizados por marketplace.
Agentics (repo): Projeto mencionado com exemplos de agents de pipeline, incluindo revisores e agentes de deduplicação de código.
Haiku (modelo): Modelo citado como opção para um agent de pesquisa de código que não exige o modelo maior disponível.
Opus (modelo): Modelo citado como autor de um plano que pode ser revisado por outro modelo.
GPT (modelo): Modelo citado como alternativa para revisar um plano produzido por outro modelo.
GitHub (empresa): Empresa onde trabalha o palestrante e que oferece a plataforma discutida.

Tradução completa (pt-BR)

00:01 [música] >> Oi, pessoal, obrigado por terem vindo. Meu nome é Jose Palafox. Estou no GitHub há 6 anos e meio. Entrei para a equipe logo depois da aquisição do GitHub pela Microsoft e, pouco depois, da aquisição de uma ferramenta chamada Semmel pelo GitHub. Também adquirimos uma empresa de segurança. Então, meu papel no GitHub tem sido expandir nosso negócio de segurança nos últimos cinco ou

00:33 seis anos. No último ano, tenho me concentrado bastante em IA, mas meu papel é trabalhar em campo com os clientes para entender como eles podem adotar nossa tecnologia e como pensar em ampliar o uso dela dentro da organização. Então, hoje vamos falar de uma introdução aos agents na plataforma, e há dois modos diferentes de pensar nos agents. Há agents autônomos que deixo rodando no pipeline e agents locais que uso para fazer vários tipos de trabalho. Vou mostrar mais ou menos como criá-los, como

01:05 pensar neles, como pensar em ampliá-los e em diferentes workflows possíveis usando agents. Esta palestra será relativamente abrangente. Então, se tiverem outras perguntas depois, ou quiserem conversar, fiquem à vontade para me procurar. Vou ficar ali no fundo da sala logo depois da palestra. Podem vir conversar comigo. Podemos falar um pouco mais a fundo sobre seus casos de uso. Esta é uma breve prévia de algumas coisas disponíveis na plataforma. Para começar, gosto de estabelecer uma base mostrando o fluxo geral de dados de como o Copilot funciona na plataforma, porque muita gente não conhece o funcionamento do Copilot

01:39 por baixo dos panos e talvez não conheça todas as nossas interfaces diferentes. Então, para dar uma rápida ideia dos recursos do produto, há várias interfaces que vocês podem usar para interagir com o coding agent. Há o IDE e o GitHub CLI, que é uma interface leve que fica no desktop. Vocês podem transmitir qualquer sessão do CLI. Então, se quiserem fechar o laptop ou se afastar dele por um tempo, podem delegar o trabalho do agent ao github.com e deixá-lo rodando em segundo plano

02:09 ou transmitir a sessão usando o comando {slash} remote, que permite fazer login pelo dispositivo móvel e controlar o agent de lá. Também há o SDK. Então, se quiserem criar agents dentro do Slack ou do Teams, ou disponibilizar funcionalidades específicas a um grupo de membros da equipe que talvez não tenham uma licença do GitHub, dá para fazer isso com bastante facilidade pelo SDK. Vocês podem criar aplicações usando o CLI ou o SDK. Independentemente da porta de entrada que escolherem

02:39 na parte de cima, vocês chegarão a esta caixa azul, que chamamos de Cappy ou serviço de API do Copilot, também conhecido como harness, certo? É ele que cuida de todas as tarefas difíceis de engenharia: pega o que vocês enviam, divide em partes e encaminha para os modelos; garante que nenhum conteúdo de provedores open source seja reproduzido; cuida da autenticação, do registro de métricas, do registro de auditoria e de todas as tarefas de infraestrutura da plataforma. E, claro, depois que vocês enviam uma mensagem,

03:10 nós a encaminhamos aos provedores de modelos. Então, independentemente da porta de entrada escolhida, vocês passam pelo harness e, em seguida, enviamos o resultado aos provedores de modelos. Quando recebemos a resposta, nós a filtramos e a exibimos para vocês. Esse é, mais ou menos, o funcionamento do produto por baixo dos panos, para que tenham uma compreensão geral das diferentes portas de entrada e de onde podem interagir com ele. Agora, se vocês começarem pelo CLI, por exemplo, terão alguns agents integrados. Acho útil dar uma olhada neles para

03:41 entender o que os agents fazem, porque há muitas maneiras diferentes de implementar um agent ou uma skill, por exemplo, e, no fim das contas, tudo acaba sendo Markdown. Então, é útil ver como estamos implementando agents na plataforma, de um jeito que vocês possam usar. Basta eu digitar {slash} agents, e isso mostra os agents padrão que fazem parte do harness do CLI. Como podem ver, há vários. Então, por exemplo, se eu quiser explorar uma base de código, não necessariamente vou querer usar

04:12 o maior modelo possível para isso. Por isso, temos um agent de pesquisa especializado, o agent explorer, que vocês podem chamar ou invocar por meio de uma palavra-chave ou do comando {slash} no CLI. Ele inicia um modelo pequeno usando Haiku e investiga uma base de código. Se vocês tiverem um plano pronto, que já escreveram em um documento de planejamento, e quiserem que outro provedor de modelos faça uma auditoria do plano porque tem dados de treinamento e pesos de modelo diferentes, tudo bem, podem fazer

04:44 isso. O Rubber duck é um agent integrado que valida um plano que sabemos ter sido escrito por Opus, com uma revisão do GPT ou algo assim. Como podem ver, todos esses modelos especificam — ou, melhor, todos esses agents especificam — o modelo. Essa é uma das opções disponíveis ao criar agents personalizados. Vocês sempre podem controlar o modelo usado e as instruções que fornecem a ele. Então, se esses modelos ou esses agents não estiverem fazendo algo de que vocês precisam, se tiverem uma tarefa específica, uma revisão ou um requisito de conformidade ou regulatório que precisem atender, e talvez tenham uma ferramenta que queiram executar ou uma série de verificações personalizadas, talvez queiram escrever um agent.

05:15 E, se quiserem, basta usar o comando agent aqui, que vai guiá-los por um workflow para adicionar um agent ao ambiente do CLI. Aqui, posso escolher se quero que ele fique no nível do projeto, no projeto Git em que estou trabalhando, ou se quero um agent disponível independentemente do projeto em que estiver trabalhando, no nível do usuário. Então, talvez eu escolha criá-lo no nível da organização ou no meu nível de usuário individual. Depois, crio o agent com o Copilot. O Copilot cria toda a estrutura para mim. Então, se eu quiser, posso gerar um agent que, por exemplo, consulte o changelog do GitHub e resuma todos os recursos mais recentes ou algo que o Copilot tenha feito. Fiz isso mais cedo hoje e gerei um agent de exemplo usando o construtor de agents integrado à

05:45 plataforma, certo? Isso está disponível em todas as interfaces. Se vocês tiverem o IDE, também terão uma interface de agents que fará o mesmo processo de criação com vocês. O bom é que ele monta toda a estrutura. Então, a partir de um prompt básico de uma linha que diz apenas: “Oi, quero acessar o changelog e resumir todas as alterações”, ele escreve a descrição para mim. Formata todo o front matter. Estrutura os critérios de sucesso. Também tenta estruturar a metodologia. Ele meio que sabe escrever esses arquivos. Então, vocês podem ser um pouco preguiçosos com isso, certo? Basta escrever algo geral

06:17 plataforma, certo? E isso está disponível em todas as interfaces. Você sabe, se tiver a IDE, também terá uma interface de agents lá que fará com você o mesmo tipo de processo de construção. Mas o bom é que ela estrutura tudo. Então, a partir de um prompt básico de uma linha que diz apenas: “Ei, quero acessar o changelog e resumir todas as mudanças”, ela escreve a descrição para mim. Formata todos os metadados iniciais. Estrutura os critérios de sucesso. Tenta estruturar a metodologia. Ela meio que sabe como escrever esses arquivos. Assim, você pode ser, sabe, um pouco preguiçoso com isso, certo? Você simplesmente escreve algo geral

06:47 descrição do que você quer fazer. Vamos preencher todos os detalhes para você. É claro que você pode entrar aqui e editar tudo isso, certo? Então, se não gostar da ordem em que ele está selecionando as fontes, neste caso, podemos mudar isso, certo? Por exemplo, este quer começar usando o roteiro do GitHub, mas talvez você queira ir direto para o changelog, sem receber itens do roteiro. Você pode simplesmente editar isso aqui, certo? Não tem problema. Mas isso faz todo o trabalho de estruturação para você. O bom agora é que você criou um agent que funciona no harness. Então, se tiver tarefas repetitivas que precisa

07:17 fazer, pode chamar esse agent para realizá-las para você, certo? Esse é mais ou menos o primeiro passo. Mas, depois de fazer isso, você fica pensando: “Qual é a próxima coisa que preciso fazer?”. E acho que a próxima coisa é: como compartilho esse agent, certo? Como outras pessoas podem aproveitá-lo? A maneira mais fácil de fazer isso no Copilot é criar um marketplace. Um marketplace é apenas um repositório com um pouco de JSON extra em um dos diretórios, indicando: “Ei, isto é um marketplace”. E ele oferece alguns recursos básicos de gerenciamento de pacotes

07:50 dentro do repo. Então, se eu me inscrever em um marketplace, posso atualizar todos os agents ao mesmo tempo. Posso versioná-los e fazer coisas assim. Posso notificar as pessoas sobre vulnerabilidades de segurança. Há recursos integrados que me permitem me comunicar com os usuários que estão mais abaixo na cadeia. Criar um marketplace costuma ser uma das primeiras coisas que faço com as empresas quando vou conversar com elas sobre como ampliar a adoção do Copilot na organização. Muitas vezes, não há um repositório central onde as equipes possam sequer contribuir com agents ou skills. Então, se você não tem um local central, deve criar

08:23 um, certo? E há um recurso para sincronizá-los com o dispositivo do cliente local e depois distribuir agents diferentes. Você também pode usar um diretório específico dentro da sua organização ou um repo específico. Então, se você estiver no GitHub, estou no nível da organização aqui; depois, entrei em um repositório, que precisa se chamar GitHub private, certo? Essa é uma convenção de nomenclatura que usamos, mas, se você tiver um repositório GitHub private, poderá disponibilizar arquivos de agent. Neste caso, tenho três agents

08:54 aqui e, como você pode ver no cloud agent, consigo chamar esse agent específico na plataforma. Mostrei antes no diagrama que você pode interagir com todos eles em diferentes superfícies. Esta é a interação com a nuvem, certo? Se eu quiser delegar a um cloud agent hospedado na plataforma, posso fazer isso aqui. Mas o bom é que este bot de conformidade que estou mostrando no menu suspenso é o mesmo bot de conformidade que está no repositório, certo? Essa é uma forma de distribuir agents para a equipe, certo? Então, se eu criar um agent útil que verifica o

09:25 changelog para mim, posso publicá-lo aqui e compartilhá-lo com todo mundo, certo? Isso vai enviá-lo para o ambiente de IDE de todos ou para o ambiente de CLI deles, e então poderão chamar o mesmo agent que estou usando. Assim, agora posso reutilizá-los, certo? Posso publicá-los em um marketplace, ou publicá-los diretamente como recursos dentro da minha empresa, para que qualquer pessoa possa chamá-los, certo? E é isso que me permite padronizar, certo? Se você analisar o modelo de custos de todos esses produtos, a forma mais barata de usá-los é obter acertos de cache, certo? Você quer

09:56 correspondências exatas entre turnos com dados comuns. E ter componentes reutilizáveis aumenta sua taxa de acerto de cache, certo? Então, se o custo é uma preocupação, criar agents reutilizáveis e garantir que as pessoas resolvam os problemas da mesma maneira, em vez de reinventar a roda sempre, é uma boa forma de reduzir sua conta total e aumentar sua taxa de acerto de cache. Então, novamente, este diretório dot GitHub private é como você compartilharia um agent internamente com todas as pessoas da organização, certo? Você pode criar um marketplace que funcione em várias organizações e que até poderia funcionar, digamos,

10:28 externamente, certo? Temos um repositório chamado awesome co-pilot com vários agents de exemplo e outras coisas. Você poderia registrá-lo como um marketplace. Isto é exclusivamente interno, certo? E um administrador pode distribuir isso. A última coisa que às vezes quero fazer quando estou trabalhando com um agent é poder usar agents em vários repositórios. O maior desafio desses agents de conformidade, por exemplo, é que eles sempre começam no repo onde o agent está. Então, se tenho agents neste repositório,

11:02 talvez eles não consigam agir em outros repositórios, certo? Preciso iniciar o agent no outro repo para que ele tenha permissões nesse repositório. No app do Copilot, há um comando chamado orchestrate. Orchestrate é nossa forma de escalar horizontalmente entre repositórios. Isso permite definir uma série de GitHub issues como objetivos para o agent e, então, iniciar subagents para lidar com todas essas tarefas. Mas o bom é que ele inicia os agents no repositório em que devem trabalhar. Então, se

11:34 você quiser executar uma tarefa em um microsserviço, como modificar uma API, e depois precisar fazer uma alteração em outro ponto mais abaixo na cadeia por causa disso, Orchestrate permite configurar vários agents que farão alterações em vários repositórios simultaneamente. Posso usar os agents pré-configurados, certo? Se estiverem disponíveis para mim nesses outros marketplaces ou forem distribuídos pelo administrador da minha organização, posso convocá-los aqui para trabalhar em repositórios individuais e mantê-los mais ou menos focados na tarefa usando essa ferramenta Orchestrate. E essas são, basicamente, três camadas de como usar agents

12:05 localmente, certo? Usar agents localmente tem muitas utilidades, certo? Mas às vezes não quero executar um agent localmente. Na verdade, quero que ele seja executado como parte do repositório, e alguns agents talvez realizem tarefas de manutenção no repo. Então, quero executá-los no repo, usando o orçamento desse repo, não o meu, certo? Ou quero executá-lo usando a identidade do repo, não a minha, certo? Nem todo agent precisa ser eu realizando uma ação. Talvez seja uma tarefa de manutenção que precise ser

12:37 feita em nome do projeto. Para trabalhar nesse modelo, temos um framework que você pode usar chamado agentic workflows. Agentic workflows é um conceito bem simples: o Copilot CLI pode ser usado em modo headless. Então, posso chamar o Copilot CLI, usar o comando -P e basicamente passar um único prompt, um prompt de execução única, para ele realizar uma tarefa. E, se eu executar isso em um runner do GitHub Actions ou em algum sistema de CI, terei um agent rodando em um pipeline para mim,

13:07 certo? Posso acioná-lo com eventos que acontecem no repo. Por exemplo, em um release, quero atualizar a documentação. Ou, toda semana, quero atualizar meus arquivos de contexto. Ou, talvez em um modelo como este, tenho várias tarefas de manutenção que quero realizar. Um dos maiores problemas atuais nos repositórios onde há muito desenvolvimento agentic é que estão adicionando muito código espaguete e muito código duplicado. Os agents são preguiçosos na implementação de funções e muito preguiçosos na definição de namespaces. Então, eles simplesmente

13:38 cria duplicação constante dentro da base de código. Então, talvez você queira um agent que examine a base de código, identifique oportunidades para eliminar duplicações de código e, em seguida, crie uma série de issues para você. E, se você usar esse framework, esse framework de workflows agentic, o legal é que vamos incluir gatilhos com intervenção humana para que você possa revisar e decidir quando realmente vai gastar dinheiro na próxima fase do fluxo. Então, neste fluxo aqui, você vê que tenho o primeiro agent talvez sendo executado em uma programação cron. Ele está examinando o repo. Identifica, você…

14:11 sabe, três itens em que há oportunidade de melhorar a base de código. Certo, ótimo. O desenvolvedor lê isso e decide se vale a pena corrigir essas coisas. E manifesta essa decisão por meio de um comando com barra, que pode adicionar como comentário na issue, certo? Então, ele vai até a issue e diz: “Certo, avance esta issue para a próxima fase do processo, certo?” Para nós, talvez seja uma fase de planejamento, certo? Então, talvez eu chame outro agent de pipeline, certo? Que é o agent gerente de produto que gera PRDs, certo? Ele vai definir o escopo do recurso para mim. Gera um plano. Entrega o plano ao Copilot na plataforma…

14:45 para implementação. E então o desenvolvedor volta a participar, talvez numa fase de aceitação, certo? Vamos examinar o código e avaliar se realmente queremos incorporá-lo ao projeto. Agora tenho agents de pipeline. E o que é muito legal nos agents de pipeline é como eles escalam. Sabe, o desafio de trabalhar localmente é que você está numa única sessão ou no seu dispositivo. Se o dispositivo parar de funcionar ou você perder a conexão com a rede, sabe, seu workflow é interrompido. Eles estão sendo executados na plataforma, então funcionam de forma autônoma, sem depender de você. Se quiser ver uma abordagem maximalista de como isso funciona, o próprio projeto GitHub AW, ou seja, o framework para criar todos esses agents, é…

15:19 inteiramente criado por agents. E essa equipe tem uma meta interna: fazer todo o desenvolvimento apenas em dispositivos móveis, porque interagem com esse aplicativo inteiramente por meio desses comandos com barra, certo? Então, só para dar uma ideia de como é um projeto de desenvolvimento totalmente conduzido por agents, este é o nosso framework, certo? E tem, sei lá, uns 200 agents aqui, todos executando diferentes partes do pipeline, certo?

15:51 E todos seguem um workflow parecido com o que acabamos de mostrar naquele slide, certo? Essa arquitetura é reutilizável. Então, deixa eu ver se consigo escolher um deles. Estou escolhendo meio que aleatoriamente, mas vamos ver o que este faz, certo? Ele verifica diariamente os relatórios de outros agents, certo? Então, este é um meta-agent que examina algumas coisas. Ele é executado diariamente e tem seu arquivo agent.md, que está trabalhando aqui, certo? Então, toda vez que ele é executado, gera algum relatório em Markdown ou…

16:24 alguma ação ou entrada para outro agent, e então continuamos acionando-o. Fiquem à vontade para dar uma olhada por aqui. Há centenas desses agents criando este projeto. O GitHub também tem vários que agrupamos. Então, dentro da nossa organização GitHub Next, há um projeto chamado Agentics. O Agentics tem cerca de 30 agents de pipeline diferentes que talvez você queira simplesmente pegar e executar no seu projeto. Alguns fazem a eliminação de duplicações de código de que falamos. Outros são diferentes tipos de revisores, então, se você precisar de um revisor de QA…

16:54 ou, sabe, quiser um que seja engraçado e conte piadas, há todo tipo de agents de exemplo diferentes que você pode pegar e colocar no pipeline. Mas o legal disso é que tira a carga de trabalho da sua máquina. E acho que, quando voltamos a pensar em custos, tirar a carga de trabalho da sua máquina é essencial para otimizar os custos, certo? Se todo mundo na minha organização está trabalhando com IA e eu digo para usarem, mas não consigo ver como estão realmente trabalhando com a ferramenta, não tenho como otimizar, certo? Não consigo realmente ver…

17:26 se os agents que estão usando são verbosos demais ou sequer estão cumprindo a tarefa. Não consigo saber quando tool calls acontecem, nem se são bem-sucedidas ou não. Não consigo saber se estão usando raciocínio de agent para todo tipo de coisa ou se estão, sabe, criando corretamente pequenos scripts bash para executar diferentes funções de busca e coisas assim. Há muitas oportunidades de otimização para mim, mas, se não consigo ver o que está acontecendo, não posso fazer nenhuma dessas otimizações. Então, ao tirar a carga de trabalho do laptop e movê-la para a CI, consigo ver o que está acontecendo…

17:58 certo? Tenho todos os agents em execução, instrumentados com OTel. Então, posso acessar um sistema de observabilidade ou algum tipo de plataforma de logs e ver como o meu agent de eliminação de duplicações de código se comporta em diferentes repositórios. Quanto isso me custa, certo? Posso analisar o uso médio de tokens. Também posso fazer coisas como dizer: “Ei, sempre que um agent ultrapassar o percentil 90 do custo que espero para executá-lo, investigue por que ele ultrapassou o limite, certo? Quero que ele me diga quais informações de depuração posso usar para…

18:30 avaliar melhor ou aprimorá-lo, certo? Ou, se eu vir que uma tool call falha repetidamente, talvez queira fazer um teste A/B com diferentes metadados iniciais, ou talvez queira fazer um teste A/B com diferentes modelos e ver se produzem a saída certa para mim, para que eu possa escolher um modelo mais barato em algum momento, certo? Tudo isso é possível quando coloco os agents no pipeline. Enfim, este foi um passeio rápido e informal pelos agents na plataforma, certo? Conversamos sobre criar um agent localmente, compartilhar agents pela plataforma e, por fim, mover esses agents para o pipeline. Se você…

19:02 quiser conversar mais sobre qualquer parte disso, vou estar lá atrás. Fique à vontade para vir falar comigo ou me adicionar no LinkedIn e mandar uma mensagem. Vou gostar de continuar a conversa. Trabalho no GitHub numa função de campo, então, se você conhece seu AE do GitHub e quiser conversar comigo, fique à vontade para falar com ele. Podemos entrar em contato e conversar rapidinho também. Muito obrigado pelo tempo de vocês hoje.

Transcrição original

[00:01] [music] >> Hey everybody, thanks for coming. My name’s Jose Palafox. I’ve been at GitHub for 6 and 1/2 years. So, I joined the team right after the Microsoft acquisition of GitHub and then shortly after GitHub acquired a tool called Semmel. We made an acquisition of a security company. And so, my role at GitHub really has been growing our security business for the last five or

[00:33] six years. In the last year, I really kind of focused on AI, but my role is to work in the field working with customers on how do they adopt our technology, how to think about scaling our technology inside of their organization. So, today what we’re going to talk about is really just like an introduction to agents on the platform and there’s sort of two different modes that I like to think of agents in. There’s like autonomous agents that I have off running in the pipeline and then I have local agents that I’m using to do various bits of work. So, I’m going to kind of walk you through sort of how to build those, how

[01:05] to think about them, how to think about scaling them, and think about different workflows that are possible using agents. This talk is going to be fairly high-level. So, if you have additional questions afterwards, you want to chat, feel free to grab me. I’ll kind of hang out right after the talk in the back of the room. You can feel free to come by and chat with me afterwards. We can talk a little bit deeper about your use cases. This is a quick preview of just kind of things that are available on the platform. Just getting us started, I always like to baseline with sort of the overall data flow of how Copilot works on the platform because a lot of people aren’t familiar with how Copilot works

[01:39] under the hood and and maybe aren’t familiar with all of our different interfaces. So, just to give you a quick preview of what the product has, you’ve got a handful of different interfaces that you can use to interact with the coding agent. You’ve got the IDE, you’ve got the GitHub CLI, which is sort of a lightweight interface that sits on your desktop. You can take any session from the CLI and you can stream it. So, if you want to you know, close your laptop or walk away from your laptop for a period of time, you can either delegate the agent to github.com and have it go run in the

[02:09] background or you can stream it using a command {slash} remote and it’ll let you log in through your mobile device and actually steer the agent from your mobile device. You’ve also got the SDK. So, if you want to create agents that live inside of Slack or inside of Teams, I’m exposed some individual functionality to a set of team members that maybe don’t have a GitHub license, you can do that pretty easily through the through the SDK. So, you can build applications using the CLI or the SDK. Regardless of what door you go through

[02:39] on the top, you’re going to hit this blue box here and this is what we call Cappy or the Copilot API service and this is also referred to as like the harness, right? This is the thing that does all the difficult engineering tasks taking your input and chunking them and sending them to the models making sure that you’re not repeating any content from open source providers, dealing with authentication for you, dealing with metrics logging, dealing with audit logging, all of the kind of like to-dos of the infrastructure of the platform. And then of course, once you send a message in,

[03:10] we take that and we pass it to the model providers. So, regardless of which door you go into, you hit the harness and then we take your output and we send it to the model providers. Once we get the output back, we filter it and then display that back to you. So, that’s sort of under the hood how the product works just so you kind of have like a high-level understanding of the different doors you can go through and and where you can touch it. Now, if you’re starting in the CLI for example, you have a handful of embedded agents and I think it’s useful to kind of look at the embedded agents just to

[03:41] understand what agents do because there’s like a lot of different you know, potential ways that you could implement whether it’s an agent or a skill or you know, it all just ends up being marked down at the end of the day. So, it’s useful to kind of see how um we’re implementing agents in the platform in a way that uh you can utilize. So, I just type {slash} agents, and all this does is drop up the um the default agents that are part of the CLI harness here. You can see I have a handful of them, right? So, if I want to explore a code base, for example, I don’t necessarily want to use

[04:12] the biggest model possible uh in order to do that. So, we have a specialized research agent, which is our explorer agent, um that you can call or invoke uh through a keyword or actually invoking like the {slash} command um in in in the CLI, and it’ll spin up, you know, a small model using Haiku, um and go and investigate a code base, right? If you um you know, have a plan that you’ve done, right? And you’ve written out a planning document, and you want a different model provider to come and audit the plan because it has different training data and different model weighting, uh then fine, you can do

[04:44] that. Rubber duck is like a embedded agent that will validate a plan that we know was written by Opus with, you know, a pass from GPT or something like that. Um you can see in all of these models they specify or in all of these agents they specify the model, and that’s one of the options that you have when you’re building custom agents. You can always control the model that you’re using, and then you control the instructions that you’re giving it. So, if these model or these um agents aren’t doing, you know, something that you need done, right? If you have a specific task or a review or you have a compliance or um regulatory

[05:15] requirement that you have to meet, and maybe you have a tool that you want to run or um a series of checks that you want to have that are custom to you. May maybe you want to write an agent. And you know, if you uh want, you can you can just use the agent command here, and it will um set you through like a a work uh a workflow to add an agent into your your CLI environment. So, here I’m getting to pick, you know, do I want this on the project level like in the Git project that I’m working on, or do I want this as like a um an agent that’s available regardless of

[05:45] which project I’m working on at the user level, right? Um so, maybe I’ll say I’m out of that at the at the org level or at my my my individual user level. And then I go ahead and create this with Copilot. Copilot will do all the scaffolding for me. So, um if I uh want, I can generate an agent that maybe uh you know, looks at the GitHub change log and it um you know, will summarize all of the latest features or something that that Copilot did. So, I did that earlier today and just generated a sample agent, you know, using this uh agent builder that’s built into the

[06:17] platform, right? And this is available in all of the interfaces. Um you know, if you have the IDE, you have an agents interface there as well that will do the same kind of build build process with you. But, what’s nice is it scaffolds everything out. So, from like a basic one-line prompt that just says, “Hey, I want to go to the change log and summarize all the changes.” It’ll write the description for me. It’ll format all the front matter. It will um structure success criteria. It’ll take an attempt at structuring methodology. Like, it kind of knows how to write these files. So, you get to be uh you know, somewhat lazy with it, right? You you you just write a general

[06:47] description of what you want to get done. We’ll fill in all the specifics for you. You can of course come in here and edit all of this, right? So, if you don’t like uh the order that it’s um picking, you know, sources in this case, um we could change that, right? Like, this one wants to start with, you know, use the GitHub roadmap, but maybe you want it just to jump straight to the change log, so you’re not getting roadmap items. You know, you can just edit it here, right? There’s no no big deal. But, this does all the scaffolding work for you. What’s nice now is you’ve created like an agent that works in the harness. So, if you have repeat tasks that you have

[07:17] to do, you can call this agent to do those tasks for you, right? Um that that’s kind of step one. Uh but, once you do that, you’re kind of like, “What’s the next thing that I got to go do?” And I think um you know, the next thing is how do I share this agent, right? How do other people uh take advantage of it? And the easiest way to do that inside of Copilot is to do that um by making a marketplace. So, a marketplace is just a repository with a little bit of extra uh JSON in one of the directories that says, “Hey, this is a marketplace.” And what it does is it gives you some light package management

[07:50] capabilities inside the repo. So, if I subscribe to a marketplace, then I can update all the agents simultaneously. I can version them, things like that. I can notify people of security vulnerabilities. You know, there’s features built in that allow me to communicate with the users that are downstream for me. So, creating a marketplace is oftentimes one of the first things that I work with companies on when I go in and try to talk with them about how to scale Copilot adoption inside their organization. A lot of times there’s not a central repository for teams to even contribute agents or skills to. So, if you don’t have a central location, you should generate

[08:23] one, right? And there is a capability basically to sync those with the the local client device and then pushing and out different agents. You can also use a specific directory inside of your organization or specific repo. So, if you’re inside of GitHub, I’m at the org level here, and then I went into a repository, and it has to be named GitHub private, right? This is a naming convention that we’ve used, but if you have a GitHub private repository, you’ll be able to expose agent files. So, in this case, I have three agents

[08:54] here, and you can see from the cloud agent, I’m actually able to call that specific agent on the platform. So, I showed you earlier in the diagram, you know, you can you can interact with all of these from different surface areas. This is the cloud interaction, right? If I want to delegate to a cloud agent that’s hosted on the platform, I can do that here. But what’s nice is this compliance bot that I’m showing you here in the the drop-down is the same compliance bot that’s in the repository, right? So, this is a way of distributing agents out to the team, right? So, if I write a handy agent that checks the

[09:25] change log for me, then I can publish it here, and I can share that with everybody else, right? So, this will push to everyone’s IDE environment or push to their CLI environment for them, and then they can just call the same agent that I’m working on. So, now I have some reuse, right? Like I can publish them in a marketplace, I can publish them directly as um assets inside of my business that anybody can call, right? And this is what’s allowing me to do standardization, right? If you look at the cost model for all of these products, the cheapest way to use them is to get cash hits, right? You want

[09:56] exact matches between turns on common data. And having reusable components will drive up your cash rate, right? So, if cost is a concern, um building reusable agents and making sure that people are solving problems in the same way, uh rather than reinventing the wheel every time, is a good way to drive down your your overall bill, drive up your cash rate. So, again, this um dot GitHub private directory, this is how you would share an agent internally to everyone inside the org, right? So, you can make a marketplace that will work across organizations, that could even work, you

[10:28] know, externally, right? So, we have a repository called awesome co-pilot that has a bunch of um you know, example agents and things. You could register that as a marketplace. This is purely internal, right? And this is like an admin can push this out. The last thing that I want to do sometimes um when I’m working uh with an agent is I want to be able to use um agents across repositories. And the biggest challenge with these uh compliance agents, for example, is that they’re always starting in the repo where the agent lives. So, if I have agents living in this repository, um

[11:02] they maybe can’t take action in other repositories, right? I need to start the agent in the other repo so that it has permissions in that repository. Um inside of the co-pilot app, there’s a command called orchestrate. Um and orchestrate is our horizontal scaling for across repo. Uh so, this will allow you to set a series of GitHub issues as uh goals for the agent, and then spin up sub agents to address all of those tasks. But, what’s nice is that it will spin up agents in the repository that it’s supposed to be working in. So, if

[11:34] you want to take a task inside of a microservice where you’re like modifying an API and then you have to make a change somewhere downstream because of that, Orchestrate will allow you to set up several agents that are going to make cross-repo changes simultaneously. So, I can use the the pre-canned agents, right? If they’re available to me in those other marketplaces or being pushed to me by my org admin, I can kind of summon them here to go do work in individual repositories and keep them sort of on task using this this Orchestrate tool. And that’s really like three layers of how do I use agents

[12:05] locally, right? Like in in using agents locally has a lot of utility, right? But sometimes I don’t want to run an agent locally. I actually want the agent to be run as a part of the repository and certain agents maybe are going to be performing like maintenance tasks in the repo. And so, I want to run them in the repo on that repo’s budget, not on my budget, right? Or I want to run it using the repo identity, not my identity, right? Not every agent needs to be me taking an action. You know, it’s it’s maybe a maintenance task that has to be

[12:37] done on behalf of of the project. When we’re working in that model, we have a framework that you can use called agentic workflows. And agentic workflows is a pretty simple concept like the Copilot CLI can be used in a headless mode. So, I can call the Copilot CLI, I can use the dash P command and basically pass it a single prompt one-shot prompt for it to go do. And then if I take that and I run that inside of a GitHub Actions runner or in some CI system, then I have an agent that’s running in a pipeline for me,

[13:07] right? So, I can trigger it on events that are happening in the repo. Like on a release, I want to update I want to update documentation. Or every week, I want to update my context files. Or, you know, in maybe a model like this, I have various maintenance tasks that I want to go do. Like one of the biggest problems today that’s happening in repositories where a lot of agentic development is happening is there’s lots of spaghetti code getting added, lots of duplicate code. Like the agents are lazy about implementing, you know, functions and they’re really lazy about namespacing. So, they’ll just like

[13:38] create constant duplication inside the code base. So, maybe you want an agent that looks inside the code base, identifies opportunities for deduplication of code, and then creates a series of issues for you. And if you use this framework, this agentic workflows framework, what’s nice is we’ll we’ll build in human in the loop triggers for you so that you can review and decide when you’re actually going to spend money on side of the next phase of the flow. So, in this flow here, you see I have the first agent maybe running on a cron schedule. It’s looking in the repo. It identifies, you

[14:11] know, three items where there’s opportunity for me to make improvement in the code base. Okay, great. The developer reads that and then makes a decision about whether or not those things are worth fixing. And they express that through a slash command that they can make as an issue comment, right? So, they they go to the issue and they say, “Okay, advance this issue to the next phase of the process, right?” For us, that’s maybe a planning phase, right? So, maybe I’m going to call another pipeline agent, right? Which is the PRD generating product manager agent, right? That’s going to scope the feature for me. It generates a plan. It hands it off to co-pilot in the platform

[14:45] for implementation. And then the developer comes back in the loop maybe at an acceptance phase, right? Let’s look at the code and evaluate whether or not we actually want to take it in the project. Now I’ve got pipeline agents. And what’s really cool about the pipeline agents is how they scale. You know, the the the the challenge with working locally is you’re on like a single session or you’re on your device. If your device goes down or you lose network activity, you know, your your workflow is interrupted. These are running in the platform, so they’re running autonomously from you. If you want to see like a maximalist approach to how this works, the GitHub

[15:19] AW project itself, like the thing that is the framework for building all these agents, it is built entirely by agents. And this team has sort of an internal goal that they’re only going to do their development on their mobile devices because they interact entirely with this application through those slash commands, right? So just to give you a feel of like what a fully, you know, agent-led development project looks like, this is this is our our our framework, right? And it has I don’t know, 200 agents in here that are all running different parts of the pipeline, right?

[15:51] And all of these follow a similar workflow that we just showed on that on that slide, right? That architecture is reusable. So let me see if I can just pick one of these. I’m a little bit picking at random here, but let’s see what this one does, right? So this is checking daily reports on other agents, right? So this is a meta agent that’s looking on things. It’s running on a daily schedule and it has, you know, its agent.md file that’s working away here, right? So every time this thing runs, it’s generating some markdown report or

[16:24] some action or input for another agent, and then we’re just continuing to trigger it. You can feel free to take a look through here. There’s hundreds of these that are creating this project. GetHub also has a bunch of them that we’ve bundled up. So inside of our GetHub next organization, there’s this project called Agentics. Agentics has 30 or so different pipeline agents that you may be interested in just pulling off the shelf and running in your project. Some of these will do the code deduplication that we talked about. Some of them are different types of reviewers, so if you need a QA

[16:54] reviewer or, you know, you want one that’s funny and just makes jokes, like there’s all kinds of different sample agents here that you can pull and drop into the pipeline. But what’s nice about this is it gets the workload off of your machine. And I think when we shift back to thinking about cost, getting the workload off of your machine is key for optimizing cost, right? If I’m having everyone in my organization work with AI and I’m telling them to go use it, but I can’t see how they’re actually working with the tool. I don’t have any opportunity to optimize, right? I can’t actually see

[17:26] whether or not the agents that they’re using are too verbose or are even achieving the task. I can’t tell when tool calls are happening if they’re successful or unsuccessful. I I I can’t tell if they’re using agent reasoning for all types of things or if they’re you know correctly building little bash scripts to actually go and do uh different search functions and things like that. Like there’s lots of optimization opportunities for me, but if I can’t see it, I can’t do any of that optimization. So, by getting the workload off of the laptop and moving it into CI, I get to see what’s happening,

[17:58] right? I have every single agent running and it’s instrumented with hotel. So, I can go to a SIM or some kind of logging platform and look, does my code duplication agent agent, how does it run across repositories? How much does it cost me, right? I can pivot on average token use. I can also do things like say, “Hey, every time that an agent exceeds its P90 for what I expect it to cost me to run, go investigate why it exceeded its its threshold, right? I want it to tell me what debugging information I can I can take to

[18:30] evaluate it further or to improve it, right? Or if I see that a tool call’s failing over and over, maybe I want to AB test different front matter or maybe I want to AB test different models and see if they produce like the the right output for me so I can pick a cheaper model at some point, right? All of this stuff is possible once I get the agents into the pipeline. Anyhow, so this was a quick and dirty kind of tour of agents in the platform, right? We talked through building an agent locally, sharing agents through the platform, and then eventually moving those agents into the pipeline. If you

[19:02] want to talk more about any part of that, I’ll be in the back. Feel free to come up and grab me or you can add me on LinkedIn and ping me. I’m happy to continue the conversation. Um, I work at GitHub in a field capacity, so if you know your GitHub AE and you want to chat with me, uh, feel free to reach out with them. Uh, we we can get in touch and and have a quick conversation as well. Thanks so much for your time today.