A anatomia de um agente de IAcompartilhar

É comum representar um agente de IA como um grande modelo de linguagem conectado a algumas ferramentas. Essa imagem funciona como simplificação, mas esconde boa parte do que permite ao sistema conduzir uma tarefa do início ao fim.

Em uma chamada, um LLM interpreta uma entrada e produz uma saída. Sustentar uma tarefa com várias etapas, porém, exige preservar informações, controlar ações e reagir ao resultado de cada operação.

É da relação entre orquestrador, modelo, memória, ferramentas e base de conhecimento que surge o agente. Neste texto, examinaremos a responsabilidade de cada componente e como eles se combinam em uma aplicação.

O modelo não é o agente

Essa diferença fica mais clara no artigo Cognitive Architectures for Language Agents, publicado em 2024 por pesquisadores da Universidade de Princeton e conhecido como CoALA. Inspirado pela inteligência artificial simbólica e pelas arquiteturas cognitivas, o artigo parte de uma ideia simples. O comportamento de um agente não nasce de um componente isolado, mas da organização entre memória, decisão e ação.

O CoALA não busca desenvolver um framework de software. Ele oferece uma taxonomia para descrever agentes de linguagem a partir de três dimensões:

1. Memória: o que o sistema mantém durante e entre as etapas de uma tarefa.
2. Espaço de ações: quais operações internas e externas o sistema pode realizar.
3. Procedimento de decisão: como o sistema escolhe e executa seu próximo passo.

O LLM participa principalmente do raciocínio. Ele recebe uma parte das informações disponíveis e pode produzir uma resposta, um plano ou uma proposta de ação. Entretanto, o modelo não mantém sozinho o estado da tarefa, não define quais capacidades estão disponíveis, não aplica permissões e não controla todo o ciclo de execução. Essas responsabilidades pertencem à aplicação ao seu redor.

Considere, por exemplo, um agente bancário que recebe o pedido: “Transfira R$ 1.500 para a conta da Ana que usei ontem”. O LLM precisa interpretar a frase e propor uma ação, mas sua saída é probabilística: ele produz a continuação que considera mais provável com base no contexto, sem oferecer uma garantia formal de que interpretou corretamente a intenção. Por isso, pode selecionar a Ana errada entre contatos, confundir o valor, preencher um argumento inválido ou repetir a solicitação depois de uma falha de comunicação. Se essa saída fosse executada diretamente, uma interpretação plausível, mas incorreta, poderia movimentar dinheiro para a conta errada ou causar uma transferência duplicada.

Para evitar esse risco, o modelo apenas propõe uma ação estruturada. Componentes determinísticos verificam se valor, moeda e identificador da conta seguem um esquema válido; diante de mais de uma “Ana”, interrompem o fluxo e pedem esclarecimento; aplicam regras de identidade, saldo, limite e autorização; e exibem os dados exatos para a confirmação do usuário. Na execução, uma chave de idempotência impede que a mesma solicitação seja processada duas vezes, enquanto uma transação atômica garante que débito e crédito aconteçam por completo ou não aconteçam. O agente só informa o sucesso depois de receber a confirmação do sistema financeiro e registrar a operação para auditoria. Assim, o LLM lida com a ambiguidade da linguagem, enquanto as regras e garantias determinísticas impedem que sua incerteza viole as condições da transação.

O exemplo torna concreta a distinção central: o modelo interpreta a linguagem e propõe possibilidades, enquanto a aplicação preserva o estado, controla as ações e acompanha seus resultados. Essa divisão de responsabilidades é o ponto de partida para compreender os componentes do agente.

Uma visão geral da anatomia

Em nível de aplicação, a anatomia básica de um agente pode ser organizada em cinco componentes:

O orquestrador coordena o ciclo, recupera o estado da memória, prepara o contexto enviado ao modelo e interpreta sua resposta. Quando a tarefa exige uma operação ou informações do domínio, ele aciona uma ferramenta. Ferramentas de recuperação consultam a base de conhecimento, e seus resultados retornam ao orquestrador como observações que podem alimentar uma nova decisão.

Os cinco componentes representam responsabilidades, não uma obrigação de criar um microserviço para cada uma:

Essa separação é arquitetural. No CoALA, a base de conhecimento continua sendo uma forma de memória semântica de longo prazo. Aqui, memória designa o estado e o histórico das execuções, enquanto base de conhecimento designa as fontes de domínio consultadas pelas ferramentas. APIs, políticas, permissões e validações continuam presentes na implementação, mas funcionam como interfaces ou controles transversais, não como componentes dessa decomposição.

Orquestrador

O orquestrador é o componente que mantém o ciclo do agente em funcionamento. No CoALA, ele implementa o procedimento de decisão, o processo que combina memória e ações para determinar o que deve acontecer em seguida.

