|
Objetivo |
Pergunte a si mesmo: "Que resultado estou a tentar alcançar?"Não: "De que ferramentas preciso?", "Que conectores devo utilizar?" ou "Que tópico devo criar?"
Descreva claramente por que motivo o agente deve existir, o que deve realizar e quem é a audiência de destino. Concentre-se nos resultados. Deixe que o design do agente decorra do problema.
Esclareça:- O problema ou a lacuna de valor
- Visar utilizadores
- O impacto esperado
- O que caracteriza o sucesso
Utilize um formato Tarefas a Concluir:
-
Como<utilizador>
-
Preciso de<tarefa a efetuar>
-
Para que<resultado>
|
-
Como novo colaborador, preciso de compreender as políticas locais de Recursos Humanos para que possa realizar a integração com confiança.
-
Como gestor de suporte de TI, preciso de processar e-mails de suporte automaticamente para reduzir a triagem manual.
|
- Começar pelas funcionalidades em vez dos resultados.
- Conceber para casos extremos.
- Ignorar critérios de sucesso mensuráveis.
|
|
Acionadores |
Um acionador de agente é o evento, a condição ou a entrada específica que sinaliza ao agente que deve iniciar o seu trabalho ou a sua tarefa. Uma ação humana ou um evento automatizado pode iniciar o acionador.
Saiba mais em: Encontrar o acionador que se adequa ao seu evento. |
- Uma mensagem de utilizador no chat.
- Um novo e-mail numa caixa de entrada partilhada.
- Um novo registo num sistema.
- Uma tarefa agendada ou recorrente.
|
- Agentes autónomos requerem acionadores explícitos. Sem eles, o agente não é executado.
- O acionador depende de comportamentos imprevisíveis do utilizador, por exemplo, confiar que o utilizador escreva uma palavra-chave ou frase específica.
- O acionador não tem o contexto necessário, por exemplo, o agente inicia mas não tem metadados suficientes (ID de registo, identidade de utilizador) para atuar de forma eficaz.
- Os acionadores ativam-se com mais frequência do que o cenário realmente exige, levando a execuções desnecessárias e ao consumo de recursos.
- A conceção do acionador não tem em consideração as quotas ou limites da plataforma, fazendo com que os agentes atinjam os limiares de utilização ou falhem sob carga.
|
|
Ferramentas e integrações |
Defina quais as ações que o agente deve ser capaz de realizar, e não apenas o que sabe.
As ferramentas permitem ao agente obter ou atualizar dados, chamar APIs, acionar fluxos de trabalho, enviar mensagens e concluir operações transacionais. Liste os sistemas de que o agente depende e as suas limitações (APIs, modelos de autenticação, limites de taxa e limites de propriedade/SLA).
Considere os resultados esperados, os critérios de sucesso e qualidade, o comportamento de contingência e de erro. As dependências frequentemente determinam a viabilidade—aborde-as cedo.
Saiba mais em: Mecanismos para adicionar ferramentas aos agentes. |
- Conector do ServiceNow → obter detalhes do pedido de suporte
- Conector do Microsoft Entra ID → obter a localização do utilizador
- API do Jira → atualizar itens de trabalho
- Conector do Outlook → responder a e-mails
|
- Não registar ações nem armazenar as saídas para auditoria.
- Assumir que as APIs são estáveis e estão sempre disponíveis.
- Ferramentas com permissões excessivas.
- Não definir o comportamento de contingência das chamadas de ferramenta (sem validação da saída da ferramenta, sem contingência quando as ferramentas falham, sem caminho de escalamento).
- Ignorar limites de taxa ou limitação.
- Mapeamento de dependências em falta (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 ações.
|
|
Canais |
Um canal é a plataforma ou interface específica onde o agente é implementado e interage com os utilizadores.
O canal também influencia as expectativas dos utilizadores em relação à latência, alternância de turnos e experiência. |
- Microsoft Teams
- SharePoint
- Microsoft 365 Copilot
- Interfaces de Webchat ou voz
|
- Escolher canais com base na conveniência ou simplicidade de implementação, em vez de como e onde os utilizadores realmente trabalham.
- Partindo do princípio de que os utilizadores se adaptam ao canal do agente, em vez de ir ao encontro dos utilizadores onde já estão.
- Priorizar a viabilidade técnica em detrimento da experiência de utilizador, resultando em baixa adoção mesmo quando o agente funciona corretamente.
- Conceção centrada em chat quando o canal real está orientado para e-mail ou fluxo de trabalho (criar uma experiência de utilizador conversacional quando o suporte realmente ocorre via Outlook; esquecendo que o e-mail é baseado em turnos, não em conversação)
- Ignorar as restrições específicas do canal (o Outlook requer respostas completas, não perguntas de esclarecimento; o Teams suporta Cartões Adaptativos, o e-mail não)
|
|
Conhecimento e dados |
Documente a informação que o agente precisa de analisar e a localização onde o conhecimento ou os dados estão atualmente disponíveis. Considere a qualidade e atualidade dos dados, o conteúdo estruturado versus não estruturado, e os limites de acesso e permissões.
A preparação dos dados é uma das origens mais comuns de bloqueadores em fases tardias, se não for tratada antecipadamente. |
- Documentos
- Bases de dados
- Sites
- Base de dados de conhecimento
- Sistemas internos ou externos
|
- Governação de dados deficiente ou inconsistente. Quando a propriedade, a cadência de atualização e os processos de atualização não estã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 etiquetados de forma consistente.
- As fontes de conhecimento contradizem-se. Várias versões de uma política, procedimento ou conjunto de dados levam o agente a instruções conflitantes.
- As permissões e os controlos de acesso não são concebidos de forma explícita. Os conteúdos confidenciais são expostos de forma involuntária, ou o agente faz referência a conhecimento a que os utilizadores finais não têm acesso.
- Expandir as fontes de conhecimento sem validar os limites de segurança resulta em agentes que partilham informação em excesso ou falham quando o acesso é restringido.
|
|
Fluxos e orquestração |
Defina como o trabalho é organizado e sequenciado dentro do agente: quando usar fluxos ou tópicos deterministas, quando recorrer à orquestração e quando é necessária a intervenção humana. O objetivo é o comportamento previsível, a automatização segura e um processo de escalamento claro.
Quando usar fluxos ou tópicos:- Recolha de dados em vários passos
- Resolução de problemas guiada ou árvores de decisão
- Processos orientados por conformidade ou políticas
- Ações de alto impacto ou irreversíveis
Os tópicos são o principal mecanismo para lógica determinista.
Defina:- O que o agente pode fazer de forma autónoma
- O que requer aprovação, revisão ou sobreposição humana
- Quando o agente tem de escalar ou adiar
- Como o feedback humano contribui para a melhoria
|
- Agente Pergunte-me qualquer coisa: Fluxos deterministas mínimos; baseia-se principalmente na orquestração e no raciocínio generativo.
- Agente autónomo: Utiliza fluxos ou tópicos para impor a sequência, validações e verificadores de integridade em passos críticos.
- Fluxos de trabalho de aprovação: O agente prepara o contexto e as recomendações; Os humanos aprovam ou sobrepõem-se a ações de alto impacto.
|
- Estruturação excessiva dos fluxos, limitando a flexibilidade e fazendo com que o agente pareça rígido ou propenso a falhas.
- Falta de estrutura nos fluxos, reduzindo a fiabilidade e tornando os resultados imprevisíveis.
- Não utilizar explicitamente tópicos para lógica determinista, levando a comportamentos ad hoc ou inconsistentes.
- Confundir responsabilidades entre humanos e agentes, resultando em caminhos de escalamento pouco claros.
- Sobrecarregar os humanos com aprovações para ações de baixo risco, criando estrangulamentos e desincentivando a utilização de agentes.
- Agentes a agir sem limites claros de "não agir", especialmente em cenários extremos ou de risco elevado.
|
|
Instruções e comportamento |
As instruções definem:- As responsabilidades e a função do agente
- Como raciocina e responde
- Quando e como deve utilizar conhecimento, ferramentas ou outros agentes
- A sequência de ações que deve seguir
- Tom, limites e regras de segurança
Instruções claras ligam conhecimento, ferramentas e fluxos num sistema coerente e previsível.
Saiba mais em: Configurar instruções de alta qualidade para orquestração generativa e Escrever instruções eficazes para agentes declarativos. |
- Função e âmbito: "És o Agente de Suporte de E-mail de TI responsável por ler as mensagens recebidas na caixa de correio, extrair os números dos pedidos de suporte e responder com informações validadas do ServiceNow."
- Comportamento sequenciado: "Passo 1: Verifica a base de dados de conhecimento para identificar uma política existente ou problema conhecido. Passo 2: Se a informação não for encontrada ou estiver incompleta, acede à ferramenta ServiceNow para obter os detalhes do pedido de suporte. Passo 3: Se os dados necessários ainda estiverem em falta, responde utilizando um padrão "não sei" e escala."
- Regras de utilização de ferramentas: "Valida sempre os IDs extraídos com uma chamada de ferramenta antes de os utilizar nas respostas."
- Gestão de falhas: "Se o conhecimento estiver em falta ou se uma chamada de ferramenta falhar, não tentes adivinhar. Responde com uma limitação clara e o passo seguinte."
|
- As instruções são demasiado vagas. Por exemplo, "Ajudar utilizadores com problemas de suporte" não especifica domínio, limites ou ações permitidas.
- Não há clareza sobre quando usar conhecimento, ferramentas ou outros agentes, o que leva a comportamentos inconsistentes ou ineficientes.
- As instruções não definem a sequência de ações, levando o agente a misturar conhecimento e saídas de ferramentas de formas imprevisíveis.
- As regras de utilização de ferramentas não estão explicitamente definidas, o que pode levar a que sejam chamadas desnecessariamente ou não sejam chamadas de todo, ou que os resultados de conhecimento e de ferramentas se misturem de formas inesperadas.
- Instruções contraditórias, tais como "faz sempre perguntas de esclarecimento" e "responde apenas com respostas definitivas."
- Não existe orientação explícita sobre o que "não se deve fazer", como modificar dados confidenciais, partilhar identificadores internos ou fornecer aconselhamento jurídico ou de RH sem fontes verificadas.
|
|
Arquitetura e composição do agente |
Utilize vários agentes quando:
- Os domínios são grandes ou distintos
- A propriedade varia entre equipas
- O acesso ou as permissões variam
- É necessário raciocínio especializado
A delegação melhora a modularidade, clareza e manutenção a longo prazo.
Saiba mais em: Explorar padrões de orquestração multiagente. |
- Um agente principal delega a pesquisa de pedidos de suporte a um agente de TI.
- Um agente de conhecimento processa a verificação de qualidade dos documentos.
- Um agente de encaminhamento decide qual o agente especialista a chamar.
|
- A delegação excessiva (demasiados agentes)—por exemplo, criar um agente separado para cada pequena tarefa—pode levar à proliferação da arquitetura e dificultar a manutenção, a depuração, a segurança ou a atualização dos agentes.
- A subdelegação (um agente gigante)—por exemplo, um único agente que se espera que responda a perguntas de RH, consulte pedidos de suporte de TI, processe resolução de problemas e crie notas de encomenda e incidentes—pode resultar num agente monolítico e frágil, impossível de manter.
- Limites de delegação indefinidos. Por exemplo, o agente principal não sabe quando deve efetuar a passagem de informações, os agentes de elemento subordinado não sabem que entradas devem esperar, ou há sobreposição de responsabilidades (dois agentes a pesquisarem pedidos de suporte de TI).
|
|
Governação e gestão de risco |
Defina como o agente é governado, protegido e monitorizado para garantir que se comporta de forma responsável, segura e previsível ao longo do seu ciclo de vida.
Esta definição inclui controlo de acesso, permissões de ação, verificadores de integridade de segurança, responsabilização e supervisão contínua para gerir riscos operacionais e relacionados com IA desde o primeiro dia.
Saiba mais em: Capturar os requisitos de governação e Aplicar princípios de IA responsável. |
- Modelo de autenticação e acesso: O agente utiliza a identidade ao nível do utilizador para obter apenas os dados que o utilizador tem permissão para ver, enquanto as identidades ao nível do sistema são restringidas a operações de serviço claramente definidas.
- Permissões e verificadores de integridade de ações: o agente pode atualizar notas de trabalho ou redigir respostas, mas não pode executar ações irreversíveis (como fechar pedidos de suporte ou enviar comunicações externas) sem aprovação.
- Segurança e proteções de conteúdo: Informação confidencial ou regulada é detetada e bloqueada de ser partilhada ou utilizada através das proteções da plataforma (por exemplo, prevenção de perda de dados ou filtros de segurança).
- Registo, auditoria e rastreabilidade: Todas as ações do agente, chamadas de ferramentas, recusas e escalamentos são registadas e auditáveis para efeitos de conformidade e revisão.
- Propriedade operacional: O agente tem um proprietário, patrocinador e responsável operacional definidos, com permissões e comportamento revistos periodicamente.
|
- Conceber controlos de governação e de risco demasiado tarde leva a implementações bloqueadas ou atrasos na entrada em produção.
- Conceder permissões excessivas aos agentes "por conveniência", aumentando o risco de exposição de dados ou ações não intencionais.
- Conceder permissões insuficientes aos agentes, levando a falhas em runtime quando os sistemas ou dados necessários estão inacessíveis.
- Não integrar preocupações de IA responsável em decisões fundamentais de governação.
- Governação operacional fraca, como a falta de um proprietário claro, nenhum plano de monitorização ou nenhum processo definido para resposta a incidentes.
- Falhar ao monitorizar o comportamento do agente após a implementação, assumindo que os verificadores de integridade por si só são suficientes.
|
|
Avaliação e otimização |
Defina testes que simulem cenários reais para medir a precisão, a relevância e a qualidade das respostas dos seus agentes. Forneça uma resposta esperada e mostre como a resposta do agente corresponde à sua resposta ou à resposta mais padrão.
Planeie como medir e melhorar o desempenho:
- Precisão e relevância
- Tempo poupado ou eficiência
- Adoção e utilização
- Sinais de satisfação e confiança
- Qualidade das citações
- Conformidade com permissões
- Deteção de informação incorreta
- Comportamento das perguntas de esclarecimento
Defina que telemetria recolher:
- Chamadas de ferramentas
- Ações do agente
- Falhas e novas tentativas
- Comentários de utilizadores
Considere a avaliação como parte do design, não como algo secundário. Saiba mais em: Conceber e operacionalizar a avaliação de agentes. |
- Validar que a pesquisa de pedidos de suporte devolve o estado correto e não um estado desatualizado.
- Valide que as ligações de citação apontam para conteúdo aprovado e atual.
- Valide que o agente se recusa a fornecer detalhes sobre o pedido de suporte de outra pessoa.
- Verifique se o agente inventa um número de pedido de suporte ou um artigo BDC.
- Meça o número de e-mails processados pelo agente autónomo por dia e a percentagem de utilizadores que optam pelo agente em vez dos canais manuais.
|
- Executar avaliações demasiado tarde (após a implementação).
- Sem linha de base ou referência.
- Avaliações não ligadas a cenários reais.
- Sem deteção de regressão.
- Sem avaliação multiturno.
- Sem avaliador para a qualidade da utilização de ferramentas.
- Verificar apenas "caminhos felizes".
- Lacunas de telemetria.
|
