“Onde está meu pedido?” e “Vocês prometeram a entrega ontem, a transportadora diz outra coisa e preciso mudar o endereço” podem chegar à mesma caixa de entrada com um minuto de diferença. Para a equipe de atendimento, são trabalhos distintos. A primeira pergunta talvez se resolva consultando um registro; a segunda exige entender o que aconteceu antes de preparar uma resposta.
Essa diferença cotidiana merece pesar mais na arquitetura do que a vontade de adotar um agente de IA. Leve as duas solicitações para a conversa sobre automação: quais passos já são conhecidos e em que momento começa uma investigação? É a partir daí que a escolha entre workflow, agente ou uma combinação dos dois ganha utilidade para quem vai operar a solução.
Quem decide qual será o próximo passo?
Um workflow determinístico segue uma sequência e condições estabelecidas por quem o desenvolveu. Ele recebe dados, verifica requisitos, consulta sistemas e executa ações conforme regras explícitas. Nesse contexto, determinístico descreve o controle do caminho. Uma integração externa ou um componente de IA pode continuar produzindo resultados variáveis.
Um agente utiliza um modelo para decidir parte desse caminho: quais informações buscar, qual ferramenta consultar ou quando encerrar a investigação. Essa flexibilidade pode ajudar quando as entradas e etapas intermediárias não são completamente previsíveis. A distinção da Anthropic entre workflows e agentes diferencia caminhos predefinidos de decisões dinâmicas. Nenhuma categoria representa, sozinha, maior maturidade. A arquitetura adequada é aquela que atende ao objetivo com níveis aceitáveis de custo, prazo e risco operacional.
Vale separar três tipos de incerteza. A primeira está na entrada: um formulário estruturado ou um e-mail ambíguo. A segunda está no caminho: etapas conhecidas ou uma investigação dependente de resultados intermediários. A terceira está no sucesso: um resultado verificável ou uma resposta que exige julgamento.
Receber texto livre não obriga a criar um agente. Um modelo pode extrair campos propostos de uma mensagem. Depois, regras convencionais validam os valores e escolhem o próximo passo. O processo mantém um caminho previsível mesmo incorporando interpretação. A autonomia ganha utilidade quando o sistema precisa escolher entre diferentes consultas e ajustar sua estratégia conforme os resultados. Ainda assim, o conjunto de decisões disponíveis deve ser limitado. Autonomia operacional precisa ter um propósito claro e uma fronteira verificável.
Um pedido, dois caminhos possíveis
Voltemos à caixa de entrada de uma distribuidora imaginária. O cliente quer alterar o endereço porque a entrega atrasou. Antes de interpretar a reclamação, o sistema precisa identificar o pedido e conferir se aquela pessoa pode consultá-lo. Um workflow consegue realizar essas verificações com regras explícitas; depois, um componente de IA interpreta a solicitação e sugere como continuar.
Se o pedido ainda estiver em preparação, consultar a política de alteração talvez seja suficiente. Se os registros do armazém e da transportadora forem contraditórios, um agente limitado pode buscar mensagens anteriores ou pedir a informação que falta. A autonomia entra nessa investigação, onde tem uma função concreta, sem se espalhar automaticamente pelo processo inteiro.
A fronteira decisiva aparece na hora de agir. Consultar pedidos, recuperar mensagens e propor uma solução são ferramentas diferentes de alterar endereços ou conceder compensações. Estas últimas precisam de validações e aprovações próprias. Uma mensagem persuasiva do cliente não muda a política comercial; da mesma forma, uma resposta convincente do agente não comprova sua autorização para executá-la. Essa separação também ajuda a equipe a reconstruir o caso quando alguma coisa dá errado.
Até onde cada ferramenta pode ir
Cada ferramenta deve representar uma operação de negócio reconhecível, com parâmetros, validações e resultados definidos. “Atualizar cliente” é amplo demais se permitir alterar qualquer campo. “Propor correção do telefone de contato” tem um escopo mais compreensível e controlável. A autorização precisa ser verificada pelo sistema que realiza a ação. Uma instrução dizendo para não modificar dados sensíveis não substitui permissões técnicas. Separe ferramentas de leitura e escrita, registre a identidade solicitante e mantenha um identificador do caso ao longo das chamadas.
Estabeleça limites de iterações, tempo e gasto. Ao atingir um limite, o processo deve entregar a uma pessoa um estado útil: o que foi consultado, o que foi encontrado e o que falta resolver. Investigar indefinidamente não significa atender melhor.
Uma boa resposta também pode estar errada
Antes de ampliar a autonomia, reúna casos representativos. Inclua solicitações completas, mensagens ambíguas, registros contraditórios e indisponibilidade de serviços. Defina antecipadamente o resultado esperado para cada situação. Avalie o workflow tradicional, a alternativa híbrida e o agente usando esse mesmo conjunto. Meça resolução correta, erros que chegam ao cliente, intervenção humana, tempo de resposta e custo por caso concluído. Repita testes probabilísticos para observar variação.
Não use apenas a aparência da resposta como critério. O sistema pode escrever um texto convincente após consultar o pedido errado. A avaliação precisa examinar o resultado de negócio e as ações realizadas, além da qualidade da linguagem. Analise falhas graves separadamente. Uma saudação inadequada e uma devolução não autorizada não podem desaparecer dentro de uma única média de qualidade.
Quanto custa manter essa flexibilidade
O consumo do modelo é somente uma parcela. Também entram na conta consultas a ferramentas, armazenamento, monitoramento, novas tentativas, revisão humana e manutenção. Uma solução com menos tokens pode custar mais se exigir correções frequentes.
Em processos estáveis e repetidos, regras explícitas normalmente oferecem uma base simples de operar. Em investigações variáveis, a mesma rigidez pode criar uma fila crescente de exceções. Compare o custo completo considerando a frequência real de cada cenário. Documente a melhoria que justifica acrescentar complexidade. Um exemplo seria resolver corretamente mais casos sem aumentar ações indevidas. Esse compromisso é mais útil do que uma meta genérica de utilizar agentes em todos os departamentos.
Considere ainda o custo das mudanças. Se as regras comerciais mudam frequentemente, a equipe precisa conseguir atualizar, testar e comunicar essas alterações sem interromper o atendimento.
A arquitetura continuará mudando depois da implantação. Uma nova política comercial, a troca de uma integração ou uma exceção inesperada trará outras decisões. Alguém do negócio precisa definir os resultados aceitáveis, enquanto um responsável técnico cuida de permissões, avaliações e implantação. Sem esses papéis, cada incidente corre o risco de virar uma nova negociação sobre o que a solução deveria fazer.
Quando surgir a proposta de “colocar um agente” naquela caixa de entrada, peça uma comparação entre as duas solicitações do início. Se um workflow atende bem à primeira, a autonomia adicional precisa de justificativa. Se uma investigação limitada melhora a segunda, existe uma hipótese concreta para testar. A DigitalCube pode ajudar nessa conversa a partir dos seus casos, das exceções que chegam à equipe e dos resultados que a operação precisa preservar.