Ele carrega o estado, seleciona as informações relevantes, monta o contexto enviado ao modelo e interpreta sua proposta. Em seguida, seleciona o próximo passo, aplica os controles necessários, coordena a execução de uma ferramenta e registra o resultado na memória. O modelo participa da decisão, mas não é o único responsável por ela.

Uma versão simplificada desse ciclo poderia ser:

while (!state.finished) {
  const context = buildContext(state)
  const proposal = await model.propose(context)
  const action = selectNextAction(proposal, state)

  await validate(action, user, state)

  if (action.type === "respond") {
    state = finish(state, action.content)
  } else {
    const observation = await tools.execute(action)
    state = transition(state, action, observation)
  }

  await memory.save(state)
}

return state.response

Nem todo agente precisa implementar cada etapa com a mesma profundidade. Em tarefas simples, o modelo pode propor uma única ação, que será validada e executada. Em tarefas críticas, o orquestrador pode comparar alternativas com regras determinísticas ou exigir aprovação humana antes de prosseguir.

O fluxo também não precisa ser inteiramente aberto. Algumas etapas podem ser definidas em uma máquina de estados, enquanto o modelo atua apenas nos pontos em que interpretação ou flexibilidade são necessárias. O ciclo raciocínio–ação–observação popularizado pelo ReAct é uma forma simples de colocar esse procedimento em movimento, mas não substitui toda a arquitetura descrita pelo CoALA.

Além do caminho principal, o orquestrador controla limites de iteração, tempo máximo, repetição de ações, falhas de integração e condições de parada. Ele também decide quando pedir mais informações ao usuário ou encaminhar a tarefa para uma pessoa. O comportamento do agente nasce, portanto, da combinação entre as possibilidades produzidas pelo modelo e os controles determinísticos da aplicação.

Modelo

O modelo é o componente capaz de interpretar linguagem, relacionar informações, gerar hipóteses e propor próximos passos. No vocabulário do CoALA, ele participa principalmente das ações internas de raciocínio, lê informações selecionadas da memória de trabalho e produz novas informações que retornam a ela.

Ele pode receber o objetivo, algumas observações e a descrição das ferramentas disponíveis. Como saída, pode produzir uma resposta ao usuário ou uma proposta estruturada, como consultarPedido({ orderId: "123" }). Essa saída ainda não é a execução da operação. É uma possibilidade que precisa ser interpretada, avaliada e validada pelo orquestrador.

Essa separação é importante porque a resposta do modelo é probabilística. Identidade, autorização, regras de negócio e efeitos externos precisam de controles verificáveis e independentes dele. O modelo pode identificar que uma consulta é necessária, mas não deve ser a autoridade que determina se o usuário tem acesso ao pedido informado.

Também não é necessário enviar todo o estado ao modelo. O orquestrador seleciona apenas as informações relevantes para a etapa atual. Isso reduz custo, evita ruído e limita a exposição de dados. Assim, o modelo amplia a capacidade de raciocínio do agente, mas permanece subordinado aos contratos e controles da aplicação.

Memória

Os modelos de linguagem não mantêm informações entre chamadas por conta própria. Cada requisição precisa fornecer novamente o contexto necessário. A aplicação resolve essa limitação mantendo um estado explícito para a execução.

Esse estado não é simplesmente o histórico completo da conversa. Ele pode conter o objetivo atual, a etapa em andamento, dados conhecidos, resultados de ferramentas, decisões anteriores, erros e uma ação aguardando confirmação. Uma estrutura simplificada poderia ser:

type AgentState = {
  sessionId: string
  goal: string
  messages: Message[]
  observations: Observation[]
  plan?: string[]
  pendingAction?: Action
  finished: boolean
}

No CoALA, a memória é organizada em quatro tipos:

• memória de trabalho: mantém as informações ativas durante a tarefa, como o objetivo, a etapa atual, as observações recebidas e uma ação aguardando execução. É o estado usado pelo agente para decidir o próximo passo;
• memória episódica: registra experiências anteriores, como conversas, decisões e sequências de ações. Ela permite recuperar o que aconteceu em outras execuções e manter continuidade entre interações;
• memória semântica: reúne conhecimentos que não dependem de uma execução específica, como fatos, conceitos, documentos, catálogos e informações sobre o domínio;
• memória procedural: representa maneiras de agir. Inclui instruções, prompts, fluxos, regras de decisão e código, além das capacidades aprendidas que permanecem implícitas nos pesos do modelo.

A janela de contexto do LLM não é um tipo de memória. Ela contém apenas a seleção de informações enviada ao modelo em uma chamada específica.

Nesta decomposição, o componente de memória concentra as memórias de trabalho e episódica. A memória semântica aparece na base de conhecimento, enquanto a procedural se distribui entre o modelo, as instruções, o orquestrador e as ferramentas.

