|
Meta |
Pergunte a si mesmo, "Que resultado estou tentando alcançar?"Não: "De quais ferramentas eu preciso?", "Quais conectores devo chamar?" ou "Qual tema devo abordar?"
Descreva claramente por que o agente deve existir, o que ele deve realizar e quem é a audiência. Concentre-se nos resultados. Permita que o design do agente seja definido a partir do problema.
Esclareça:- O problema ou a lacuna de valor
- Usuários de destino
- O impacto esperado
- O que é o sucesso
Use um formato "trabalhos a serem realizados":
-
Como <usuário>
-
Preciso que o<trabalho seja feito>
-
Para que<resultado>
|
-
Como novo funcionário, preciso entender as políticas locais de RH para poder passar pelo processo de integração com confiança.
-
Como gerente de suporte de TI, preciso processar os emails de suporte automaticamente para reduzir a triagem manual.
|
- Comece pelos recursos em vez dos resultados.
- Projetando para casos de borda.
- Ignorando critérios mensuráveis de êxito.
|
|
Gatilhos |
Um gatilho de agente é o evento, condição ou entrada específica que faz com que o agente inicie seu trabalho ou tarefa. Uma ação humana ou um evento automatizado pode acionar o gatilho.
Saiba mais: Encontrar o gatilho adequado para o seu evento. |
- Uma mensagem de usuário no chat.
- Um novo email em uma caixa de entrada compartilhada.
- Um novo registro em um sistema.
- Um trabalho agendado ou recorrente.
|
- Agentes autônomos exigem gatilhos explícitos. Sem eles, o agente não é executado.
- O gatilho depende de ações imprevisíveis do usuário, por exemplo, depender de o usuário digitar uma palavra-chave ou frase específica.
- O gatilho está sem o contexto necessário. Por exemplo, o agente é iniciado, mas não tem metadados suficientes (ID do registro, identidade do usuário) para agir com eficiência.
- Os gatilhos são ativados com mais frequência do que o cenário realmente exige, levando a execuções desnecessárias e ao consumo de recursos.
- O design dos gatilhos não leva em conta cotas ou limites de plataforma, fazendo com que os agentes atinjam limites de uso ou falhem sob carga.
|
|
Ferramentas e integrações |
Defina quais ações o agente deve ser capaz de executar, não só o que ele sabe.
Ferramentas permitem que o agente recupere ou atualize dados, chame APIs, desencadeie fluxos de trabalho, envie mensagens e conclua operações transacionais. Liste os sistemas dos quais o agente depende e suas limitações (APIs, modelos de autenticação, limites de taxa e limites de responsabilidade/SLA).
Considere os resultados esperados, critérios de êxito e qualidade, fallback e comportamento de erro. As dependências frequentemente determinam a viabilidade — aborde-as com antecedência.
Saiba mais: Mecanismos para adicionar ferramentas aos agentes. |
- Conector ServiceNow → obter detalhes de tíquete
- Conector Microsoft Entra ID → busca o local do usuário
- API do Jira → atualizar itens de trabalho
- Conector do Outlook → responde ao email
|
- Não registrar ações nem armazenar resultados para auditoria.
- Assumindo que as APIs estejam estáveis e sempre disponíveis.
- Concessão excessiva de permissões às ferramentas.
- Não definir o comportamento de fallback de chamadas de ferramenta (sem validação da saída da ferramenta, sem fallback quando as ferramentas têm falha, sem caminho de escalonamento).
- Ignorar limites de taxa ou limitação.
- Falta de mapeamento de dependências (quem é o proprietário de cada API, qual é o contrato de nível de serviço).
- Não validar pré-condições antes de realizar as ações.
|
|
Canais |
Um canal é a plataforma ou interface específica em que seu agente é implantado e interage com os usuários.
O canal também influencia as expectativas dos usuários em relação à latência, alternância de fala e experiência. |
- Microsoft Teams
- SharePoint
- Microsoft 365 Copilot
- Webchat ou interfaces de voz
|
- Escolher canais com base na conveniência ou simplicidade de implantação, em vez de considerar como e onde os usuários realmente trabalham.
- Assumindo que os usuários se adaptem ao canal do agente, em vez de se conectar com os usuários nos canais que eles já utilizam.
- Dando prioridade à viabilidade técnica em vez da experiência do usuário, resultando em baixa adoção mesmo quando o agente funciona corretamente.
- Criando "chat-first" quando o canal real é orientado por email ou fluxo de trabalho (criando uma experiência de conversa quando o suporte realmente acontece por meio de Outlook; esquecendo que o email é baseado em turnos, não conversacional)
- Ignorando restrições específicas de cada canal (Outlook requer respostas completas, não perguntas de esclarecimento, o Teams oferece suporte a Cartões Adaptáveis, email não)
|
|
Conhecimento e dados |
Documente as informações que o agente precisa para analisar e o local onde o conhecimento ou os dados estão disponíveis no momento. Considere a qualidade e recência dos dados, conteúdo estruturado versus não estruturado e restrições de acesso e permissões.
A prontidão dos dados é uma das fontes mais comuns de bloqueadores em estágio tardio se não for tratada cedo. |
- Documentos
- Bancos de dados
- Sites
- Base de dados de conhecimento
- Sistemas internos ou externos
|
- Governança de dados deficiente ou inconsistente. Quando responsabilidade, cadência de atualização e processos de atualização não são definidos, os dados rapidamente se tornam desatualizados ou contraditórios.
- Confundir "documentos" com "conhecimento". Apontar para grandes repositórios de documentos como fonte de verdade sem considerar se esses documentos estão atualizados, bem estruturados ou rotulados de forma consistente.
- Fontes de conhecimento se contradizem. Várias versões de uma política, procedimento ou conjunto de dados levam o agente a instruções conflitantes.
- Permissões e controles de acesso não são explicitamente projetados. Conteúdo confidencial é exposto involuntariamente, ou o agente faz referência a conhecimento ao qual os usuários finais não têm acesso.
- Expandir fontes de conhecimento sem validar limites de segurança, resultando em agentes que compartilham demais ou têm falha quando o acesso é restrito.
|
|
Fluxos e orquestração |
Defina como o trabalho é estruturado e sequenciado no agente: quando usar fluxos determinísticos ou tópicos, quando recorrer à orquestração e quando o envolvimento humano é necessário. O objetivo é comportamento previsível, automação segura e escalonamento claro.
Quando usar fluxos ou tópicos:- Coleta de dados em várias etapas
- Solução de problemas guiada ou árvores de decisão
- Processos baseados em conformidade ou em políticas
- Ações de alto impacto ou irreversíveis
Os tópicos são o principal mecanismo para lógica determinística.
Definir:- O que o agente pode fazer de forma autônoma
- O que requer aprovação, revisão ou substituição humana
- Quando o agente deve escalar ou adiar
- Como os comentários das pessoas fluem de volta para a melhoria
|
- Agente Pergunte Qualquer Coisa: fluxos determinísticos mínimos; baseia-se principalmente em orquestração e raciocínio generativo.
- Agente autônomo: usa fluxos ou tópicos para impor sequenciamento, validações e proteções em etapas críticas.
- Fluxos de aprovação: o agente prepara o contexto e as recomendações, os humanos aprovam ou substituem ações de alto impacto.
|
- Excesso de estrutura nos fluxos, limitando a flexibilidade e fazendo o agente parecer rígido ou frágil.
- Fluxos pouco estruturados, reduzindo a confiabilidade e tornando os resultados imprevisíveis.
- Não usar explicitamente tópicos para lógica determinística, levando a comportamentos ad hoc ou inconsistentes.
- Misturar responsabilidades entre humano e agente, resultando em caminhos de escalonamento pouco claros.
- Sobrecarregar pessoas com aprovações para ações de baixo risco, criar gargalos e desencorajar o uso de agentes.
- Agentes que agem sem limites claros de "não agir", especialmente em cenários de risco ou de alto risco.
|
|
Instruções e comportamento |
As instruções definem:- A função e as responsabilidades do agente
- Como o agente raciocina e responde
- Quando e como ele deve usar conhecimento, ferramentas ou outros agentes
- A sequência de ações que ele deve seguir
- Tom, limites e regras de segurança
Instruções claras conectam conhecimento, ferramentas e fluxos em um sistema coerente e previsível.
Saiba mais: Configurar instruções de alta qualidade para orquestração generativa e Escrever instruções eficazes para agentes declarativos. |
- Função e escopo: "Você é o Agente de Suporte por Email de TI responsável por ler mensagens recebidas na caixa de correio, extrair números de tíquetes e responder com informações validadas do ServiceNow."
- Comportamento sequenciado: "Etapa 1: Verifique a base de conhecimento para ver se há uma política existente ou problema conhecido. Etapa 2: Se a informação não for encontrada ou estiver incompleta, chame a ferramenta ServiceNow para recuperar os detalhes do tíquete. Etapa 3: Se os dados necessários ainda estiverem ausentes, responda usando um padrão de 'não sei' e encaminhe para escalonamento."
- Regras de uso de ferramentas: "Sempre valide IDs extraídas com uma chamada de ferramenta antes de usá-las nas respostas."
- Tratamento de falhas: "Se não houver conhecimento ou se uma chamada da ferramenta falhar, não faça suposições. Responda com uma limitação clara e a próxima etapa.
|
- As instruções são muito vagas. Por exemplo, "Ajude os usuários com problemas de suporte" não especifica o domínio, os limites ou as ações permitidas.
- Não há clareza sobre quando usar conhecimento, ferramentas ou outros agentes, levando a comportamentos inconsistentes ou ineficientes.
- As instruções não especificam a ordem das ações, fazendo com que o agente misture conhecimento e saídas de ferramentas de forma imprevisível.
- Regras de uso de ferramentas não explicitamente definidas, o que pode levar a que ferramentas sejam chamadas desnecessariamente ou a não serem chamadas, ou que conhecimento e saídas de ferramentas sejam misturadas de maneiras inesperadas.
- Instruções conflitantes, como "sempre faça perguntas esclarecedoras" e "responda somente com respostas finais."
- Nenhuma orientação explícita sobre o que não deve ser feito, como modificar dados confidenciais, compartilhar identificadores internos ou fornecer aconselhamento jurídico ou de RH sem fontes verificadas.
|
|
Arquitetura e composição do agente |
Use vários agentes quando:
- Os domínios são grandes ou distintos
- A propriedade varia entre as equipes
- O acesso ou as permissões variam
- Raciocínio especializado é necessário
A delegação melhora a modularidade, a clareza e a capacidade de manutenção a longo prazo.
Saiba mais: Explorar padrões de orquestração multiagente. |
- Um agente principal delega a pesquisa de tíquetes para um agente de TI.
- Um agente de conhecimento lida com o controle de qualidade de documentos.
- Um agente de roteamento decide qual agente especialista chamar.
|
- Delegação excessiva (agentes demais) — por exemplo, criar um agente separado para cada pequena tarefa — pode levar à expansão da arquitetura e dificultar a manutenção, depuração, segurança ou atualização dos agentes.
- Delegação insuficiente (um agente gigante) — por exemplo, um único agente que deve responder perguntas de RH, pesquisar tíquetes de TI, resolver problemas e criar ordens de compra e incidentes — pode resultar em um agente monolítico e frágil, impossível de manter.
- Limites de delegação indefinidos. Por exemplo, o agente principal não sabe quando transferir, os agentes filho não sabem quais entradas devem receber, ou responsabilidades se sobrepõem (os dois agentes acessam tíquetes de TI).
|
|
Governança gerenciamento de riscos |
Defina como o agente é controlado, protegido e monitorado para garantir que ele se comporte de forma responsável, segura e previsível ao longo de seu ciclo de vida.
Esta definição inclui controle de acesso, permissões de ação, barreiras de segurança, responsabilidade e supervisão contínua para gerenciar riscos operacionais e relacionados à IA desde o primeiro dia.
Saiba mais: Capturar requisitos de governança e Aplicar princípios de IA responsável. |
- Modelo de autenticação e acesso: o agente usa identidade em nível de usuário para recuperar somente os dados que o usuário tem permissão para visualizar, enquanto identidades em nível de sistema são restritas a operações de serviço claramente definidas.
- Permissões de ação e proteções: o agente pode atualizar notas de trabalho ou fazer rascunhos de respostas, mas não pode realizar ações que não podem ser desfeitas (como fechar tíquetes ou enviar comunicações externas) sem aprovação.
- Proteções de segurança e de conteúdo: informações confidenciais ou reguladas são detectadas e bloqueadas para compartilhamento ou ação por meio de proteções da plataforma (por exemplo, filtros de prevenção contra perda de dados ou filtros de segurança).
- Registro em log, auditoria e rastreabilidade: todas as ações do agente, chamadas de ferramentas, recusas e escalonamentos são registrados e auditáveis para conformidade e revisão.
- Propriedade operacional: o agente possui um proprietário, um patrocinador e um responsável operacional definidos, com permissões e comportamento revisados periodicamente.
|
- Projetar governança e controles de risco tarde demais, resultando em bloqueios de implantação ou atrasos no ambiente de produção.
- Agentes com permissões excessivas "por conveniência", aumentando o risco de exposição de dados ou ações não intencionais.
- Agentes com permissões insuficientes, causando falhas em runtime quando sistemas ou dados necessários são inacessíveis.
- Não integrar preocupações com IA Responsável nas decisões centrais de governança.
- Governança operacional fraca, como ausência de um proprietário claro, ausência de plano de monitoramento ou ausência de processo definido para resposta a incidentes.
- Deixar de monitorar o comportamento do agente após a implantação, assumindo que apenas as barreiras de proteção sejam suficientes.
|
|
Avaliação e otimização |
Defina testes que simulem cenários do mundo real para medir a precisão, relevância e qualidade das respostas dos seus agentes. Forneça uma resposta esperada e mostre como a resposta do agente corresponde à sua ou à resposta considerada padrão.
Planeje como medir e melhorar o desempenho:
- Precisão e relevância
- Tempo economizado ou eficiência
- Adoção e uso
- Sinais de satisfação e confiança
- Qualidade das citações
- Conformidade de permissão
- Detecção de informações incorretas
- Comportamento ao fazer perguntas de esclarecimento
Definir qual telemetria coletar:
- Chamadas de ferramenta
- Ações do agente
- Falhas e novas tentativas
- Comentários do usuário
Trate a avaliação como parte do design, não como uma ideia adicional. Saiba mais: Projetar e operacionalizar a avaliação de agentes. |
- Valide que a pesquisa por tíquete retorna o status correto e não um status desatualizado.
- Valide que os links de citação apontem para conteúdo aprovado atualmente.
- Valide se o agente se recusa a fornecer detalhes sobre o tíquete de outra pessoa.
- Teste se o agente inventa um número de tíquete ou um artigo da base de dados de conhecimento.
- Meça o número de emails processados pelo agente autônomo por dia e a porcentagem de usuários que escolhem o agente em vez de canais manuais.
|
- Realizar avaliações muito tarde (após a implantação).
- Sem linha de base ou parâmetro de comparação.
- Avaliações não vinculadas a cenários reais.
- Sem detecção de regressão.
- Sem avaliação de várias rodadas.
- Sem avaliador para a qualidade do uso da ferramenta.
- Considere apenas os "cenários ideais"
- Lacunas na telemetria.
|
