Da Engenharia de Prompts à Arquitetura de Agentes: Guia Completo

Engenharia de Agentes de IA: LLMs, Skills e Voz

A inteligência artificial está deixando de ser apenas uma ferramenta que responde perguntas para se transformar em uma infraestrutura capaz de executar tarefas, utilizar ferramentas, consultar documentos e coordenar processos inteiros. Essa transformação exige uma mudança profunda na maneira como desenvolvedores, empresas e profissionais pensam a construção de aplicações inteligentes.

Durante a primeira fase de popularização dos grandes modelos de linguagem (LLMs), boa parte da atenção estava concentrada na engenharia de prompts. O objetivo era descobrir como escrever instruções melhores para obter respostas mais precisas, criativas e contextualizadas.

Essa habilidade continua importante. Entretanto, quando uma aplicação precisa consultar bancos de dados, executar códigos, interpretar documentos, utilizar APIs, controlar permissões e manter processos complexos, um prompt isolado deixa de ser uma arquitetura suficiente.

É nesse cenário que surge uma nova abordagem: a engenharia de sistemas de IA, que combina instruções modulares, Agent Skills, ferramentas executáveis, orquestração, avaliações e interfaces multimodais.

A arquitetura dos agentes de IA

A ideia central deste guia: prompts definem orientações, skills organizam conhecimentos operacionais, ferramentas executam operações, agentes coordenam tarefas e sistemas tradicionais controlam permissões e estados. A confiabilidade depende da integração correta dessas camadas.

Este artigo apresenta os fundamentos dessa transformação, desde a criação de fábricas de prompts até a construção de assistentes especializados, integrações corporativas e interfaces de voz.

📑 Sumário do artigo — clique para expandir

1. Da engenharia de prompts à engenharia de sistemas de IA
2. Metaprompting e fábricas de prompts
3. Arquitetura de Agent Skills e padrão SKILL.md
4. Divulgação progressiva e economia de contexto
5. O protocolo @skills e a organização das habilidades
6. Modularização e Prompt Chaining
7. Evidências experimentais da modularização
8. Avaliação, testes e qualidade das skills
9. Interfaces de voz e Amazon Alexa Skills Kit
10. Assistentes especializados, RAG e APIs
11. Segurança e governança corporativa
12. Como construir uma arquitetura de agente na prática
13. O futuro da engenharia de agentes
14. Perguntas frequentes
15. Conclusão
16. Fontes e referências

1. Da engenharia de prompts à engenharia de sistemas de IA

Um prompt é uma instrução enviada a um modelo de inteligência artificial. Ele pode definir uma tarefa, fornecer contexto, estabelecer restrições e determinar o formato esperado da resposta.

Em aplicações simples, essa estrutura pode ser suficiente. Um usuário pergunta, o modelo interpreta e responde. Mas imagine um assistente corporativo responsável por verificar o estoque, consultar fornecedores, atualizar um sistema de vendas e enviar um relatório.

Esse processo envolve diferentes operações. Algumas dependem de interpretação linguística; outras exigem cálculos exatos, consultas estruturadas e alterações em sistemas externos.

Concentrar todas essas responsabilidades em uma única instrução cria dificuldades de manutenção, controle e avaliação.

O problema dos prompts monolíticos

Um prompt monolítico reúne praticamente todas as instruções de uma aplicação em um único bloco. Pode conter identidade do assistente, regras de negócio, exemplos, exceções, procedimentos, formatos e condições de execução.

Embora essa abordagem seja útil para protótipos, ela pode apresentar problemas quando a aplicação cresce:

• Complexidade: encontrar uma regra específica em instruções extensas torna-se mais difícil.
• Manutenção: uma alteração pode produzir efeitos inesperados em outras partes do comportamento.
• Contexto: informações irrelevantes para determinada tarefa disputam espaço com os dados realmente necessários.
• Testabilidade: torna-se mais difícil identificar qual instrução provocou determinado erro.
• Escalabilidade: novas funcionalidades aumentam a complexidade do conjunto.

Isso não significa que prompts longos sejam sempre inadequados. Uma aplicação pode precisar de instruções extensas e bem documentadas. O problema aparece quando o tamanho substitui uma arquitetura organizada.

O novo paradigma de engenharia

A abordagem modular separa responsabilidades. O modelo recebe somente as orientações necessárias para a etapa atual, enquanto componentes tradicionais cuidam de operações que exigem previsibilidade.

Dimensão	Abordagem monolítica	Arquitetura modular
Instruções	Um grande bloco centralizado.	Módulos especializados.
Contexto	Grande quantidade de informações permanentes.	Recuperação conforme a necessidade.
Lógica	Regras e decisões misturadas à linguagem.	Separação entre código e interpretação.
Manutenção	Alterações podem afetar diversas funções.	Componentes isolados e versionados.
Testes	Inspeção geral das respostas.	Testes por módulo e por cenário.
Governança	Controle concentrado nas instruções.	Permissões, validações e registros de execução.

A transformação mais importante não está em abandonar a engenharia de prompts, mas em colocá-la dentro de uma arquitetura de software mais ampla.

2. Metaprompting: a criação de fábricas de prompts e instruções

Uma evolução interessante da engenharia de prompts acontece quando o desenvolvedor deixa de produzir diretamente todas as instruções e passa a construir um sistema capaz de criá-las, revisá-las e padronizá-las.

Esse processo é conhecido como metaprompting.

Em vez de pedir a um modelo que execute imediatamente uma tarefa, o usuário solicita que ele analise o objetivo, identifique os requisitos e produza uma instrução especializada para aquela atividade.

2.1. O que é uma fábrica de prompts?

Uma fábrica de prompts é um ambiente organizado para desenvolver, documentar, testar e manter instruções reutilizáveis.

Ela pode utilizar modelos de linguagem, documentos técnicos, exemplos validados e critérios de qualidade para produzir instruções consistentes.

Uma implementação pode ser organizada em três camadas:

1. Conhecimento técnico: documentação oficial, manuais, padrões de desenvolvimento e estudos relevantes.
2. Metodologia: estruturas de instrução, modelos de tarefas e regras de qualidade.
3. Biblioteca operacional: prompts, exemplos e procedimentos já testados.

