Cada vez mais escuto pedidos que começam de uma forma parecida:

“Precisamos de um agente.”

Ou:

“Poderíamos resolver isso com IA.”

É compreensível. Os LLMs e os agentes abriram possibilidades que há poucos anos eram difíceis de imaginar, e hoje podemos automatizar tarefas que antes exigiam necessariamente a intervenção de uma pessoa.

Mas existe um risco em começar a conversa pela tecnologia.

Muitas vezes, depois de entender o processo, descobrimos que não precisávamos de um agente. Precisávamos de uma integração entre dois sistemas, uma regra de negócio mais bem definida, um processo mais claro ou simplesmente um desenvolvimento tradicional.

A pergunta interessante deixa de ser:

Como podemos resolver isso com IA?

E passa a ser:

Qual é o problema que realmente estamos tentando resolver?

Muitas vezes o pedido já chega com a solução incluída

Isso não começou com a inteligência artificial.

Há anos escutamos pedidos como:

“Precisamos de um dashboard.”

“Precisamos trocar o sistema.”

“Precisamos automatizar este processo.”

“Precisamos de uma nova aplicação.”

Agora simplesmente adicionamos mais um:

“Precisamos de um agente.”

Não há nada de errado em um stakeholder chegar com uma solução proposta. Quem trabalha todos os dias com um processo provavelmente conhece aspectos do problema muito melhor do que Tecnologia e, em muitos casos, sua proposta pode estar correta.

O erro seria tratar essa primeira solução como uma especificação e começar imediatamente a construir.

Quando alguém me apresenta uma necessidade, tento começar com perguntas muito mais básicas:

Qual é o problema?

Qual resultado esperamos obter?

A partir daí começa uma conversa.

O que acontece hoje? Onde está a dor? Quanto trabalho isso gera? Quem participa? Quais exceções existem? De quais informações uma pessoa precisa para tomar uma decisão?

Muitas vezes, enquanto respondemos a essas perguntas, a solução original começa a se transformar sozinha.

Antes de escolher a tecnologia, entender o sistema

Gosto de organizar essa conversa em cinco etapas.

1. Problema

O que realmente está acontecendo?

Esse ponto deve ser explicado principalmente por quem vive o processo todos os dias. Tecnologia pergunta, escuta e tenta separar o problema da solução proposta.

Não qual sistema queremos construir.

Não qual tecnologia queremos incorporar.

Qual problema existe.

2. Resultado

O que deveria ser diferente quando terminarmos?

Negócio e Tecnologia devem concordar sobre um resultado observável: reduzir tempos, diminuir erros, eliminar tarefas repetitivas, melhorar conversão, reduzir custos, controlar riscos ou permitir crescimento.

O resultado deve poder ser explicado independentemente da tecnologia.

3. Dor

Onde realmente são gerados o custo, o atraso ou a fricção?

Vale percorrer o processo com quem o executa, porque a dor visível nem sempre se origina onde está o problema.

Uma equipe pode pedir para automatizar a carga manual de informações em um sistema, por exemplo. Mas, ao percorrer o processo, podemos descobrir que essa carga existe porque outro sistema gera informações incompletas.

Automatizar a carga ataca a dor.

Corrigir a origem da informação ataca o problema.

4. Restrições

O que não podemos simplificar?

Regulação, segurança, privacidade, decisões humanas, sistemas existentes, regras de negócio ou integrações com terceiros.

Negócio traz as restrições do domínio. Tecnologia ajuda a separar quais são realmente inerentes ao problema e quais são consequência de decisões anteriores.

5. Solução

Só então Tecnologia deveria propor alternativas.

E há uma pergunta que gosto de fazer:

Qual é a solução mais simples que atende a tudo o que vimos acima?

Pode ser IA.

Mas também pode ser uma API, uma regra, um formulário, uma automação tradicional, uma mudança de processo ou até mesmo a decisão de não construir nada.

Essas cinco etapas não precisam se transformar em burocracia. Muitas vezes, trinta minutos diante de um quadro com as pessoas certas são suficientes.

O valor não está em completar um framework.