Redis, Postgres e armazenamentos de documentos podem implementar partes da memória, mas a tecnologia utilizada não define sua função. O aspecto essencial é que o estado possa ser recuperado, atualizado e inspecionado de maneira consistente.

Atualizar a memória também é uma ação. Registrar uma conversa, alterar o objetivo corrente ou incorporar o resultado de uma ferramenta muda o contexto das decisões seguintes. Por isso, essas gravações precisam respeitar regras de retenção, privacidade e auditoria.

Ferramentas

O CoALA divide o espaço de ações entre operações internas e externas. As ações externas interagem com o ambiente por meio de ancoragem, ou grounding, consultar uma API, modificar um registro, controlar um dispositivo ou responder ao usuário. As ações internas transformam ou movimentam informações dentro do próprio agente:

• recuperação: consulta a memória ou a base de conhecimento e leva informações para o estado da execução;
• raciocínio: usa o modelo para produzir novas informações;
• aprendizagem: grava experiências, conhecimentos ou procedimentos para uso futuro.

No design da aplicação, ferramentas materializam as ações que exigem código controlado ou integração com outros sistemas. Uma ferramenta pode consultar um serviço externo, atualizar um registro ou recuperar documentos da base de conhecimento. Cada uma deve oferecer um contrato claro: nome, finalidade, formato de entrada, resultado esperado e implementação. O modelo conhece a descrição desse contrato, mas não precisa conhecer os detalhes da integração.

Considere uma ferramenta chamada consultarPedido. O modelo pode sugerir sua utilização após interpretar a pergunta “onde está meu pedido 123?”. Antes da execução, a aplicação precisa verificar se o identificador é válido, se o usuário está autenticado e se o pedido pertence a ele. Somente depois dessas verificações o adaptador chama o serviço responsável.

É nessa fronteira que entram políticas, permissões e validações. Elas não formam outro componente nem uma dimensão separada no CoALA. São controles transversais aplicados pelo orquestrador e pela implementação das ferramentas para:

• validar identidade e autorização;
• conferir argumentos e regras de negócio;
• disponibilizar ações diferentes conforme o contexto;
• controlar o que pode ser gravado na memória;
• solicitar confirmação para operações sensíveis;
• impedir ações fora do escopo do agente.

O resultado da ferramenta retorna primeiro ao orquestrador como uma observação. Essa observação é tratada como dado potencialmente não confiável, registrada na memória e, quando necessário, enviada ao modelo para uma nova interpretação. Um retorno como { status: "shipped", expectedDate: "2026-08-18" }, por exemplo, ainda precisa ser transformado em uma resposta compreensível.

Por isso, “ação” é um conceito mais amplo do que tool calling. Ferramentas representam uma parte importante do espaço de ações, mas o agente também raciocina, recupera informações, atualiza memória e se comunica com o usuário.

Base de conhecimento

A base de conhecimento reúne informações sobre o domínio: documentos, manuais, catálogos, registros e outros fatos que podem ser necessários durante uma tarefa. Diferentemente da memória, ela não representa a posição do agente em uma execução específica. Seu papel é oferecer material recuperável para fundamentar uma decisão.

No CoALA, esse conteúdo corresponde principalmente à memória semântica de longo prazo. Separá-lo da memória de execução torna explícita uma diferença prática: o histórico informa o que aconteceu na tarefa, enquanto a base de conhecimento informa o que o sistema sabe sobre o domínio.

O modelo não precisa acessar essa base diretamente. Quando identifica a necessidade de informação, ele propõe uma ação de recuperação. O orquestrador seleciona a ferramenta adequada, a ferramenta realiza a consulta e o resultado retorna como observação. Depois de registrado na memória, esse conteúdo pode ser incluído no contexto de uma nova chamada ao modelo.

Bancos relacionais, armazenamentos de documentos, mecanismos de busca e índices vetoriais podem implementar partes da base de conhecimento. A tecnologia não define o componente: um banco vetorial ajuda a localizar conteúdo por similaridade, mas não representa sozinho todas as fontes, regras de atualização e critérios de qualidade.

Atualizar a base de conhecimento é uma ação de aprendizagem e exige controles próprios. Proveniência, validade, autorização e revisão determinam se uma informação pode influenciar execuções futuras. Regras que precisam ser aplicadas de forma determinística, como autorização e limites de transação, devem permanecer em código controlado; a base pode descrevê-las, mas não deve ser a única responsável por aplicá-las.

O fluxo completo de uma execução

O relacionamento entre os componentes fica mais claro quando acompanhamos uma solicitação do início ao fim:

---
config:
  theme: redux