Ferramentas de pesquisa documental, como o NotebookLM, podem ajudar a trabalhar com conjuntos de documentos fornecidos pelo usuário. Entretanto, trabalhar com fontes delimitadas não significa que todos os documentos estejam corretos ou atualizados. A qualidade do resultado continua dependendo da seleção e da verificação das fontes.

2.2. O metaprompt como instrução central

O metaprompt estabelece como uma solicitação deverá ser transformada em uma instrução final.

Uma estrutura útil possui três entregáveis:

• Prompt final: instrução completa, pronta para utilização.
• Justificativa arquitetural: explicação das escolhas de estrutura, contexto, restrições e formato.
• Variáveis configuráveis: elementos que podem ser modificados sem comprometer o funcionamento geral.

Veja um exemplo de metaprompt para criar instruções profissionais:

Você é um arquiteto de instruções para sistemas
baseados em modelos de linguagem.

Sua tarefa é transformar solicitações em prompts
estruturados, claros, verificáveis e reutilizáveis.

Para cada solicitação:

1. Identifique o objetivo principal.
2. Determine o contexto necessário.
3. Defina as entradas esperadas.
4. Estabeleça as restrições.
5. Determine o formato de saída.
6. Identifique situações de falha.
7. Defina critérios de validação.

Entregue:

A. Prompt final.
B. Justificativa das decisões.
C. Variáveis configuráveis.
D. Casos de teste recomendados.

Não invente informações ausentes.
Identifique ambiguidades e requisitos não atendidos.

2.3. A importância das fontes e do contexto fechado

Um sistema que produz instruções técnicas não deve depender exclusivamente de respostas genéricas do modelo.

Documentações oficiais, especificações, exemplos de implementação e registros de testes ajudam a criar uma base mais consistente.

Entretanto, existe uma distinção importante: um sistema alimentado com documentos não passa automaticamente a conhecer toda a verdade contida neles. Ele ainda pode interpretar incorretamente informações, ignorar limitações ou combinar trechos incompatíveis.

Por isso, uma fábrica de prompts precisa de rastreabilidade: cada regra importante deve possuir uma origem identificável e um critério de validação.

3. Agent Skills: a anatomia das habilidades para agentes

Uma das mudanças mais importantes no desenvolvimento de agentes é a utilização de habilidades especializadas, conhecidas como Agent Skills.

Uma skill é um pacote organizado de instruções procedurais, materiais de referência e, quando necessário, scripts executáveis. Sua finalidade é ensinar ao agente como conduzir determinado tipo de trabalho.

O padrão ganhou destaque no ecossistema da Anthropic e aparece em ferramentas e ambientes que adotam estruturas semelhantes de habilidades para agentes.

A documentação oficial descreve uma organização baseada em um diretório que contém um arquivo principal chamado SKILL.md, acompanhado opcionalmente de arquivos de apoio e código.

3.1. Agentes, ferramentas, regras e skills: qual é a diferença?

Esses quatro conceitos são frequentemente confundidos, mas possuem responsabilidades distintas.

Componente	Responsabilidade	Exemplo
Agente	Coordena o processo e decide os próximos passos.	Assistente que organiza uma análise financeira.
Tool	Executa uma operação disponível ao sistema.	Consultar uma API ou ler um arquivo.
Rule	Define restrições e comportamentos transversais.	Não alterar arquivos sem autorização.
Skill	Ensina um procedimento especializado.	Executar uma revisão técnica de código.

Uma forma simples de compreender a relação é:

Agentes coordenam. Ferramentas executam. Regras restringem. Skills orientam.

Uma skill, portanto, não precisa ser um agente independente. Ela pode ser uma capacidade especializada utilizada por diferentes agentes, desde que o ambiente ofereça compatibilidade com o formato.

3.2. Estrutura de diretórios de uma skill

Uma organização básica pode ser representada assim:

analise-de-dados/
│
├── SKILL.md
│
├── scripts/
│   ├── validar_dados.py
│   └── gerar_relatorio.py
│
├── references/
│   ├── metodologia.md
│   └── esquema-dados.md
│
└── assets/
    ├── modelo-relatorio.md
    └── exemplo.csv

Cada diretório possui uma função:

• SKILL.md: arquivo principal com metadados e instruções.
• scripts/: códigos auxiliares para operações determinísticas.
• references/: documentação técnica e informações complementares.
• assets/: modelos, arquivos de exemplo e recursos estáticos.

Somente o arquivo SKILL.md é obrigatório na estrutura básica descrita pela documentação da Anthropic. Os demais diretórios são opcionais.

3.3. O frontmatter YAML

O início do arquivo SKILL.md utiliza metadados em YAML, delimitados por três hífens.

---
name: analise-de-dados
description: >
  Analisa conjuntos de dados, identifica inconsistências,
  valida estruturas e produz relatórios.
---

# Análise de Dados

## Objetivo

Executar análises estruturadas e reproduzíveis.

## Procedimento

1. Identificar a origem dos dados.
2. Verificar o formato dos arquivos.
3. Validar os campos obrigatórios.
4. Identificar valores ausentes.
5. Executar as análises solicitadas.
6. Conferir os resultados.
7. Produzir o relatório final.

Os campos principais possuem regras específicas:

• name: nome identificador da habilidade. Na especificação da Anthropic, deve utilizar letras minúsculas, números e hífens, respeitando o limite de 64 caracteres.
• description: descreve o que a habilidade faz e em quais situações deve ser utilizada. O limite documentado é de 1.024 caracteres.
• compatibility: campo opcional para informar requisitos ambientais.
• allowed-tools: campo opcional para declarar ferramentas permitidas, quando suportado pelo ambiente.

Nem todos os ambientes implementam exatamente os mesmos campos ou regras adicionais. Portanto, o desenvolvedor deve consultar a especificação e a documentação da plataforma escolhida.

3.4. Por que o SKILL.md deve ser objetivo?

Uma habilidade precisa fornecer orientações suficientes para executar uma tarefa sem se transformar em uma enciclopédia desorganizada.

Se todos os detalhes de implementação, exemplos extensos e documentação forem colocados no arquivo principal, o agente poderá receber informações que não são necessárias para a atividade atual.

