Dentro de um Agente de IA Corporativo: Uma Arquitetura Prática

“Agente” costuma ser tratado como se descrevesse uma coisa única: ou você tem um agente, ou não tem. Na prática, porém, todo agente que já vi funcionar — construído internamente ou comprado como produto — se organiza em uma cadeia de sete etapas. E quase nada da engenharia mais interessante acontece na etapa de que todo mundo mais fala.

Visão geral do fluxo, do gatilho à saída

1 - A primeira etapa é o gatilho: um pedido do usuário, uma tarefa programada ou um evento de outro sistema. Parece simples, mas importa porque determina quanto contexto já está disponível no início. Um agente acionado por uma mensagem no Slack, por exemplo, começa com menos contexto do que um acionado por um formulário estruturado.

2 - A segunda etapa reúne objetivo e permissões. Antes de agir, o sistema precisa transformar “me ajude a preparar essa ligação de renovação” em uma tarefa concreta — e saber o que aquele usuário, naquele contexto, tem permissão para ver e fazer. Muitos projetos internos de agentes cortam caminho aqui sem perceber: usam permissões amplas de uma conta de serviço, em vez de respeitar o acesso real da pessoa que fez o pedido.

Recuperação de contexto respeitando os limites de acesso

3 - A terceira etapa é a recuperação: reunir o contexto e os dados necessários para executar a tarefa. É uma das etapas mais subestimadas de toda a cadeia. O desafio não é simplesmente “buscar em um banco de dados”; é encontrar os documentos, tickets e conversas certos entre tudo o que a empresa já registrou — e fazer isso rápido o bastante para que o usuário quase não perceba a espera. Já vi essa etapa, mais do que qualquer outra, determinar se um piloto dá certo ou acaba abandonado silenciosamente.

4 - A quarta etapa é o raciocínio: o modelo decide o que fazer com o contexto recuperado. É a etapa que ganha as manchetes e, sinceramente, a que menos me preocupa. Os modelos de ponta de hoje já são bons nisso.

5 - A quinta etapa é a ação: chamar uma ferramenta, acionar uma API ou gravar em um sistema. É aqui que o agente deixa de ser apenas um chatbot e passa a produzir consequências. Por isso, as permissões definidas na segunda etapa precisam ser reforçadas também neste momento — não basta verificá-las uma única vez, no início.

6 - A sexta etapa é a validação: conferir a ação com base em regras. Para algo irreversível, a checagem deve acontecer antes da execução. Para ações de baixo risco e fáceis de desfazer, pode acontecer depois. Na minha opinião, é a etapa que mais implantações corporativas de agentes ignoram ou subdimensionam — e um dos pontos centrais nas conversas sobre governança.

Validação antes de uma ação chegar ao sistema

7 - A sétima etapa é a saída: o resultado chega a uma pessoa ou alimenta a próxima etapa de uma cadeia maior. Vale desenhá-la com cuidado. Se ninguém confia no resultado, ninguém vai usá-lo — por melhor que tenham funcionado as seis etapas anteriores.

No meu trabalho na Glean, percorro alguma versão desse diagrama com clientes quase toda semana. O padrão se repete: os times investem demais na etapa 4 e de menos nas etapas 2, 3 e 6. O modelo raramente é o gargalo; o pipeline de contexto e as salvaguardas quase sempre são.

Meu conselho prático: antes de avaliar um produto “agente” pela inteligência do modelo, peça para ver a arquitetura dividida nessas sete etapas. Os fornecedores que conseguem mostrar o próprio diagrama, etapa por etapa, geralmente já pensaram no que fazer quando algo dá errado.