O divertido nas aulas que ministro são as perguntas que nos fazem repensar. Uma delas foi: “um sistema de agentes com LLM pode ser descrito como uma camada de orquestração determinística em torno de sistemas probabilísticos?”

A pergunta é boa. Captura uma intuição correta, mas ainda incompleta. Em muitos casos, é possível descrever esses sistemas dessa forma,  com uma camada de controle estruturada (fluxos, regras, chamadas de ferramentas) organizada de maneira previsível, enquanto os modelos operam sobre probabilidades. Mas na prática, essa “orquestração determinística” é mais bem descrita como controlada do que verdadeiramente determinística. Mesmo em pipelines rígidos ou DAGs, há variabilidade, com parsing de respostas, dependência de APIs externas, retries e timeouts. O comportamento é mais previsível, mas não estritamente determinístico no sentido clássico.

Além disso, essa definição não se sustenta em todos os cenários. Em arquiteturas mais abertas, o próprio LLM passa a participar da tomada de decisão. Ele escolhe ferramentas, define próximos passos e decompõe tarefas. Aqui, é importante separar dois níveis de decisão: o de controle de fluxo (qual caminho seguir, qual tool acionar) e o de conteúdo (o que gerar como resposta). Quando o modelo começa a influenciar o fluxo, a lógica de controle deixa de ser apenas estruturada e passa a incorporar incerteza.

E isso muda bastante coisa. Esses sistemas são sensíveis a pequenas variações. Ajustes no prompt, no contexto ou até na ordem das informações podem levar a caminhos diferentes de execução. Não é ausência total de previsibilidade, mas uma redução significativa da reprodutibilidade estrita. Em sistemas com múltiplos loops de decisão, o comportamento pode se tornar emergente e difícil de antecipar.

Por isso, uma descrição mais precisa é tratar esses sistemas como arquiteturas híbridas, onde coexistem zonas de controle mais rígido e zonas de incerteza probabilística. O ponto central não é eliminar a incerteza, mas decidir onde ela é aceitável e onde não é.

Essa distinção tem implicações práticas. A primeira é ajustar a expectativa de reprodutibilidade. Ela não desaparece, mas deixa de ser absoluta. Isso torna essencial o uso de logs detalhados, versionamento de prompts e rastreabilidade. Mas aqui existe um risco comum: a ilusão de controle. Ter logs não significa entender o sistema. Observabilidade real exige instrumentação semântica, como métricas de qualidade, avaliação de respostas, tracing de decisões, e não apenas telemetria.

A segunda é separar explicitamente o que deve ser determinístico do que pode ser probabilístico. Regras críticas, validações e invariantes não devem ser delegadas ao modelo. Código tradicional continua sendo o mecanismo mais confiável para garantir esse tipo de comportamento. Uma prática comum é manter o fluxo sob controle explícito e restringir o modelo ao conteúdo.

Também é necessário introduzir mecanismos de contenção: validação de saídas, restrições estruturais, retries com critérios claros e caminhos de fallback. Sem isso, o sistema pode funcionar bem na maior parte do tempo, até falhar de forma difícil de explicar, e mais difícil ainda de reproduzir.

Há ainda decisões arquiteturais frequentemente ignoradas. Nem todo problema precisa de um “agente”. Em muitos casos, pipelines mais simples, com uso pontual de LLMs, são mais previsíveis, mais baratos e mais fáceis de manter.

E custo e latência não são detalhes. Cada decisão probabilística pode gerar novas chamadas, novos loops e muito mais consumo de tokens. Em arquiteturas mais “agentic”, isso escala rapidamente e pode inviabilizar o sistema economicamente. O desenho da arquitetura não impacta apenas o comportamento, mas impacta diretamente o custo por operação e o tempo de resposta.

Por fim, até a forma de testar muda. Não basta validar casos determinísticos. É preciso combinar avaliação offline (benchmarks, datasets de teste) com avaliação em produção (feedback real, monitoramento de drift, regressões). Testar deixa de ser apenas “passou ou falhou” e passa a ser “como o sistema se comporta sob variação”.

E existe um limite importante: controle não é entendimento. Mesmo com toda a estrutura ao redor, o comportamento interno do modelo continua, em grande parte, opaco. Você controla o fluxo, mas nem sempre consegue explicar plenamente a decisão.

Talvez o enquadramento mais útil não seja “determinístico versus probabilístico”, mas controle. A pergunta deixa de ser “o sistema é previsível?” e passa a ser quanto do comportamento está sob controle explícito e quanto está sendo delegado ao modelo? Porque projetar sistemas de agentes com LLMs é, na pratica, decidir onde aceitar incerteza,  e garantir que você sabe exatamente onde ela está.