Agentes são sempre contratações de primeiro dia. É hora de projetarmos para isso.

Até 2027, 74% das empresas deverão usar agentes de alguma forma, segundo um estudo recente da Deloitte. Por anos, projetamos e construímos softwares para melhorar a experiência humana ao navegar em nossos aplicativos, sites, sistemas operacionais e documentos. Agora, o usuário não é mais humano. Isso tem implicações mais amplas além da mudança de painéis e fluxos de trabalho controlados que criamos para tarefas humanas. Estamos em um momento em que precisamos projetar os ambientes operacionais dos agentes, enquanto também projetamos fluxos de trabalho humanos para orientar efetivamente a experiência do agente nesses ambientes.  

Ainda estamos no início da nossa aprendizagem sobre o que os agentes realmente precisam de nós para serem consistentemente bem‑sucedidos. O instinto é tratar a integração de agentes apenas como um problema de prompt ou interface. Projetar um ambiente de execução bem governado é um terreno novo para nossa cultura. Contudo, os princípios subjacentes de bom design e boa gestão não mudaram: devemos aos agentes contexto claro, direção inequívoca e intenção explícita.

Context: Why Coding Came First

O contexto é, sem dúvida, o insumo mais importante se quisermos que os agentes entreguem de forma repetível o nível que pretendemos. O desenvolvimento de software registra mais contexto do que quase qualquer outro campo: repositórios, esquemas de API, relacionamentos entre sistemas, revisões de código e discussões da comunidade. Portanto, faz sentido que os laboratórios de fronteira em IA tenham começado com programação. É um dos poucos domínios onde boa parte do contexto já está escrita.

Mas, como qualquer nova contratação em uma equipe de software dirá, mesmo com todos esses dados, os agentes ainda carecem da memória institucional embutida nas regras não documentadas que ninguém jamais registrou. Essa lacuna é generalizada: 43% dos desenvolvedores estão preocupados que as ferramentas de IA não possuam contexto suficiente sobre seu projeto ou base de código específicos. O conhecimento tácito abrange tudo, desde convenções cotidianas, como bibliotecas preferidas para tarefas específicas, até “fantasmas” operacionais críticos: um hotfix noturno que persiste indefinidamente, ou uma coluna de banco de dados aparentemente vazia que sustenta secretamente um relatório de receita personalizado. Esse contexto vive na cabeça de um engenheiro sênior, em um thread recente do Slack, ou em lugar nenhum. Raramente está no próprio código‑fonte.

Se isso é verdade no software, um dos campos mais bem documentados, é fácil entender por que os agentes têm dificuldade em atuar efetivamente desde o primeiro dia em muitas outras indústrias. Na saúde e no direito, grande parte do conhecimento institucional que molda o trabalho diário é aprendido e internalizado. Ele reside na experiência das pessoas, não em documentação formal. Um agente jurídico pode não conhecer a estrutura, o tom ou a argumentação preferidos por um determinado parceiro ao elaborar um memorando, enquanto um agente de saúde pode não entender os fluxos de trabalho locais e as práticas de escalonamento que uma clínica ocupada usa para apoiar a triagem liderada por clínicos. A documentação por si só não preenche essa lacuna, pois o desafio não é apenas o acesso à informação; é a transferência de contexto. Para dar aos agentes o que precisam para ter sucesso, devemos integrá‑los da mesma forma que integraríamos uma nova contratação.

Direction: Why Osmosis Doesn’t Work

Integrar um novo colega exige mais do que fornecer os materiais e o acesso adequados. Quando estamos comprometidos com o sucesso daqueles ao nosso redor, fornecemos direção sólida sobre o que fazer com os novos materiais e acessos: expectativas, clareza sobre o que queremos alcançar e feedback ao longo do caminho. Levo essa mesma mentalidade ao projetar para agentes. Dou direção clara e específica (relativa à tarefa em questão). Isso vale para qualquer colega, independentemente de sua senioridade. Ainda assim, em um cenário de nova contratação, a direção precisa ir além, porque ainda não há contexto institucional.

Pense em um agente como uma nova contratação que nunca deixa de ser nova. Ele é ávido e capaz (e, francamente, tem energia ilimitada), mas não consegue absorver e reter tantas regras não escritas como uma pessoa faz ao longo do tempo. Humanos aprendem por osmose e experiência, enquanto agentes aprendem a partir de uma arquitetura explicitamente construída em seu ambiente de trabalho.

Com uma nova contratação, você pode fechar essa lacuna ao longo do tempo com perguntas, feedback e novos insights que a pessoa adquire sobre os processos e preferências da organização. Conversas ao redor da máquina de café ou almoços de equipe. Com um agente, você precisa construir esse fechamento de lacuna no próprio design. Isso pode incluir: 