Uma boa prática é manter o procedimento principal no SKILL.md e transferir informações específicas para arquivos de referência.

4. Divulgação progressiva: a economia de contexto

Modelos de linguagem trabalham com janelas de contexto limitadas. Mesmo quando a janela é muito grande, isso não significa que seja conveniente preencher todo o espaço com informações permanentes.

A divulgação progressiva, ou Progressive Disclosure, organiza o carregamento de conhecimento em etapas.

As três camadas de carregamento

1. Descoberta: o agente identifica as habilidades disponíveis por meio de seus metadados.
2. Ativação: quando uma habilidade é considerada relevante, suas instruções principais são carregadas.
3. Execução: arquivos complementares e scripts são consultados ou utilizados quando necessários.

Essa abordagem evita que todo o conteúdo de todas as habilidades precise estar presente permanentemente na janela de contexto.

Exemplo: um agente possui habilidades para análise de planilhas, revisão de código, elaboração de relatórios e pesquisa documental. Se a tarefa atual é revisar um programa Python, não há motivo para carregar integralmente os procedimentos de análise financeira.

4.1. Contexto como orçamento de atenção

Existe uma diferença entre possuir capacidade de armazenar contexto e conseguir utilizar todas as informações de maneira eficiente.

Instruções concorrentes, regras redundantes e informações irrelevantes podem dificultar a identificação do que realmente importa para uma tarefa.

Por isso, a engenharia de contexto deve priorizar:

• Informações diretamente relacionadas à tarefa.
• Regras de segurança e restrições indispensáveis.
• Dados atualizados e identificáveis.
• Exemplos realmente úteis.
• Documentação complementar recuperada sob demanda.

Não existe um número universal de tokens que garanta uma skill eficiente. O tamanho adequado depende do modelo, da tarefa, do ambiente e dos resultados dos testes.

5. O protocolo @skills e a organização das habilidades

Uma questão aparece quando o número de habilidades cresce: como disponibilizar centenas ou milhares de procedimentos sem transformar o prompt do sistema em um catálogo permanente de instruções?

O artigo técnico @skills: Attention is all you have, publicado no arXiv em agosto de 2026, apresenta uma proposta de protocolo aberto que procura separar três funções: conteúdo, persistência e acionamento automático.

A proposta parte de uma observação arquitetural: nem toda habilidade precisa estar instalada permanentemente no prompt para poder ser utilizada.

5.1. Os componentes da proposta

• Referência por caminho: permite indicar uma habilidade pelo endereço ou caminho em que está armazenada.
• .atskills/: diretório utilizado para manter cópias versionadas e adaptadas ao projeto.
• .autotrigger: arquivo que registra quais habilidades devem permanecer disponíveis para acionamento automático.
• .source: registro de origem e revisão da habilidade, permitindo rastrear sua procedência.

A proposta busca diminuir a necessidade de manter descrições de todas as habilidades permanentemente no contexto do agente.

5.2. Três formas de organização

Camada	Organização	Uso
Referência	Acesso por caminho.	Habilidades utilizadas ocasionalmente.
Projeto	Cópia versionada no repositório.	Procedimentos adaptados pela equipe.
Acionamento automático	Habilidades selecionadas para ativação permanente.	Procedimentos centrais e recorrentes.

É importante observar que o @skills é uma proposta técnica específica, e não um requisito universal de todos os agentes ou uma substituição obrigatória do padrão SKILL.md.

Seu valor está em discutir um problema real de engenharia: a relação entre quantidade de habilidades disponíveis, descoberta, acionamento e consumo de contexto.

6. Engenharia de prompts avançada e modularização componível

A modularização não se limita à divisão de um texto grande em vários arquivos. Ela exige separar responsabilidades que possuem comportamentos e critérios de validação diferentes.

6.1. O desacoplamento entre linguagem e lógica determinística

Um LLM é adequado para interpretar linguagem natural, resumir informações, classificar solicitações e produzir conteúdo contextualizado.

Entretanto, tarefas como verificar se um campo está preenchido, calcular um valor, conferir uma permissão ou determinar se uma operação foi concluída devem ser controladas por mecanismos determinísticos sempre que possível.

Imagine um assistente responsável por cadastrar um cliente.

O modelo pode interpretar uma mensagem como:

"Quero cadastrar Maria, que mora em São Paulo, e utilizar o e-mail informado na conversa."

O LLM pode extrair os dados e organizá-los em uma estrutura. Mas a aplicação deve verificar os campos obrigatórios, validar o endereço eletrônico, consultar duplicidades e somente então autorizar a gravação.

Uma arquitetura adequada separa:

1. Interpretação da solicitação pelo modelo.
2. Extração de dados estruturados.
3. Validação programática.
4. Verificação de autorização.
5. Execução da operação.
6. Confirmação do resultado.

O modelo não deve ser a única autoridade responsável por declarar que uma operação foi realizada com sucesso.

6.2. Prompt Chaining: encadeamento de instruções

O Prompt Chaining consiste em dividir uma tarefa complexa em etapas conectadas.

Em vez de solicitar que um único modelo pesquise, classifique, analise, compare e redija tudo simultaneamente, o sistema organiza um fluxo de transformações.

Um pipeline pode funcionar da seguinte maneira:

ENTRADA DO USUÁRIO
        |
        v
[1] INTERPRETAÇÃO
        |
        v
[2] EXTRAÇÃO DE INFORMAÇÕES
        |
        v
[3] VALIDAÇÃO DO RESULTADO
        |
        v
[4] ANÁLISE ESPECIALIZADA
        |
        v
[5] REVISÃO E CONFERÊNCIA
        |
        v
[6] ENTREGA FINAL

Cada etapa recebe somente os dados necessários para sua responsabilidade.

6.3. Os cinco contratos de cada etapa

Para tornar o pipeline previsível, cada módulo deve possuir um contrato de interface.

• Entrada contextualizada: quais informações o módulo recebe?
• Instrução focada: qual transformação deverá executar?
• Contrato de saída: qual estrutura deverá produzir?
• Validação: como o sistema verifica se o resultado está correto?
• Encaminhamento: quais informações seguem para o próximo estágio?