---
sequenceDiagram
    autonumber
    actor U as Usuário
    participant O as Orquestrador
    participant MEM as Memória
    participant MOD as Modelo
    participant FER as Ferramentas
    participant BC as Base de conhecimento

    U->>O: Envia solicitação
    O->>MEM: Carrega estado
    MEM-->>O: Retorna estado e observações

    loop Enquanto a solicitação estiver em andamento
        O->>MOD: Envia o contexto
        MOD-->>O: Propõe o próximo passo
        O->>O: Seleciona o passo e aplica os controles

        alt Responder ao usuário
            O->>MEM: Salva o estado final
            MEM-->>O: Confirma a persistência
            O-->>U: Entrega a resposta
        else Operar no ambiente
            O->>FER: Executa uma ferramenta
            FER-->>O: Retorna uma observação
            O->>MEM: Registra a observação
            MEM-->>O: Confirma a persistência
        else Recuperar conhecimento
            O->>FER: Executa a ferramenta de recuperação
            FER->>BC: Consulta informações
            BC-->>FER: Retorna conteúdo relevante
            FER-->>O: Retorna uma observação
            O->>MEM: Registra a observação
            MEM-->>O: Confirma a persistência
        end
    end

O usuário pergunta: “Onde está o pedido 123 e qual é o prazo para devolução?”. A interface autentica a requisição, identifica a sessão e entrega a mensagem ao orquestrador. Em seguida, o estado é carregado da memória e atualizado com a nova entrada.

O orquestrador monta o contexto contendo a pergunta, os dados necessários do usuário e as ferramentas disponíveis. O modelo interpreta a intenção e propõe a chamada de consultarPedido. O orquestrador seleciona essa proposta, aplica as validações necessárias e executa a ferramenta, que consulta o serviço de pedidos e devolve o status da entrega.

Esse retorno é registrado na memória como uma observação e inicia uma nova decisão. Como a solicitação também exige informações sobre devolução, o modelo propõe uma ferramenta de recuperação. Ela consulta a base de conhecimento e retorna os trechos relevantes da política de devolução, que também são incorporados ao estado.

Com as duas observações disponíveis, o orquestrador prepara um novo contexto e o modelo propõe a resposta final. A comunicação com o usuário passa pelos controles aplicáveis antes de o estado ser salvo na memória e a interface entregar a mensagem.

Cada componente participa do fluxo com uma responsabilidade distinta. O orquestrador mantém o ciclo; o modelo interpreta e propõe; a memória preserva o estado; as ferramentas executam consultas; e a base de conhecimento fornece informações do domínio. No vocabulário do CoALA, a interpretação é raciocínio, as consultas e a resposta são ações, os resultados são observações e a repetição que conecta esses passos é o procedimento de decisão.

O aspecto essencial é que o resultado da ferramenta não encerra automaticamente a tarefa. Ele é incorporado ao estado do agente e passa a influenciar a próxima decisão. É essa realimentação que transforma uma sequência de chamadas independentes em um comportamento orientado por objetivo.

Considerações

Nenhum desses componentes, isoladamente, constitui um agente. O orquestrador mantém o ciclo, o modelo interpreta e produz possibilidades, a memória preserva o estado, as ferramentas realizam operações, e a base de conhecimento oferece informações sobre o domínio. Políticas, permissões e validações atravessam essas relações para limitar o que pode acontecer.

Levar essa anatomia à prática não exige começar por uma plataforma complexa. Um backend modular já consegue separar as responsabilidades principais. Cinco princípios ajudam a manter o desenho compreensível:

1. Mantenha o estado explícito. Objetivos, observações e etapas devem poder ser inspecionados, persistidos e recuperados.
2. Crie ferramentas pequenas. Cada integração e operação de memória deve ter uma responsabilidade e um contrato bem definidos.
3. Separe proposta, autorização e execução. O modelo sugere; o orquestrador seleciona; controles validam; código controlado executa.
4. Defina condições de parada. Limites de repetição, erros, tempo e intervenção humana fazem parte do fluxo.
5. Comece com o menor conjunto de ferramentas necessário. Mais ferramentas aumentam a capacidade, mas também tornam a decisão e a segurança mais difíceis.

Observabilidade, avaliação e auditoria atravessam todos esses componentes. Para entender uma execução, é necessário reconstruir qual estado foi utilizado, o que o modelo propôs, como a ação foi selecionada, qual política foi aplicada, o que foi executado e qual resultado retornou.

Espero que esse texto te ajude de algum jeito. E obrigado por ler até o final e se dispor a ouvir o que tenho a dizer.

Obrigado! (:

Referências

• Albada, Michael. Building Applications with AI Agents: Designing and Implementing Multiagent Systems. O'Reilly Media, 2025.
• Sumers, Theodore R.; Yao, Shunyu; Narasimhan, Karthik; Griffiths, Thomas L. Cognitive Architectures for Language Agents. 2024.
• Yao, Shunyu et al. ReAct: Synergizing Reasoning and Acting in Language Models. 2022.