Um incidente recente expôs parcialmente a arquitetura interna de um CLI de agente de codificação com IA amplamente usado. A internet reagiu com curiosidade. Alguns trataram como vazamento. Outros como fofoca. Para equipes que constroem sistemas agênticos em produção, o sinal real era arquitetural.
O que veio a público não foi apenas um prompt. Foi um runtime. E é no runtime que sistemas se tornam confiáveis, ou falham em silêncio.
O que o incidente realmente revelou
Quando as pessoas falam sobre agentes de IA, normalmente falam sobre modelos. Qual modelo é mais inteligente. Qual é mais rápido. Qual pontua melhor em benchmarks. A arquitetura exposta apontou para uma realidade diferente.
O modelo era um componente substituível dentro de um sistema muito maior. A complexidade real não estava no modelo em si. Estava em tudo o que existe ao redor dele:
- Governança de ferramentas
- Gerenciamento de estado
- Controle de execução
- Camadas de permissão
- Coordenação de streaming
- Renderização de UI
Nada disso mora dentro do modelo. Tudo isso mora no runtime.
O modelo raciocina sobre o que recebe. O runtime decide o que isso será.
Este é o ponto que muitas equipes ainda deixam passar.
Governança de ferramentas
Em sistemas agênticos de produção, ferramentas não são funções abertas que o modelo pode chamar livremente. Elas são capacidades governadas. Cada ferramenta carrega um contexto. Cada ferramenta tem limites de permissão. Cada ferramenta tem regras explícitas sobre quando e como pode ser invocada.
Isto não é uma preferência de design. É uma exigência. Em ambientes regulados, como financeiro e jurídico, uma chamada de ferramenta sem controle não é apenas um bug. É um incidente de compliance.
O runtime precisa definir o que o modelo está autorizado a fazer, não o contrário.
Governança de ferramentas significa que o sistema define os limites. O modelo opera dentro deles. Se o seu agente trata chamadas de ferramenta como despacho irrestrito de funções, você construiu um passivo, não um produto.
O loop de eventos como máquina de estados
Se o seu agente é apenas um loop em volta de uma chamada de API, você não tem um sistema. Você tem uma demo.
Agentes de produção não funcionam assim. Em um agente bem construído, o loop de eventos é uma máquina de estados com transições incrementais. Ele lida com emissão de tokens em streaming e execução de ferramentas como preocupações separadas, mas coordenadas. Processa resultados parciais, gerencia interrupções, resolve retries e coordena caminhos paralelos de execução.
Essa distinção importa no nível de implementação. Emissão de eventos não é a mesma coisa que mutação de estado. Enviar um token para a UI é um evento. Concluir uma chamada de ferramenta e atualizar o contexto de execução é outro. O runtime precisa separar essas coisas com clareza, ou o sistema se torna imprevisível sob carga real.
Isto é orquestração orientada a eventos. A distância entre isso e um while com uma chamada de API dentro é a distância entre uma demo e um sistema.
Orquestração e separação de responsabilidades
Outro padrão que apareceu com clareza é a separação entre execução e coordenação. Em arquiteturas multiagente, isso normalmente significa um coordenador que planeja e delega, e workers que executam dentro de limites definidos.
O princípio é familiar em sistemas distribuídos: menor privilégio. Cada componente recebe acesso apenas ao que precisa. Aplicado a agentes, o orquestrador não deve executar toda ferramenta diretamente. Workers não devem decidir a estratégia do sistema. Cada camada tem um papel. O runtime faz valer esse isolamento.
Isso vai além da separação de papéis. Inclui modelos de delegação com limites explícitos de tarefa, isolamento de domínios de falha para que um worker não corrompa outro e estratégias de contenção para que uma chamada de ferramenta com falha não escale para a camada de orquestração.
Em produção, auditabilidade não é opcional. Toda decisão, toda delegação e toda invocação de ferramenta precisam ter um caminho rastreável pelo runtime.
UI como superfície de execução
Um dos padrões menos óbvios, mas mais importantes, está em como a camada de UI funciona. Nesses sistemas, o terminal não está apenas renderizando saída. Ele está renderizando execução.
A arquitetura frequentemente usa um modelo declarativo, parecido com a forma como o React funciona. Componentes descrevem o que deve aparecer com base no estado atual. O sistema atualiza a tela de forma incremental por streaming. O ponto não é estética. É visibilidade.
A UI é uma projeção do fluxo de eventos. É uma superfície de depuração. É a camada de controle do operador. Quando um agente transmite sua execução em tempo real, ele torna o estado interno visível:
- Quais ferramentas estão sendo chamadas
- Quais decisões estão sendo tomadas
- Em que ponto do grafo de execução o sistema está
Em produção, isto não é um extra conveniente. É observabilidade. Sem isso, você opera no escuro.
Controle sobre a inteligência
Todos esses padrões apontam para a mesma conclusão. Sistemas agênticos confiáveis não são construídos tornando o modelo mais inteligente. Eles são construídos tornando o runtime mais forte.
Governança sobre ferramentas. Gerenciamento de estado por loops orientados a eventos. Orquestração com isolamento e contenção de falhas. UI como superfície de observabilidade. Esses pontos não são secundários. Eles são a arquitetura.
As equipes que entendem isso não estão apenas correndo atrás do próximo lançamento de modelo. Elas estão construindo a infraestrutura que torna qualquer modelo seguro para operar. O modelo gera saídas. O runtime decide o que vira ação.
O que isso significa em produção
O incidente não foi importante por causa do que foi exposto. Foi importante por causa do que ele confirmou. Os melhores sistemas agênticos do mundo não são construídos em torno de prompts. São construídos em torno de controle de runtime.
Se você está construindo agentes hoje, a pergunta não é apenas qual modelo você usa. A pergunta é como seu runtime se parece. Como você governa ferramentas. Como gerencia transições de estado. Como separa coordenação de execução. Como torna o sistema observável, auditável e contido.
Em produção, inteligência não é o que o sistema sabe. É o que o sistema está autorizado a fazer.
Inteligência precisa ser estruturada antes de ser escalada. Confiável antes de autônoma.