Agentes colegas de trabalho do Google ganham e-mail, agenda e diretório. Quem faz o offboarding deles?

Em algum lugar no diretório de uma empresa no próximo ano, entre um novo analista e um contratado, haverá uma entrada terminando em @agents.company.com. Ela terá uma agenda, uma pasta do Drive e colegas que compartilham arquivos com ela. Ninguém no RH a terá contratado, e ninguém pode saber como deixá-la ir.

Esse é o cenário que o Google desenhou em 8 de outubro. Em sua keynote do Gemini at Work, Thomas Kurian apresentou o Gemini como “um agente único e universal para o trabalho” que roda na nuvem, continua trabalhando “depois que você fecha o laptop” e divide grandes tarefas entre subagentes. Dois tipos de agente nesse design carregam sua própria identidade.

Agentes colegas de trabalho têm “um papel persistente e definido e presença operacional ao longo de dias, sessões e múltiplas responsabilidades em mudança”. No Workspace, diz o Google, esse agente “recebe sua própria conta do Workspace, incluindo um endereço de e-mail, agenda, Drive e presença no diretório da sua empresa”, e só consegue ver o contexto que as pessoas fornecem a ele.

Subagentes são “agentes temporários, específicos para uma tarefa, cada um com sua própria identidade”, criados na hora para tarefas de várias etapas que podem durar horas ou dias.

Ao redor deles, o Google descreveu os controles: identidades que são “atestadas criptograficamente e governadas como um funcionário”, permissões baseadas em papéis aprovadas por administradores de segurança, propagação de OAuth quando um agente acessa um sistema externo, uma trilha de auditoria “atribuída ao agente em vez de a uma pessoa”, um Agent Sandbox com sua própria fronteira de rede, e um Agent Gateway que inspeciona o tráfego de entrada, saída e entre agentes.

Um aviso antes de planejar em torno de qualquer parte disso. Exceto pelas edições do setor, que o Google diz estarem em preview, a keynote não dá status de lançamento, preços ou disponibilidade regional para essas peças. Leia como uma direção de arquitetura e verifique a documentação do produto antes de comprometer um roadmap com isso.

Dois tipos de agente, dois relógios de identidade

O design é mais útil que seu marketing porque separa dois problemas que as equipes de identidade enterprise já conhecem, e já tratam em lugares diferentes.

Um agente colega de trabalho se comporta como um funcionário. Ele entra, assume responsabilidades, muda de papel e eventualmente sai. Na maioria das empresas, esse ciclo de vida é conduzido a partir de registros de RH e executado por meio de governança de identidade: um joiner recebe uma linha de base, um mover aciona uma revisão de acesso, um leaver é desabilitado no mesmo dia.

Um subagente se comporta como uma carga de trabalho. Ele existe para uma tarefa, deve manter credenciais apenas para essa tarefa, e deve desaparecer com ela. Esse ciclo de vida pertence a equipes de plataforma, credenciais de curta duração e automação, não a revisões trimestrais.

O Google coloca ambos dentro de um produto. Sua organização ainda precisa decidir qual processo é dono de cada um, porque o fornecedor pode emitir a identidade mas não pode decidir quem é responsável por ela.

Quanto tempo vive uma identidade de agente

Uma tarefaMeses

1. SubagenteEmitida por tarefa, deve expirar com ela
2. Tarefa de longa duraçãoContinua rodando por horas ou dias
3. Agente colega de trabalhoE-mail, agenda, Drive, entrada no diretório
4. Colega inativoAinda mantém acesso que ninguém usa

O mover é o caso difícil

A frase do Google “múltiplas responsabilidades em mudança” é a parte para ler duas vezes. Quando uma pessoa muda de papel, a transferência é um evento ao qual alguém pode anexar uma revisão. Quando as responsabilidades de um agente derivam porque colegas continuam entregando novo trabalho a ele, não há evento. As permissões, as pastas compartilhadas e os quatro tipos de memória que o Google descreve (sessão, semântica, procedural, incluindo “habilidades que ele escreve para si mesmo”, e episódica) permanecem, a menos que alguém as remova.

O acúmulo de acessos leva anos com pessoas. Um agente que recebe novas funções toda semana pode acumular a mesma proliferação em um mês.

Há um ponto mais silencioso no design também. Se um agente colega de trabalho só pode ver “o contexto que você ou os membros da sua equipe fornecem”, então compartilhar uma pasta com ele é como ele é provisionado. A maioria das empresas não revisa o compartilhamento no Drive como uma concessão de acesso. Com agentes colegas de trabalho, elas precisarão fazer isso.

O que significa aposentar um agente

O offboarding de uma pessoa é bem ensaiado: desabilitar a conta, transferir os arquivos, revogar os tokens. Um agente colega de trabalho adiciona itens que nenhuma checklist atual tem:

• Memória e habilidades autoescritas. Manter, arquivar ou excluir? Habilidades que um agente escreveu para si mesmo podem codificar como uma equipe realmente trabalha.
• Concessões em outros sistemas. Quando a identidade é propagada por OAuth, tokens e consentimentos vivem nos sistemas externos, não apenas no console do Google.
• A caixa de correio. Fornecedores e clientes podem continuar escrevendo para um agente que não existe mais, e alguém deveria ser dono do que chega.

O próprio TI da Microsoft dá um ponto de referência útil do outro lado do mercado. Seu guia interno, publicado no mesmo dia, define um limite de inatividade de 60 dias para agentes criados no Agent Builder do Microsoft 365 Copilot, com alertas e limpeza automatizada. Regras de inatividade como essa são um piso razoável para agentes colegas de trabalho também.

A atribuição é metade da responsabilidade

Registrar ações sob a própria identidade do agente, em vez da de uma pessoa, corrige um problema real: auditores finalmente podem distinguir a ação de um funcionário da de um agente. Mas “o agente fez isso” é apenas metade do que uma investigação precisa. A outra metade é quem deu ao agente o objetivo e quem aprovou suas permissões. É por isso que argumentamos que agentes precisam do que os funcionários já têm: um ID, e também um gerente, um orçamento e um arquivo.

A mesma lógica se aplica ao Gateway. Uma política como o exemplo do Google, “agentes não podem abrir documentos classificados como Need to Know”, é tão boa quanto a rotulagem por trás dela. Para agentes colegas de trabalho, a cobertura de rótulos se torna cobertura de segurança de agentes.

Nada disso argumenta contra o design do Google. Identidades separadas e atestadas com sua própria trilha de auditoria são o que pediríamos. O trabalho que isso cria fica do lado do cliente: decidir qual ciclo de vida é dono de cada tipo de agente, definir o que aciona uma revisão quando o papel de um agente deriva, e escrever a checklist de desligamento antes que o primeiro agente colega de trabalho receba seu endereço de e-mail.