O problema da marreta
Muitos fluxos de trabalho de IA atuais parecem usar uma marreta para quebrar uma noz.
A tarefa é simples o suficiente: ler uma planilha, verificar novos registros, enriquecer alguns campos, classificar uma solicitação, criar um relatório, atualizar um CRM, enviar uma notificação ou preparar uma resposta para revisão.
Mas, em vez de projetar o processo, as equipes entregam todo o trabalho a um agente e pedem que ele opere o computador como uma pessoa. O agente abre aplicativos, clica em telas, lê linhas, decide o próximo passo, repete as mesmas instruções e gasta tokens redescobrindo um fluxo de trabalho que já era conhecido.
Também existe um custo de disponibilidade. As ferramentas de IA mais capazes costumam ser usadas em sessões limitadas, com limites práticos de uso, limites de taxa ou filas. Se uma equipe gasta essa capacidade em trabalho repetitivo que um software poderia executar de forma determinística, não está apenas desperdiçando tokens. Está consumindo tempo escasso e valioso de modelos. Então, quando surge uma tarefa realmente complexa, a equipe pode voltar a esperar por capacidade.
Isso pode ser útil quando o ambiente é desconhecido ou a tarefa é genuinamente exploratória. Mas nem sempre é a melhor arquitetura para um processo empresarial repetível.
A maioria dos fluxos de trabalho em produção não são problemas de agentes. São problemas de automação com chamadas ocasionais de IA.
Um fluxo de trabalho geralmente é mais estruturado do que parece
Quando analisamos com atenção, muitos fluxos de trabalho de IA seguem uma estrutura previsível.
Eles começam com um gatilho. Às vezes, o gatilho é programado: todas as manhãs, toda sexta-feira, no fim do mês ou após o encerramento de um período de relatório. Às vezes, é baseado em eventos: um e-mail chega, um cliente envia um formulário, um registro é alterado em um banco de dados, um chamado é criado ou um novo arquivo é adicionado a uma pasta.
Em seguida, o fluxo de trabalho obtém os dados de entrada. Eles podem vir de uma API, de um CRM, de um ERP, de uma planilha, de um documento, de um aplicativo web, de um banco de dados existente ou de uma combinação de sistemas.
Depois, ele itera sobre os dados de entrada. Valida registros, filtra casos, normaliza campos, aplica regras, verifica status, cria ramificações com base em condições e prepara resultados.
Apenas algumas etapas realmente precisam de IA.
A IA pode ser necessária para extrair significado de textos não estruturados, classificar uma solicitação, resumir evidências, elaborar uma resposta, comparar documentos, decidir qual caminho de exceção se aplica ou gerar uma recomendação. Mas muitas etapas ao redor são determinísticas. Elas devem ser código, não raciocínio repetido.
Por fim, o fluxo de trabalho armazena ou entrega o resultado. Ele atualiza um banco de dados, grava dados de volta em um CRM, cria um documento, envia um e-mail, abre uma tarefa, publica no Slack ou disponibiliza um dashboard.
Isso não é uma pessoa clicando em telas. É um processo.
Os tokens em tempo de execução devem ser gastos com inteligência
O erro mais caro é usar chamadas de modelo para uma orquestração que o software pode executar diretamente.
Se, a cada execução, um agente precisa ler as mesmas instruções, navegar pelas mesmas telas, inspecionar as mesmas colunas e decidir o mesmo próximo passo óbvio, a empresa está pagando por coordenação repetida, não por inteligência.
O padrão mais eficiente é simples:
- use código determinístico para gatilhos, loops, validação, roteamento, novas tentativas e armazenamento
- use APIs e conectores quando os sistemas já oferecem interfaces confiáveis
- chame a IA apenas nas partes que se beneficiam de compreensão de linguagem, geração, raciocínio ou julgamento
- escolha o modelo certo para cada etapa, em vez de enviar toda tarefa ao modelo mais poderoso
- mantenha rastreamentos, custos, latência, entradas, saídas e falhas visíveis
É daí que vêm as economias de tokens. Não apenas do uso de modelos mais baratos, mas também da eliminação completa de chamadas desnecessárias a modelos.
Nas implementações da Guanta, essa arquitetura pode reduzir drasticamente o uso de tokens porque o modelo deixa de ser responsável por executar todo o processo. A empresa paga pela inteligência de que precisa, quando precisa, usando o modelo adequado para o trabalho.
Com o tempo, algumas partes podem deixar de precisar de chamadas a modelos externos. Modelos menores, classificadores especializados, inferência local, decisões armazenadas em cache, embeddings e código convencional podem assumir uma parcela maior do fluxo de trabalho. A plataforma deve permitir essas escolhas sem exigir a reformulação do processo a cada mudança.
A IA também pertence ao momento de criação
Isso não significa usar menos IA no geral.
Significa usar a IA no lugar certo.
A IA pode ser extremamente útil na criação do fluxo de trabalho. Ela pode ajudar a transformar requisitos em código, gerar conectores, escrever transformações de dados, elaborar lógica de validação, criar pequenas ferramentas internas, produzir testes, explicar APIs legadas e acelerar o trabalho de transformar um processo operacional desorganizado em software.
Mas, quando esse fluxo de trabalho já é conhecido, a empresa não deve continuar pagando para que um modelo gere a mesma lógica repetidamente em tempo de execução.
Use a IA intensivamente durante o design e a construção. Depois, implante o fluxo de trabalho em uma plataforma que o execute de forma confiável. Em tempo de execução, chame a IA apenas quando os dados reais exigirem inteligência.
Essa distinção é importante.
Agentes são bons para descobrir o que fazer quando o problema é ambíguo. Plataformas são boas para executar trabalhos conhecidos de forma confiável, repetida, segura e observável.
A arquitetura mais forte usa ambos. A IA ajuda a criar o fluxo de trabalho. A plataforma executa o fluxo. A IA é acionada dentro dele apenas nos pontos em que gera alavancagem real.
Por que uma plataforma é importante
O trabalho repetível com IA precisa de mais do que prompts.
Precisa de conectores para sistemas empresariais. Precisa de execução programada e baseada em eventos. Precisa de estado, permissões, novas tentativas, filas, logs, segredos, etapas de aprovação humana, controle de versões e controles de implantação.
Também precisa de observabilidade.
Quando um fluxo de trabalho é executado, a equipe deve conseguir ver o que aconteceu:
- o que acionou a execução
- quais registros de entrada foram processados
- quais sistemas foram acessados
- qual modelo foi usado em cada etapa de IA
- quantos tokens foram gastos
- quanto tempo cada etapa levou
- quais registros falharam e por quê
- quais resultados foram gravados
- quais casos precisam de revisão humana
Sem essa camada, a automação com IA se torna difícil de operar. Um usuário pode ver uma resposta, mas a organização não consegue entender o custo, a qualidade, os modos de falha ou a saúde do processo.
Por isso, a necessidade real é de uma plataforma: um lugar para conectar aplicativos, executar processos, chamar a IA seletivamente, entregar resultados onde são necessários e observar todo o sistema continuamente.
Onde entram os engenheiros em campo
A IA pode ajudar a gerar o código do fluxo de trabalho, mas alguém ainda precisa entender o processo real.
Esse é o papel do engenheiro em campo.
Um FDE trabalha próximo ao cliente e traduz a realidade operacional em um design de fluxo de trabalho executável. Ele identifica o gatilho, os sistemas de origem, os campos importantes, as exceções, os pontos de aprovação, as restrições de segurança e o resultado empresarial esperado.
Ele decide o que deve ser código determinístico, onde a IA é realmente útil, qual modelo é suficiente, o que nunca deve ser enviado a um modelo e o que precisa ser registrado para auditoria e melhoria.
A IA pode escrever o primeiro rascunho. Os FDEs o tornam pronto para produção.
Isso é importante porque os fluxos de trabalho reais estão cheios de contextos que não são óbvios em um chamado. Algumas ações em ERPs são irreversíveis. Alguns campos são sensíveis. Algumas exceções envolvem questões políticas. Algumas falhas são aceitáveis, enquanto outras interrompem as operações. Algumas decisões podem ser automatizadas, enquanto outras precisam de uma pessoa no circuito.
A plataforma dá mais alavancagem aos FDEs. Em vez de começar cada implantação em um repositório vazio, eles podem usar conectores reutilizáveis, componentes básicos de fluxos de trabalho, observabilidade, controles de segurança e desenvolvimento assistido por IA. O FDE traduz o processo. A plataforma torna a implementação repetível.
Essa combinação evita duas armadilhas: agentes abertos que gastam demais em tempo de execução e projetos de consultoria personalizados que nunca se transformam em recursos reutilizáveis do produto.
O modelo mental mais eficiente
O objetivo não é substituir todos os agentes por um script rígido.
O objetivo é separar o que é conhecido do que é desconhecido.
O trabalho conhecido deve se tornar software. O trabalho desconhecido ou intensivo em linguagem pode usar IA. O trabalho repetido deve ser executado em uma plataforma. O trabalho sensível deve ter controles. O trabalho caro deve ser medido. As falhas devem ser visíveis. As melhorias devem se acumular.
Para muitas empresas, essa é a camada que falta entre as demonstrações de IA e o valor em produção.
O futuro da automação com IA não será um único agente gigante clicando em todos os aplicativos o dia inteiro. Serão processos empresariais projetados como fluxos de trabalho, gerados mais rapidamente com IA, operados por uma plataforma, monitorados de ponta a ponta e apoiados por engenheiros que entendem tanto o cliente quanto o código.
É assim que as empresas deixam de usar uma marreta para quebrar uma noz.
E é assim que pagam pela IA de que realmente precisam.