O problema da marreta
Muitos fluxos de trabalho de IA hoje parecem usar uma marreta para quebrar uma noz.
A tarefa é simples: ler uma planilha, verificar novos registros, enriquecer alguns campos, classificar um pedido, criar um relatório, atualizar um CRM, enviar uma notificação ou preparar uma resposta para revisão.
Mas, em vez de desenhar o processo, as equipes entregam toda a tarefa 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.
Há também 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 o software poderia executar de forma determinística, não está apenas desperdiçando tokens. Está consumindo um tempo de modelo escasso e de alto valor. Então, quando surge uma tarefa realmente difícil, a equipe pode estar novamente esperando por capacidade.
Isso pode ser útil quando o ambiente é desconhecido ou a tarefa é genuinamente exploratória. Nem sempre é a melhor arquitetura para um processo de negócio repetível.
A maioria dos fluxos de trabalho em produção não é um problema de agente. São problemas de automação com chamadas ocasionais de IA.
Um fluxo de trabalho geralmente é mais estruturado do que parece
Quando se olha de perto, muitos fluxos de trabalho de IA seguem uma forma previsível.
Eles começam com um gatilho. Às vezes o gatilho é agendado: toda manhã, toda sexta-feira, no final do mês ou após o fechamento de uma janela de relatório. Às vezes é baseado em evento: chega um e-mail, um cliente envia um formulário, um registro muda num banco de dados, um ticket é criado ou um novo arquivo cai numa pasta.
Em seguida, o fluxo de trabalho obtém dados de entrada. Podem vir de uma API, de um CRM, de um ERP, de uma planilha, de um documento, de uma aplicação web, de um banco de dados existente ou de uma combinação de sistemas.
Depois ele itera sobre a entrada. Valida registros, filtra casos, normaliza campos, aplica regras, checa status, ramifica conforme condições e prepara saídas.
Apenas algumas etapas realmente precisam de IA.
A IA pode ser necessária para extrair significado de texto não estruturado, classificar um pedido, resumir evidências, redigir 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. Devem ser código, não raciocínio repetido.
Por fim, o fluxo de trabalho armazena ou entrega o resultado. Atualiza um banco de dados, escreve de volta num CRM, cria um documento, envia um e-mail, abre uma tarefa, publica no Slack ou expõe um dashboard.
Isso não é uma pessoa clicando em telas. Isso é um processo.
Tokens em tempo de execução devem ser gastos com inteligência
O erro caro é usar chamadas ao modelo para orquestração que o software pode gerenciar diretamente.
Se cada execução pede a um agente para 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 melhor é simples:
- usar código determinístico para gatilhos, laços, validação, roteamento, tentativas e armazenamento
- usar APIs e conectores onde os sistemas já expõem interfaces confiáveis
- chamar a IA apenas para as partes que se beneficiam de compreensão de linguagem, geração, raciocínio ou julgamento
- escolher o modelo certo para cada etapa em vez de enviar toda tarefa para o modelo mais poderoso
- manter rastros, custo, latência, entradas, saídas e falhas visíveis
É daqui que vêm as economias de tokens. Não só de modelos mais baratos, mas de remover chamadas desnecessárias ao modelo por completo.
Em implantações Guanta, essa arquitetura pode reduzir dramaticamente o uso de tokens porque o modelo não é mais solicitado a executar todo o processo. A empresa paga pela inteligência que precisa, quando precisa, com o modelo adequado ao trabalho.
Com o tempo, algumas partes podem não necessitar de chamadas externas a modelos de maneira alguma. Modelos menores, classificadores especializados, inferência local, decisões em cache, embeddings e código convencional podem lidar com mais do fluxo de trabalho. A plataforma deve possibilitar essas escolhas sem redesenhar o processo toda vez.
A IA também deve ser usada na fase de construção
Isso não significa usar menos IA no total.
Significa usar IA no lugar certo.
A IA pode ser extremamente útil ao construir o fluxo de trabalho. Pode ajudar a traduzir requisitos em código, gerar conectores, escrever transformações de dados, rascunhar lógica de validação, criar pequenas ferramentas internas, produzir testes, explicar APIs legadas e acelerar o trabalho de transformar um processo operacional confuso em software.
Mas, uma vez que esse fluxo de trabalho esteja definido, a empresa não deve continuar pagando a um modelo para gerar a mesma lógica repetidamente em tempo de execução.
Use IA intensamente na fase de design e build. 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 onde os dados ao vivo realmente exigem inteligência.
Essa distinção importa.
Agentes são bons em descobrir o que fazer quando o problema é ambíguo. Plataformas são boas em 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 de trabalho. A IA é invocada dentro do fluxo somente nos pontos onde gera alavancagem real.
Por que uma plataforma importa
Trabalhos repetíveis com IA precisam de mais do que prompts.
Precisam de conectores para sistemas de negócios. Precisam de execução agendada e baseada em eventos. Precisam de estado, permissões, tentativas, filas, logs, segredos, etapas de aprovação humana, versionamento e controles de implantação.
Também precisam de observabilidade.
Quando um fluxo de trabalho roda, a equipe deve poder ver o que aconteceu:
- o que disparou 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 saídas foram gravadas
- quais casos precisam de revisão humana
Sem essa camada, a automação com IA torna-se difícil de operar. Um usuário pode ver uma resposta, mas a organização não consegue entender custo, qualidade, modos de falha ou saúde do processo.
É por isso que a necessidade real é uma plataforma: um lugar para conectar aplicações, executar processos, chamar IA seletivamente, entregar resultados onde são necessários e observar todo o sistema em todos os momentos.
Onde os engenheiros forward-deployed se encaixam
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 forward-deployed.
Um FDE fica próximo ao cliente e traduz a realidade operacional em um desenho de fluxo de trabalho executável. Eles identificam o gatilho, os sistemas de origem, os campos relevantes, as exceções, os pontos de aprovação, as restrições de segurança e o resultado de negócio.
Decidem o que deve ser código determinístico, onde a IA é genuinamente útil, qual modelo é suficientemente bom, 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 importa porque fluxos de trabalho reais estão cheios de contexto que não é óbvio a partir de um ticket. Algumas ações em ERP são irreversíveis. Alguns campos são sensíveis. Algumas exceções são políticas. Algumas falhas são aceitáveis e outras quebram operações. Algumas decisões podem ser automatizadas, enquanto outras precisam de um humano no loop.
A plataforma dá alavancagem aos FDEs. Em vez de começar cada implantação a partir de um repositório em branco, eles podem usar conectores reutilizáveis, primitivas de fluxo 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 de propósito aberto que gastam demais em tempo de execução e projetos de consultoria customizados que nunca se tornam uma capacidade de produto reutilizável.
O modelo mental mais adequado
O objetivo não é substituir todo agente por um script rígido.
O objetivo é separar o que é conhecido do que é desconhecido.
Trabalho conhecido deve virar software. Trabalho desconhecido ou pesado em linguagem pode usar IA. Trabalho repetido deve rodar numa plataforma. Trabalho sensível deve ter controles. Trabalho caro deve ser mensurado. Falhas devem ser visíveis. Melhorias devem se acumular.
Para muitas empresas, essa é a camada que falta entre demos de IA e valor em produção.
O futuro da automação com IA não será um agente gigante clicando em todas as aplicações o dia todo. Serão processos de negócio projetados como fluxos de trabalho, gerados mais rápido com IA, operados por uma plataforma, monitorados de ponta a ponta e suportados 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 elas pagam apenas pela IA de que realmente precisam.