Quando a aplicação exige dados estruturados, formatos como JSON associados a esquemas de validação ajudam a reduzir inconsistências de interface.

6.4. Exemplo de contrato JSON

{
  "status": "sucesso",
  "categoria": "financeiro",
  "dados": {
    "valor": 1500.00,
    "moeda": "BRL"
  },
  "precisa_revisao": true,
  "justificativa": "Valor extraído da solicitação."
}

O sistema deve verificar se os campos obrigatórios existem, se os tipos estão corretos e se os valores obedecem às regras de negócio.

Uma saída JSON válida não garante que a informação seja verdadeira. Validade estrutural e validade factual são controles diferentes.

7. Evidência experimental: modularização em sistemas Text-to-SQL

A modularização não é apenas uma preferência estética de desenvolvimento. Existem pesquisas que investigam seus efeitos em aplicações concretas.

Um exemplo brasileiro é o trabalho Composable Prompt Modularization in Text-to-SQL Agents: A Practical Approach, desenvolvido por pesquisadores vinculados à Universidade Federal do Ceará (UFC) e à Universidade de Fortaleza (Unifor).

O estudo investiga agentes capazes de converter perguntas em linguagem natural em consultas SQL, utilizando uma arquitetura que separa a classificação da pergunta da geração da consulta.

7.1. O que foi investigado?

A abordagem modular organiza o processo em duas camadas principais:

1. Classificação semântica da intenção e interpretação da pergunta.
2. Geração da consulta SQL utilizando os esquemas relacionais pertinentes.

Essa divisão permite que o sistema identifique primeiro o significado da solicitação e depois construa a consulta com base na estrutura dos dados disponíveis.

7.2. Resultados apresentados

95,39% — maior acurácia de execução apresentada no resumo do estudo para a arquitetura modular, dentro das condições experimentais avaliadas.

Na comparação com cinco exemplos recuperados (Top-k = 5), o trabalho informa:

Abordagem	Acurácia de execução
Prompt monolítico	94,08%
Prompt modular	94,74%

A diferença observada foi de 0,66 ponto percentual em favor da arquitetura modular nesse cenário.

O resumo também apresenta uma pontuação média de 0,954 para alinhamento estrutural na métrica de correspondência de componentes.

Importante: esses números representam os experimentos e condições descritos no trabalho. Não significam que toda arquitetura modular alcançará 95,39% de acurácia ou que será sempre superior a um prompt monolítico.

O estudo é interessante porque demonstra como a decomposição semântica pode ser aplicada a um problema real, especialmente quando os sistemas precisam interpretar solicitações humanas e consultar bases relacionais.

8. Ciclo de vida das skills: avaliação, testes e desenvolvimento orientado por falhas

Uma habilidade não se torna confiável simplesmente porque suas instruções parecem bem escritas.

O verdadeiro teste é seu comportamento diante de situações reais, incluindo dados incompletos, solicitações ambíguas, erros de ferramenta e condições inesperadas.

8.1. Avaliação antes da implementação

Uma abordagem eficiente começa pela identificação dos problemas que a habilidade precisa resolver.

1. Estabeleça uma linha de base: execute a tarefa sem a skill e registre os comportamentos observados.
2. Identifique falhas: documente erros de interpretação, omissões, formatos inadequados e decisões incorretas.
3. Transforme falhas em requisitos: crie instruções para tratar problemas concretos.
4. Teste novamente: compare o comportamento com e sem a habilidade.
5. Automatize avaliações: preserve exemplos de referência para detectar regressões.

Essa metodologia evita que o desenvolvedor acrescente regras desnecessárias apenas por imaginar que elas poderão ajudar.

8.2. O que são Skill Smells?

Na engenharia de software tradicional, a expressão Code Smells descreve sinais de que um código pode possuir problemas de estrutura ou manutenção.

O conceito de Skill Smells aplica raciocínio semelhante às habilidades de agentes.

São características que podem indicar instruções frágeis, ambíguas ou difíceis de manter.

Entre os principais problemas que merecem auditoria estão:

Problema	Manifestação	Melhoria recomendada
Regras ambíguas	O agente interpreta uma obrigação como opcional.	Definir condições explícitas de aprovação e interrupção.
Avisos escondidos	Restrições importantes aparecem no meio de textos extensos.	Destacar as regras críticas no início.
Execução sem planejamento	O agente começa operações complexas sem verificar requisitos.	Separar planejamento e execução.
Ausência de aprovação humana	Ações sensíveis são realizadas sem confirmação.	Estabelecer pontos de aprovação obrigatória.
Excesso de contexto	Documentação detalhada é repetida em todas as instruções.	Transferir materiais extensos para referências.
Comandos rígidos	Procedimentos dependem de caminhos e parâmetros fixos.	Definir objetivos, condições e resultados esperados.
Falta de testes	Alterações são publicadas sem comparação de desempenho.	Manter avaliações de regressão.

8.3. Testes de regressão e Golden Prompts

Uma técnica importante é manter um conjunto de solicitações representativas, conhecidas como Golden Prompts.

São entradas utilizadas repetidamente para verificar se uma nova versão continua apresentando o comportamento esperado.

Exemplo de conjunto de testes para uma skill de análise documental:

• Documento completo e corretamente formatado.
• Documento com informações ausentes.
• Documento com tabelas complexas.
• Documento com dados contraditórios.
• Solicitação fora do escopo da habilidade.
• Arquivo ilegível ou incompatível.

As respostas devem ser avaliadas segundo critérios objetivos, como precisão, completude, aderência ao formato, rastreabilidade e capacidade de reconhecer limitações.

O objetivo não é obrigar o modelo a produzir sempre a mesma resposta textual, mas verificar se continua respeitando os requisitos funcionais.

9. Interfaces de voz: arquitetura do Amazon Alexa Skills Kit

Enquanto os agentes de software tradicionais operam frequentemente por textos, arquivos, ferramentas e APIs, as interfaces de voz apresentam desafios próprios.

O usuário não precisa conhecer menus, botões ou comandos técnicos. Ele simplesmente fala.

Essa diferença exige uma arquitetura que transforme linguagem falada em intenções estruturadas.

