Prepara a passagem para uma tarefa concreta
Começa por dizer por que vais mudar de agente e que trabalho esperas receber a seguir. A passagem deve orientar uma tarefa delimitada, não entregar uma autorização genérica para reformular o projeto. Indica o resultado pretendido e as partes que o novo agente precisa de compreender antes de propor ou executar alterações.
Imagina que um agente construiu o primeiro ecrã de um portal e que outro vai verificar o processo de aprovação. O segundo precisa de saber o comportamento esperado e localizar a implementação, mas não recebeu automaticamente autorização para redesenhar a interface. Separar revisão de edição ajuda a interpretar o papel de quem recebe o trabalho.
Neste exemplo hipotético, o pedido pode ser identificar divergências entre o processo acordado e o que está implementado, apresentando evidência. Se depois decidires corrigir essas divergências, defines o âmbito da alteração. O motivo de mudar de agente deve ficar claro para evitar que a passagem se torne um reinício de todas as decisões.
A prática de dar contexto à IA com critério é útil para escolher o conteúdo da passagem. Entrega o que permite compreender a tarefa e aponta para detalhe adicional. Copiar a conversa inteira pode transferir muitas palavras sem esclarecer qual é a versão aprovada do objetivo e do trabalho.
Para preparar o próximo passo, consulta Desenvolver aplicações com IA.
Transfere decisões com o seu estado e a sua razão
Regista o que foi decidido, quem confirmou e por que essa escolha importa para o projeto. Distingue decisões em vigor, sugestões ainda abertas e escolhas substituídas. A razão ajuda o novo agente a respeitar a intenção sem interpretar uma solução anterior como obrigação técnica imutável ou uma ideia exploratória como requisito aprovado.
No portal, pode estar decidido que só um responsável dá aprovação final porque a empresa quer concentrar essa responsabilidade. O aspeto visual do botão pode ainda estar em revisão. Se ambos aparecem numa lista de comentários sem estado, o agente seguinte pode tratar o requisito de autorização como detalhe opcional e o desenho provisório como definitivo.
A preparação do plano de uma aplicação ajuda a manter requisitos separados das decisões de implementação. O novo agente pode encontrar outra forma de cumprir o mesmo requisito, mas precisa de mostrar como preserva o comportamento esperado. Uma preferência por outra tecnologia não basta para justificar uma mudança que reabre trabalho já validado.
Também interessa saber que alternativas foram rejeitadas e porquê, quando esse motivo continua relevante. Um registo curto evita repetir uma proposta já recusada por incompatibilidade com o negócio. Não transformes todas as experiências antigas em proibições permanentes: conserva o motivo e as condições, permitindo reconsiderar uma escolha se aparecer evidência nova.
Mostra o estado nos ficheiros e nas verificações
A passagem deve apontar para os resultados existentes e explicar que verificações lhes correspondem. Identifica a versão ou o momento a que o registo se refere, bem como trabalho local ainda não integrado. O novo agente precisa de distinguir o que encontra no projeto do que alguém pretendia fazer ou afirmou ter terminado.
No exemplo do portal, pode existir uma alteração guardada num ficheiro local, mas ainda ausente da versão partilhada com a equipa. Se o resumo diz apenas que a funcionalidade foi concluída, o destinatário pode procurar no sítio errado ou reconstruir trabalho que já existe. A localização e o estado de integração evitam essa ambiguidade.
Relaciona cada verificação com o que realmente demonstra. Uma conferência visual do ecrã não prova que as permissões funcionam, e um teste local não confirma uma alteração online. Guarda referências aos resultados pertinentes e explica os limites conhecidos para que a revisão seguinte comece na incerteza real, sem repetir sucessos nem presumir validações inexistentes.
O princípio de conseguir explicar por que uma automação alterou uma campanha também serve para esta passagem. Uma ação deve poder ser ligada ao pedido, aos dados e à decisão que a sustentou. O agente que recebe o projeto precisa dessa ligação para avaliar o trabalho, além do resultado visível.
Confirma instruções, acessos e âmbito no novo ambiente
Antes de executar, verifica que o novo agente recebeu as instruções pertinentes e tem apenas os acessos necessários à tarefa. A troca de ambiente pode mudar a forma de encontrar documentos e ferramentas. O conteúdo transferido explica o projeto, mas não garante configurações equivalentes nem cria autorização para ações que não foram pedidas.
Se o projeto utiliza ficheiros de instruções, confirma quais são efetivamente lidos e qual é a referência principal. Não pressuponhas que nomes ou estruturas são reconhecidos de forma idêntica por ferramentas diferentes. Indica os documentos a consultar e verifica que os limites relevantes aparecem na compreensão da tarefa antes da primeira alteração.
As credenciais não devem circular no documento de passagem. Regista onde se obtém acesso autorizado e o que falta configurar, mantendo os segredos no local apropriado. Se a tarefa é apenas rever ficheiros, não há razão para entregar também acesso de publicação ou informação de clientes que não contribui para essa revisão.
Define quem está responsável pelas alterações enquanto decorre a passagem. Dois agentes a editar o mesmo trabalho sem coordenação podem tornar o estado rapidamente desatualizado. Se existe trabalho em paralelo, delimita a responsabilidade de cada um e garante que o destinatário sabe que partes continuam a mudar antes de basear conclusões nelas.
Valida a compreensão antes de dar a passagem por concluída
Pede ao novo agente que identifique o objetivo, as decisões que condicionam a tarefa e a evidência que consultou. Compara essa leitura com o registo de passagem e resolve divergências relevantes. A transferência fica útil quando permite iniciar o trabalho certo com referências verificadas, e não apenas quando o documento foi enviado ou guardado.
Um primeiro passo limitado pode revelar lacunas sem alterar o projeto: localizar os ficheiros, identificar os estados de aprovação e indicar o teste em falta. Se o agente propõe construir uma funcionalidade excluída ou assume que já houve publicação, há uma diferença de entendimento a corrigir antes de autorizar execução adicional.
Quando encontra inconsistências entre o resumo e os ficheiros, pede que as apresente com evidência. A solução pode ser atualizar a documentação, recuperar uma alteração local ou reconhecer que o trabalho anterior ficou incompleto. Escolhe com base no estado confirmado, evitando obrigar o novo agente a preservar uma descrição que já não corresponde à realidade.
Depois de iniciar a nova tarefa, mantém o registo de decisões e o estado atual junto do projeto. A passagem seguinte será mais simples se o contexto se atualizar durante o trabalho. Mudar de agente torna-se uma escolha operacional possível quando consegues preservar intenção, localizar resultados e verificar o que realmente foi feito, sem depender da memória de uma única conversa.