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:
- Localizar o ponto de entrada da tela e explicar de onde vieram as instruções que está seguindo.
- Descrever a alteração que faria, sem mexer no código ainda, e indicar o teste apropriado.
- 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.