O Amazon Alexa Skills Kit (ASK) oferece um exemplo importante de como desenvolver interfaces conversacionais com separação entre o reconhecimento da solicitação e a lógica responsável pela execução.

9.1. Os quatro elementos do modelo de interação

O modelo de interação de uma skill personalizada pode ser compreendido por meio de quatro componentes:

• Invocation Name: expressão utilizada para iniciar a habilidade.
• Intents: representam as ações que a habilidade pode atender.
• Sample Utterances: frases de exemplo associadas às intenções.
• Slots: variáveis utilizadas para extrair informações das frases.

Imagine uma skill de controle financeiro.

O usuário pode perguntar:

"Alexa, quanto gastei com alimentação este mês?"

O sistema precisa reconhecer a intenção de consulta financeira e extrair informações como categoria e período.

Essas informações são encaminhadas ao backend em uma estrutura organizada.

9.2. Intents e Slots na prática

Uma intenção chamada ConsultarGastosIntent pode utilizar os seguintes slots:

{
  "intent": "ConsultarGastosIntent",
  "slots": {
    "categoria": "alimentação",
    "periodo": "este mês"
  }
}

O reconhecimento da intenção e a resolução dos valores dependem do modelo de interação, dos recursos da plataforma e da implementação escolhida.

9.3. Backend serverless com AWS Lambda

Uma skill pode utilizar uma função hospedada no AWS Lambda para processar solicitações.

O modelo de processamento separa o reconhecimento do evento da lógica de atendimento.

No ASK SDK para Node.js, dois métodos são especialmente importantes:

• canHandle(): verifica se determinado manipulador é responsável pelo evento recebido.
• handle(): executa a lógica correspondente e constrói a resposta.

Exemplo simplificado de um manipulador inicial:

const Alexa = require('ask-sdk-core');

const LaunchRequestHandler = {

  canHandle(handlerInput) {
    return Alexa.getRequestType(
      handlerInput.requestEnvelope
    ) === 'LaunchRequest';
  },

  handle(handlerInput) {

    const speakOutput =
      'Olá! Qual informação você deseja consultar?';

    return handlerInput.responseBuilder
      .speak(speakOutput)
      .reprompt(
        'Você pode fazer uma pergunta.'
      )
      .getResponse();
  }
};

exports.handler = Alexa.SkillBuilders.custom()
  .addRequestHandlers(LaunchRequestHandler)
  .lambda();

Esse exemplo ilustra a estrutura do SDK. Uma aplicação de produção também precisa implementar os manipuladores de intenção, tratamento de erros, validações e integração com seus serviços.

9.4. Speak e Reprompt

As funções possuem responsabilidades diferentes:

• speak(): define o conteúdo que será falado imediatamente.
• reprompt(): define uma nova orientação caso o usuário não responda e a sessão permaneça aberta.

Essa segunda resposta ajuda a manter uma conversa natural, evitando que o usuário precise reiniciar a interação a cada silêncio.

9.5. O desafio cognitivo das interfaces de voz

Uma interface visual permite que o usuário releia informações. Uma interface exclusivamente falada precisa respeitar a capacidade de retenção auditiva.

Uma heurística útil é o chamado One-Breath Test: a resposta principal deve ser curta o suficiente para ser compreendida naturalmente em uma única fala, sem exigir uma sequência excessiva de informações.

Não se trata de uma exigência formal universal da Amazon, mas de uma recomendação de design conversacional.

Quando a informação for extensa, o assistente pode apresentar um resumo por voz e disponibilizar detalhes em uma interface complementar, quando o dispositivo e a plataforma oferecerem esse recurso.

9.6. Segurança nas habilidades de voz

Interfaces de voz precisam considerar problemas de identificação de comandos, privacidade e autorização.

Uma habilidade não deve presumir que reconhecer uma frase equivale a confirmar a identidade de quem está falando.

Consultas comuns e operações sensíveis devem possuir níveis diferentes de proteção.

Informações pessoais, dados financeiros e operações que alterem registros precisam de controles adicionais, conforme o risco da aplicação.

10. Assistentes especializados, RAG e integração com APIs

Os assistentes especializados representam uma etapa importante na transformação dos modelos de linguagem em ferramentas de trabalho.

Em vez de utilizar um modelo generalista para qualquer atividade, uma organização pode configurar assistentes com instruções, bases documentais e ferramentas específicas.

10.1. Instruções permanentes e conhecimento especializado

Um assistente corporativo pode possuir:

• Identidade e função claramente delimitadas.
• Regras institucionais.
• Vocabulário e padrões de comunicação.
• Documentação técnica.
• Base de conhecimento especializada.
• Ferramentas autorizadas.

Essa organização permite que o assistente opere dentro de um escopo definido.

10.2. RAG: recuperação aumentada por geração

O Retrieval-Augmented Generation (RAG) combina a capacidade de geração dos modelos com a recuperação de informações externas.

Em vez de depender exclusivamente do conhecimento aprendido durante o treinamento, o sistema procura documentos relevantes no momento da consulta e fornece os trechos encontrados como contexto ao modelo.

O fluxo simplificado é:

PERGUNTA DO USUÁRIO
        |
        v
BUSCA NA BASE DOCUMENTAL
        |
        v
RECUPERAÇÃO DOS TRECHOS
RELEVANTES
        |
        v
CONSTRUÇÃO DO CONTEXTO
        |
        v
MODELO DE LINGUAGEM
        |
        v
RESPOSTA COM BASE NAS FONTES

O RAG é útil para manuais internos, políticas empresariais, contratos, documentação técnica e bases de conhecimento que mudam frequentemente.

Uma ressalva fundamental: RAG não elimina alucinações. A recuperação pode retornar documentos incompletos, desatualizados ou irrelevantes. O modelo também pode interpretar incorretamente os trechos recuperados. São necessários controles de qualidade, rastreabilidade e avaliação.

10.3. A diferença entre conhecimento e capacidade de execução

Um assistente que consulta documentos não é necessariamente capaz de executar operações externas.

Para acessar sistemas, consultar bancos de dados ou atualizar registros, ele precisa de ferramentas e integrações devidamente configuradas.

É nesse ponto que entram as APIs e o Function Calling.

10.4. Function Calling e ferramentas externas