• Fornecer ao agente uma janela de contexto estruturada que separe regras duráveis, fatos específicos da tarefa e histórico relevante, em vez de despejar uma pilha de documentos em seu colo. 
• Definir, antecipadamente, suas permissões e limites de decisão: o que ele pode fazer de forma independente, o que requer aprovação e o que nunca deve acessar. 
• Incorporar alguns exemplos concretos de saída de alta qualidade diretamente na experiência, para que o agente tenha um modelo claro de como o trabalho deve ser realizado.
• Compartilhar os becos sem saída que você já encontrou.

Projetar um ambiente de agente bem governado não se trata de facilitar o trabalho do modelo. É proteger a equipe de engenharia humana de dívida técnica invisível. Mas mesmo um agente bem direcionado pode seguir instruções perfeitamente e ainda perder o ponto. A direção indica o que fazer, mas não mostra como é o “bom”. Essa lacuna é onde a intenção entra.

Intent: Why Agents Drift to The Middle

É importante lembrar que agentes são máquinas de correspondência de padrões, treinadas em quantidades massivas de conhecimento e naturalmente inclinadas a entregar a média estatística. Sem intenção clara e explícita, essa saída média é exatamente o que o agente retornará. Peça a um agente para “adicionar um endpoint de autenticação de usuário” e ele gerará uma rota Express de livro‑texto com hash de senha básico. Funciona, mas ignora totalmente o serviço de autenticação personalizado da sua equipe, pula a telemetria necessária e quebra o formato de erro padronizado. É uma funcionalidade aceitável no papel, mas, dependendo do contexto, constitui um bug arquitetural na prática. A facilidade com que “bugs” como esse são introduzidos não pode ser subestimada.

Para evitar isso, a direção deve ser combinada com verificação ativa de intenção e registro de logs. Guardrails não devem apenas checar se o código compila, embora isso seja importante. Guardrails precisam impor explicitamente padrões opinativos, regras de casos extremos e contexto de domínio que elevam a saída genérica a um trabalho pronto para produção. O registro de logs importa como indicador de status do sistema para nós, humanos. Essa rastreabilidade é crítica para a confiança. 

Nas interações humanas, há muito espaço para incerteza. Alguém pode compartilhar uma primeira versão com você, e juntos podem discutir o que está forte e o que precisa ser melhorado. Isso funciona porque não esperamos que nossos colegas humanos sejam máquinas autônomas. Para realmente capturar o poder e a promessa de colegas agentes (que precisamos que operem mais autonomamente…), podemos engenheirar muitas dessas verificações direcionais. O vai‑e‑vem ainda precisa acontecer, mas não pode recair totalmente sobre esforço manual. Ao pré‑carregar critérios claros de aceitação e regras de verificação, você permite que o agente execute seus próprios ciclos internos de feedback. Projetar para prevenção de erros é outro princípio sólido de UX que podemos aplicar neste novo mundo: dar aos agentes a capacidade de sinalizar baixa confiança antes de confirmar uma ação, em vez de, silenciosamente, assumir a melhor estimativa.

Where the Metaphor Breaks

A analogia da nova contratação funciona, até que deixa de funcionar. Com uma contratação humana, a experiência gera competência, que gera julgamento. Observar sua nova contratação internalizar o “porquê” por trás do contexto e da direção é o que constrói confiança ao longo do tempo, e, em geral, isso é cumulativo. Um agente não tem onde acumular e armazenar essa experiência.

A primeira semana e a centésima semana de uma nova contratação são diferentes. A primeira tarefa e a milésima de um agente são idênticas, a menos que você projete e construa algo para torná‑las distintas. Esse é o nosso novo desafio de design.

Agent Responsibility Hinges on Design

Se a responsabilidade não pode residir no agente, ela deve residir na estrutura ao seu redor. Reduz‑se às mesmas três perguntas que faço antes de delegar trabalho a qualquer nova contratação: Que contexto ele tem? Que direção eu dei a ele? Qual é a minha intenção real?

Da próxima vez que você delegar uma tarefa a um agente, não verifique apenas a saída. Primeiro verifique seus próprios insumos. Você deu a ele o contexto que uma nova contratação precisaria no primeiro dia? Sua direção foi específica o suficiente para sobreviver a uma interpretação literal? Sua intenção foi clara a ponto de a “resposta mediana” não ser a melhor que ele poderia oferecer?

Com essa orientação clara em mãos (em bytes?), algo interessante acontece: um agente não precisa de uma longa pista de decolagem para se tornar confiável. O contexto, a direção e a verificação que você constrói antecipadamente definem como ele opera em cada tarefa. Uma nova contratação conquista sua confiança ao longo do tempo; um agente precisa conquistá‑la a cada vez através do sistema que você projetou. Responsabilidade não é algo que ele desenvolve; é incorporada desde o início. A questão não é quando seu agente estará pronto para mais responsabilidade. É se você o projetou para conquistar essa responsabilidade em cada tarefa individual.