Está em adiar a escolha da tecnologia até termos entendido o problema.

Para que precisamos que ele raciocine?

Isso se tornou especialmente relevante com o surgimento dos agentes.

Imagine um processo operacional comum.

Uma pessoa consulta informações em um sistema, verifica cinco condições perfeitamente definidas, pega um valor e o insere em outro sistema.

Poderíamos construir um agente para fazer isso.

Mas existe uma pergunta anterior:

Para que precisamos que ele raciocine?

Se as entradas são estruturadas, as cinco regras são conhecidas e, diante das mesmas condições, esperamos sempre o mesmo resultado, provavelmente estamos diante de um problema determinístico.

Talvez precisemos de uma integração e cinco regras.

Não de um agente.

E a diferença é concreta.

Um agente envolve chamadas ao modelo, avaliação de respostas, observabilidade, gestão do não determinismo e novos modos de falha.

Uma integração com cinco regras, em um caso simples, pode exigir pouco desenvolvimento e ser testada com testes unitários completamente reproduzíveis.

Isso não torna a segunda solução menos tecnológica.

Torna-a mais adequada ao problema.

Determinístico não significa necessariamente hardcoded

Existe outra nuance importante.

O fato de hoje conseguirmos expressar um processo por meio de cinco regras não significa que essas regras sejam estáveis.

Talvez mudem todos os meses.

Talvez o negócio precise modificá-las sem esperar um deployment.

Isso também não significa automaticamente que precisamos de um agente.

Pode significar que precisamos de configuração.

As regras podem viver fora do código, ser versionadas, auditadas e modificadas pelas pessoas adequadas.

Passamos então a ter três problemas diferentes:

  • regras conhecidas e estáveis → lógica determinística;
  • regras conhecidas, mas que mudam com frequência → configuração;
  • decisões cujo caminho depende de contexto, informações ambíguas ou raciocínio → aqui um LLM ou agente começa a se tornar muito mais interessante.

A arquitetura deve responder à natureza do problema, não à ferramenta que queremos utilizar.

A solução mais sofisticada não é necessariamente a mais inteligente

Em Building Effective Agents, a Anthropic recomenda encontrar a solução mais simples possível e aumentar a complexidade apenas quando necessário. Também destaca um trade-off importante: sistemas agênticos podem melhorar o desempenho em determinadas tarefas em troca de maior custo e latência.

A Microsoft, por sua vez, descreve diferentes pontos de um espectro entre agentes que decidem dinamicamente o que fazer e workflows cujo comportamento é controlado de forma determinística.

Não existe uma única arquitetura correta.

Se precisamos interpretar linguagem não estruturada, compreender contexto, trabalhar com informações ambíguas, escolher ferramentas dinamicamente ou resolver situações cujo caminho não pode ser definido previamente, um LLM pode agregar muito valor.

Mas se temos:

Se A e B acontecerem → executar C

escrever exatamente isso pode ser uma solução extraordinariamente boa.

Usar uma tecnologia mais sofisticada não torna automaticamente uma solução mais inteligente.

A simplicidade também tem uma arquitetura

Dizer “vamos fazer da forma mais simples” não significa escolher sempre a menor solução possível.

Uma solução simples ainda precisa ser segura, observável, sustentável e capaz de responder às necessidades reais do negócio.

Mas deve evitar a complexidade de que não precisamos.

Em 1986, Frederick Brooks apresentou em No Silver Bullet uma distinção que continua útil quarenta anos depois: em software existe complexidade essencial, inerente ao problema que tentamos resolver, e complexidade acidental, introduzida pelas ferramentas e mecanismos que usamos para resolvê-lo.

Essa distinção é particularmente relevante hoje.

Temos ferramentas extraordinariamente poderosas.

E, justamente por isso, temos muito mais oportunidades de introduzir complexidade acidental.

Alguns problemas são genuinamente complexos

O erro oposto seria levar a simplicidade longe demais.

Simples não significa simplista.

Trabalhando com problemas relacionados à saúde, isso fica muito evidente.

Visto de fora, um processo pode parecer desnecessariamente complexo. Depois começamos a entendê-lo.