O Function Calling permite que o modelo solicite a execução de funções disponibilizadas pela aplicação.

Imagine um sistema de inventário que disponibiliza uma função para consultar equipamentos:

{
  "name": "consultar_ativo",
  "description": "Consulta a disponibilidade de um equipamento",
  "parameters": {
    "type": "object",
    "properties": {
      "categoria": {
        "type": "string",
        "description": "Categoria do equipamento"
      }
    },
    "required": ["categoria"],
    "additionalProperties": false
  }
}

O modelo pode identificar que o usuário deseja consultar a disponibilidade de notebooks e solicitar a chamada da função com os argumentos correspondentes.

Entretanto, a aplicação que controla a ferramenta continua responsável por verificar a autorização, validar os parâmetros e executar a operação.

10.5. OpenAPI e integração padronizada

O OpenAPI é uma especificação utilizada para descrever interfaces HTTP de maneira estruturada.

Um esquema pode informar:

• Quais endpoints estão disponíveis.
• Quais métodos HTTP podem ser utilizados.
• Quais parâmetros são obrigatórios.
• Quais estruturas são aceitas.
• Quais respostas podem ser retornadas.
• Quais mecanismos de autenticação são necessários.

Essa descrição facilita a integração entre assistentes, aplicações e serviços externos.

10.6. Duas estratégias de integração

Estratégia	Funcionamento	Aplicação
Orientada ao modelo	O modelo seleciona uma ferramenta disponível e propõe seus argumentos.	Consultas e pesquisas com baixo impacto operacional.
Orquestrada pela aplicação	O modelo sugere a operação, enquanto o backend valida e executa.	Operações empresariais, transacionais e sensíveis.

Em operações que alteram dados, movimentam recursos ou produzem consequências relevantes, a orquestração pela aplicação é especialmente importante.

11. Segurança e governança corporativa dos agentes

Quanto maior a capacidade de um agente, maior deve ser o rigor dos controles utilizados para limitar suas ações.

Um sistema que apenas responde perguntas possui um perfil operacional diferente daquele que pode enviar mensagens, alterar registros, consultar informações privadas ou executar códigos.

Por isso, segurança não pode ser acrescentada apenas depois que o agente estiver funcionando.

11.1. Princípio do menor privilégio

O agente deve receber somente as permissões necessárias para executar a tarefa autorizada.

Uma habilidade de leitura de documentos não precisa receber automaticamente permissão para apagar arquivos ou modificar sistemas corporativos.

O mesmo princípio deve ser aplicado às APIs, credenciais e ferramentas.

11.2. Aprovação humana

Operações sensíveis precisam de pontos explícitos de confirmação.

Exemplos:

• Excluir arquivos ou registros.
• Enviar comunicações em nome de uma organização.
• Realizar pagamentos.
• Modificar dados de clientes.
• Publicar conteúdos externamente.
• Executar mudanças irreversíveis.

O agente pode preparar a operação, apresentar seus parâmetros e explicar as consequências. A execução deve depender da autorização apropriada.

11.3. Injeção de prompts e conteúdo não confiável

Um agente pode receber informações provenientes de páginas da internet, documentos, e-mails e arquivos externos.

Esses materiais podem conter instruções maliciosas ou enganosas destinadas a influenciar o comportamento do modelo.

Esse problema é conhecido como injeção de prompt, incluindo sua modalidade indireta.

Uma arquitetura segura deve tratar conteúdo externo como dado, e não como autorização para modificar as regras do sistema.

As permissões precisam ser verificadas fora do modelo, e as ferramentas devem limitar as operações que podem ser executadas.

11.4. Observabilidade e métricas

Um agente precisa ser acompanhado durante sua operação.

Algumas métricas importantes incluem:

• Taxa de conclusão: proporção de tarefas finalizadas corretamente.
• Taxa de escalonamento: frequência de transferência para atendimento ou revisão humana.
• Taxa de erro: quantidade de falhas de interpretação, ferramentas e validação.
• Latência: tempo necessário para concluir uma solicitação.
• Custo por tarefa: consumo de recursos computacionais e chamadas de ferramentas.
• Taxa de retrabalho: frequência com que o usuário precisa corrigir ou repetir uma solicitação.

O volume de mensagens isoladamente não representa qualidade. Uma conversa curta pode indicar eficiência ou abandono. Uma conversa longa pode representar uma tarefa complexa ou um problema de execução.

As métricas devem ser interpretadas em conjunto com o contexto e com avaliações qualitativas.

12. Como construir uma arquitetura de agente na prática

Para transformar os conceitos apresentados em um projeto funcional, podemos imaginar a construção de um agente especializado em análise de documentos empresariais.

Etapa 1 — Definir o objetivo

O primeiro passo é estabelecer exatamente o que o agente deverá fazer.

Exemplo: receber documentos, identificar informações relevantes, comparar dados, verificar inconsistências e produzir relatórios.

Etapa 2 — Definir as habilidades

Em vez de concentrar todo o procedimento em uma instrução, o sistema pode possuir habilidades independentes:

• extrair-documentos
• validar-informacoes
• comparar-registros
• gerar-relatorios
• revisar-resultados

Etapa 3 — Criar ferramentas determinísticas

Desenvolva funções para operações que exigem resultados verificáveis:

• Leitura de arquivos.
• Validação de formatos.
• Consultas a bancos de dados.
• Comparação de valores.
• Geração de arquivos.

Etapa 4 — Organizar o fluxo de execução

Uma arquitetura simplificada pode ser representada assim:

             USUÁRIO
                |
                v
        INTERFACE CONVERSACIONAL
                |
                v
          AGENTE CENTRAL
                |
                v
       ORQUESTRADOR DA APLICAÇÃO
                |
        +-------+-------+
        |       |       |
        v       v       v
      SKILL   SKILL   SKILL
     EXTRAIR VALIDAR COMPARAR
        |       |       |
        +-------+-------+
                |
                v
       FERRAMENTAS E APIS
                |
                v
        BASE DE CONHECIMENTO
                |
                v
       VALIDAÇÃO DOS RESULTADOS
                |
                v
       APROVAÇÃO HUMANA
                |
                v
          ENTREGA FINAL

Etapa 5 — Estabelecer critérios de validação

