Trocar de agente na IDE não garante o mesmo contexto de trabalho

Você está mexendo numa tela do app. O primeiro agente encontrou o componente, entendeu as instruções do repositório e rodou os testes. Você troca de agente; o painel da IDE continua no mesmo lugar. O trabalho, porém, pode parar num detalhe bem menos visível: o novo agente não recebeu a mesma documentação, não tem a ferramenta de build configurada ou precisa pedir autorização de novo.

É uma situação hipotética, mas dá para testá-la sem esperar que aconteça no meio de uma entrega.

A conexão com a IDE cobre só parte do caminho

O Android Studio passou a oferecer, em prévia no canal Canary, a opção de conectar agentes compatíveis com ACP (Agent Client Protocol). Nesse fluxo, a IDE pode oferecer informações do projeto e ferramentas como diagnóstico de build, Compose Preview e emulador. Isso ajuda o agente a trabalhar no projeto Android. Não significa que duas contas, dois agentes ou duas configurações terão as mesmas permissões e instruções.

Outra peça é o que você instala ao redor do agente. O plugin google-cloud-developer, por exemplo, reúne orientações e a configuração de acesso à documentação pelo Developer Knowledge MCP. Para funcionar no seu ambiente, ainda há instalação e configuração, incluindo autenticação. ACP conecta agente e IDE; um pacote de instruções e ferramentas ajuda a preparar o ambiente de trabalho. Uma coisa não substitui a outra.

E tem a sessão. O Agent Host do VS Code permite acompanhar uma sessão entre diferentes clientes conectados ao mesmo host. Isso não é promessa de levar o histórico de um agente para outro. São problemas distintos: acessar o projeto, encontrar as ferramentas certas e retomar uma conversa em andamento.

Faça a troca passar por uma tarefa pequena

Escolha algo reversível no mesmo repositório: uma tela com um teste existente, por exemplo. Antes de trocar, anote qual arquivo o agente atual encontrou, quais instruções usou, qual teste rodou e quais acessos precisou. Depois peça ao novo agente para:

1. Localizar o ponto de entrada da tela e explicar de onde vieram as instruções que está seguindo.
2. Descrever a alteração que faria, sem mexer no código ainda, e indicar o teste apropriado.
3. Rodar esse teste somente depois de você conferir as permissões solicitadas. Não conceda acesso de produção nem autorização para publicar ou fazer deploy só para completar a checagem.

Compare os resultados. Ele viu as regras do repositório? Conseguiu usar a ferramenta de teste? Precisou instalar um plugin, autenticar um serviço ou explicar de novo a tarefa? Registre o que faltou e o que o novo agente conseguiu fazer com segurança.

Se você mantiver definições de ferramentas em JSON, uma comparação com dados inventados ajuda a enxergar campos ausentes ou diferentes. Se o exemplo ficar difícil de comparar, confira a sintaxe e formate o JSON; o DevSexy pode servir de apoio nessa etapa. Use apenas dados fictícios, sem chaves, tokens, endpoints privados ou configurações reais. Um JSON válido ainda não prova que o MCP se conecta, que a permissão é adequada ou que uma sessão foi preservada.

Se o teste pedir acesso demais para uma tarefa tão pequena, reduza as ferramentas disponíveis e repita. A troca vale a pena quando o novo agente consegue avançar numa tarefa delimitada e você consegue apontar, sem adivinhar, o que teve de reconfigurar.

Referências

• Android Developers — Bring Your Own Agent no Android Studio (prévia Canary)
• Google Cloud — Google Cloud Developer Plugin para agentes de código
• VS Code — arquitetura do Agent Host e do AHP