Existem regulações. Privacidade. Rastreabilidade. Diferentes atores. Sistemas que precisam interoperar. Exceções clínicas. Requisitos de auditoria. Informações que não podem ser tratadas de qualquer maneira.

Podemos tentar simplificar a solução tecnológica.

Mas não podemos fazer desaparecer a complexidade do domínio simplesmente porque ela nos incomoda.

Não se trata de eliminar toda a complexidade. Trata-se de eliminar a complexidade que nós adicionamos desnecessariamente.

Se o problema é complexo, a solução provavelmente terá que representar parte dessa complexidade.

O que não precisamos é adicionar outra camada apenas porque uma tecnologia está na moda.

Escutar faz parte do trabalho de tecnologia

Uma parte importante do trabalho de um líder de tecnologia acontece antes de discutir arquitetura.

Acontece escutando.

Um stakeholder pode dizer:

“Preciso automatizar isso.”

Nossa responsabilidade não deveria ser responder imediatamente com um diagrama.

Precisamos entender o que ele faz hoje, por que faz, quais informações utiliza, onde perde tempo, quais erros aparecem e qual resultado precisa alcançar.

E há algo importante nisso:

Tecnologia não necessariamente conhece melhor o problema.

A pessoa que trabalha todos os dias com um processo possui um conhecimento que nós não temos.

Nossa contribuição está em combinar esse conhecimento do negócio com nossa capacidade de observar o sistema de outra perspectiva.

O melhor resultado não surge quando Tecnologia impõe uma solução.

Surge quando Negócio e Tecnologia entendem juntos o problema.

Mas perguntar também tem um custo

Também podemos errar na direção oposta.

Podemos passar semanas tentando entender perfeitamente um problema antes de construir qualquer coisa.

Isso também nem sempre faz sentido.

Existem situações em que o stakeholder não consegue explicar completamente o que precisa até ver algo funcionando.

Nesses casos, um protótipo de dois dias pode nos ensinar mais do que duas semanas de reuniões.

Discovery não deve se transformar em paralisia.

O objetivo não é entender absolutamente tudo antes de avançar.

É entender o suficiente para que construir se torne a próxima forma mais barata de aprender.

Às vezes precisamos perguntar.

Às vezes precisamos modelar o processo.

E às vezes precisamos construir algo pequeno, colocá-lo diante do usuário e continuar aprendendo a partir daí.

A IA torna essa conversa ainda mais necessária

Paradoxalmente, quanto melhores se tornam nossas ferramentas, mais importante fica essa distinção.

Hoje conseguimos construir software muito mais rapidamente.

Podemos gerar código, integrar sistemas, processar documentos, interpretar linguagem e criar agentes capazes de utilizar ferramentas.

Isso reduz muito o custo de construir algumas soluções.

Mas não reduz automaticamente o custo de construir a solução errada.

Pode até acelerá-lo.

Podemos passar meses construindo algo errado. Ou podemos construí-lo errado em três dias.

A velocidade mudou.

A necessidade de entender o problema, não.

Primeiro o problema. Depois a tecnologia.

Eu adoro tecnologia.

É justamente por isso que tento não começar por ela.

O valor de uma tecnologia não está em quão sofisticada ela é, mas em qual problema nos permite resolver e a que custo.

Um agente pode ser a solução correta.

Um modelo de IA também.

Mas uma API, uma regra de negócio ou vinte linhas de código podem ser uma decisão tecnológica igualmente boa — ou melhor.

E, às vezes, depois de entender realmente o processo, podemos descobrir que o problema nem sequer precisava de software.

Por isso, quando alguém chega dizendo:

“Precisamos de um agente.”

minha primeira pergunta continua sendo:

“Qual problema queremos resolver?”

E depois de entender o problema, o resultado esperado, as dores e as restrições, acrescentaria mais uma:

“Qual é a forma mais simples de resolvê-lo bem?”

Para mim, é aí que começa uma boa decisão tecnológica.

Não quando escolhemos a ferramenta.

Quando entendemos o problema.

Fontes e leituras