Antes de considerar o trabalho concluído, o sistema precisa verificar:

• Se todos os documentos necessários foram processados.
• Se as informações obrigatórias estão presentes.
• Se existem divergências não resolvidas.
• Se os cálculos foram realizados corretamente.
• Se as fontes estão identificadas.
• Se a saída corresponde ao formato solicitado.

Etapa 6 — Implementar testes contínuos

O projeto precisa manter casos de teste que permitam avaliar alterações nos prompts, nas skills, nos modelos e nas ferramentas.

Uma atualização aparentemente simples pode mudar o comportamento do agente. Por isso, cada versão deve ser comparada com uma linha de base conhecida.

Etapa 7 — Implantar monitoramento

Após a publicação, acompanhe erros, custos, tempo de resposta, intervenções humanas e satisfação dos usuários.

O desenvolvimento não termina quando o agente começa a funcionar. Ele continua durante todo o ciclo de vida da aplicação.

13. O futuro da engenharia de agentes: da conversa à execução

A evolução dos modelos de linguagem está ampliando a possibilidade de construir aplicações que combinam texto, voz, documentos, imagens, ferramentas e serviços externos.

Entretanto, essa evolução não significa que os agentes estejam se tornando sistemas infalíveis ou plenamente independentes.

O verdadeiro avanço está na possibilidade de coordenar capacidades especializadas dentro de processos controlados.

13.1. Da interface de texto às experiências multimodais

Os sistemas poderão combinar diferentes formas de interação:

• Conversação textual.
• Reconhecimento e geração de voz.
• Interpretação de documentos.
• Compreensão de imagens.
• Execução de ferramentas externas.
• Integração com aplicações e serviços.

Isso permite criar assistentes mais adequados ao contexto de cada atividade.

13.2. Skills como componentes reutilizáveis

Habilidades bem estruturadas podem reduzir a duplicação de procedimentos entre projetos.

Uma equipe pode desenvolver uma skill de auditoria documental e reutilizá-la em diferentes agentes, desde que os ambientes sejam compatíveis e as permissões sejam adequadamente configuradas.

O controle de versões, a documentação e os testes tornam-se essenciais para evitar que habilidades antigas continuem sendo utilizadas sem revisão.

13.3. O novo papel dos profissionais

A engenharia de agentes cria espaço para profissionais que compreendam simultaneamente:

• Modelos de linguagem.
• Arquitetura de software.
• Engenharia de contexto.
• Integração de APIs.
• Automação de processos.
• Segurança e governança.
• Avaliação de sistemas inteligentes.

O conhecimento de escrever bons prompts continua sendo relevante, mas passa a integrar uma competência mais ampla.

Análise FaceLíder: a próxima geração de aplicações inteligentes não será definida apenas pela capacidade de produzir respostas impressionantes. Será definida pela capacidade de realizar tarefas úteis, demonstrar de onde vieram suas informações, reconhecer limites, respeitar permissões e permitir que pessoas controlem decisões importantes.

14. Cinco princípios para construir sistemas inteligentes confiáveis

Da engenharia de prompts à arquitetura de agentes, cinco princípios merecem orientar qualquer projeto profissional.

1. Contexto é um recurso: não carregue indiscriminadamente informações que não contribuem para a tarefa.
2. Modularidade é manutenção: separe responsabilidades e permita testar cada componente.
3. Avaliação deve começar cedo: identifique falhas antes de ampliar a aplicação.
4. Execução exige controle: ferramentas e APIs precisam de permissões, validações e registros.
5. Supervisão humana continua necessária: operações sensíveis não devem depender exclusivamente da interpretação do modelo.

15. Perguntas frequentes sobre engenharia de agentes de IA

O que é engenharia de agentes de IA?

É a disciplina de projetar, desenvolver, integrar e avaliar sistemas inteligentes capazes de interpretar solicitações, coordenar etapas, utilizar ferramentas e executar tarefas dentro de limites definidos.

Qual é a diferença entre engenharia de prompts e engenharia de agentes?

A engenharia de prompts concentra-se na construção de instruções eficazes para modelos de linguagem. A engenharia de agentes amplia essa abordagem, incluindo ferramentas, memória, habilidades, orquestração, integrações e mecanismos de controle.

O que é uma Agent Skill?

É uma habilidade especializada que reúne instruções procedurais e, opcionalmente, scripts e materiais de referência para orientar um agente na execução de determinada atividade.

Para que serve o arquivo SKILL.md?

É o arquivo principal de uma skill no padrão documentado pela Anthropic. Ele contém metadados YAML e instruções que explicam como a habilidade deve ser utilizada.

O que significa Progressive Disclosure?

É a técnica de disponibilizar informações em etapas, carregando primeiro os metadados, depois as instruções necessárias e, por fim, recursos complementares quando forem solicitados.

O que é Prompt Chaining?

É a divisão de uma tarefa complexa em várias etapas de processamento, nas quais a saída de uma etapa é validada e encaminhada para a seguinte.

O RAG elimina as alucinações da inteligência artificial?

Não. O RAG pode melhorar a fundamentação das respostas ao recuperar documentos relevantes, mas não garante que a recuperação ou a interpretação do modelo estejam corretas.

Qual é a diferença entre um agente e uma ferramenta?

O agente coordena a execução de uma tarefa e decide quais capacidades utilizar. A ferramenta realiza uma operação específica, como consultar uma API, ler um arquivo ou executar um cálculo.

É possível utilizar Agent Skills com diferentes modelos?

Sim, desde que os ambientes de execução sejam compatíveis com a estrutura e as instruções utilizadas. A portabilidade depende também das ferramentas, dos caminhos de arquivos e das permissões disponíveis.

É seguro permitir que um agente execute ações automaticamente?

Depende da operação e dos controles existentes. Ações de baixo impacto podem ser automatizadas com validações apropriadas. Operações financeiras, destrutivas ou sensíveis exigem controles de autorização e, frequentemente, aprovação humana.

Preciso saber programar para criar um agente de IA?

Não necessariamente para protótipos e assistentes simples. Porém, sistemas profissionais com APIs, automação, validação, segurança e execução de operações exigem conhecimentos de programação e arquitetura de software.

16. Conclusão: a inteligência artificial precisa de engenharia, não apenas de bons prompts

A popularização dos modelos de linguagem criou uma percepção de que desenvolver aplicações inteligentes seria principalmente uma questão de escrever instruções cada vez melhores.

Essa percepção foi útil no início, mas não representa toda a complexidade dos sistemas que hoje precisam operar em ambientes reais.

Quando uma aplicação passa a lidar com informações empresariais, documentos, bancos de dados, ferramentas externas e decisões operacionais, a qualidade de um prompt deixa de ser suficiente para garantir confiabilidade.

É necessário pensar em arquitetura.

Metaprompting ajuda a criar instruções organizadas. Agent Skills permitem empacotar conhecimento procedural. A divulgação progressiva reduz o carregamento desnecessário de contexto. A modularização separa responsabilidades. O Prompt Chaining organiza tarefas complexas. O RAG conecta modelos a bases documentais. APIs e ferramentas permitem executar operações. Avaliações e mecanismos de governança ajudam a controlar o comportamento do sistema.

O ponto fundamental é compreender que a inteligência artificial não precisa controlar todas as partes de uma aplicação para ser útil. Pelo contrário: sistemas mais confiáveis surgem quando cada componente possui uma responsabilidade clara.

O modelo interpreta e propõe. O código valida e executa. As ferramentas realizam operações. O agente coordena. E o ser humano mantém a autoridade sobre decisões que exigem responsabilidade.

O futuro da IA não será determinado apenas por quem consegue escrever o melhor prompt, mas também por quem consegue transformar capacidades probabilísticas em sistemas úteis, verificáveis, seguros e sustentáveis.

Reflexão do Senhor Facelider:
A inteligência artificial está deixando de ser apenas uma janela de conversa e se tornando uma camada de operação do mundo digital. A pergunta mais importante já não é somente o que um modelo consegue responder, mas quais tarefas podemos confiar a ele, sob quais condições e com quais mecanismos de responsabilidade.

Se queremos construir uma tecnologia que realmente beneficie pessoas e organizações, precisamos ir além do encantamento com as respostas. Precisamos compreender a arquitetura que existe por trás delas.

---

17. Fontes e referências técnicas

As referências abaixo sustentam os principais conceitos técnicos apresentados neste artigo. Documentações de fornecedores descrevem o funcionamento de suas próprias plataformas; estudos acadêmicos apresentam resultados limitados aos seus respectivos experimentos.

1. Anthropic — Agent Skills: documentação oficial.
   Apresenta a estrutura do SKILL.md, metadados, carregamento progressivo, instruções e recursos complementares.
   Consultar documentação oficial.
2. Anthropic — Equipping agents for the real world with Agent Skills.
   Explica a organização das habilidades e o princípio de divulgação progressiva.
   Consultar artigo técnico.
3. Yin et al. — @skills: Attention is all you have (2026).
   Apresenta uma proposta de protocolo aberto para separar conteúdo, persistência e acionamento de habilidades.
   Consultar pesquisa no arXiv.
4. Gonçalves e colaboradores — Composable Prompt Modularization in Text-to-SQL Agents: A Practical Approach.
   Estudo brasileiro sobre modularização de prompts em agentes Text-to-SQL.
   Consultar registro do trabalho.
5. OpenAI — Prompt Engineering.
   Documentação sobre elaboração, estruturação, versionamento e avaliação de instruções para modelos de linguagem.
   Consultar documentação.
6. OpenAI — Function Calling.
   Explica como conectar modelos a funções e sistemas externos por meio de ferramentas estruturadas.
   Consultar documentação.
7. OpenAI — Structured Outputs.
   Apresenta mecanismos para estruturar saídas e chamadas de ferramentas conforme esquemas definidos.
   Consultar documentação.
8. OpenAI — Working with Evals.
   Material sobre avaliação sistemática de resultados de modelos e aplicações.
   Consultar documentação.
9. Amazon — Handle Requests Sent by Alexa.
   Documentação sobre o processamento de eventos e os manipuladores de requisições do Alexa Skills Kit.
   Consultar documentação oficial.
10. Amazon — Interaction Model Schema.
    Especificação dos elementos do modelo de interação, incluindo intents, slots e enunciados de exemplo.
    Consultar especificação.

18. Quer atualizar este conteúdo no futuro?

A engenharia de agentes está evoluindo rapidamente. Novas especificações, modelos, ferramentas e padrões de integração podem alterar as recomendações técnicas deste guia.

Utilize o seguinte comando em uma ferramenta de inteligência artificial com acesso à internet para revisar o conteúdo futuramente:

PROMPT DE ATUALIZAÇÃO — ENGENHARIA DE AGENTES DE IA

Atue como pesquisador técnico especializado em inteligência artificial, engenharia de software, modelos de linguagem e arquitetura de agentes.

Analise este artigo sobre engenharia de prompts, Agent Skills, SKILL.md, protocolo @skills, Prompt Chaining, RAG, Function Calling e interfaces de voz.

Execute as seguintes atividades:

1. Informe a data atual da pesquisa.
2. Identifique novidades publicadas depois da data original do artigo.
3. Consulte prioritariamente documentações oficiais, pesquisas acadêmicas e especificações técnicas.
4. Verifique mudanças nos padrões Agent Skills e nas ferramentas de desenvolvimento de agentes.
5. Confira a evolução do protocolo @skills e de suas implementações.
6. Verifique novas pesquisas sobre modularização, avaliação e qualidade de habilidades.
7. Analise mudanças nas APIs de modelos de linguagem, RAG, Function Calling e integração OpenAPI.
8. Verifique atualizações relevantes no Alexa Skills Kit e nas interfaces de voz.
9. Separe fatos confirmados, resultados experimentais, propostas e previsões.
10. Identifique informações desatualizadas, referências indisponíveis e recomendações que precisam de revisão.
11. Apresente links diretos para todas as fontes consultadas.
12. Indique exatamente quais parágrafos e seções deste artigo devem ser atualizados.

Não invente referências, estatísticas ou mudanças técnicas. Se não encontrar evidências suficientes, informe a limitação.

---

Senhor Facelider — Tecnologia, inteligência artificial, comportamento digital e o futuro da sociedade.