Digital workers não falham por falta de modelo — falham por falta de teoria

Um quadrante de delegação, três modos de falha, e por que Naur, Polanyi e Suchman explicam o que acontece quando a demo vai pra produção

A demo funcionou. O piloto, também. O rollout pra duzentos usuários foi o que não foi.

Essa frase podia descrever metade dos projetos de digital workers que passaram pelas minhas conversas nos últimos dezoito meses. O padrão é previsível: um caso de uso escolhido com carinho mostra um agente resolvendo um problema real, a liderança aprova, o escopo expande — e aí, em algum ponto entre a semana três e a semana oito, o time começa a perceber que o agente está entregando resultados plausíveis no topo e sutilmente errados embaixo. Ninguém consegue dizer exatamente quando começou. Ninguém consegue dizer exatamente o que mudou. A primeira hipótese é sempre a mesma: o modelo não é bom o suficiente.

Quase sempre, essa hipótese está errada.

O que aconteceu não foi uma falha do modelo. Foi uma falha de teoria — no sentido técnico, específico, quase esquecido que Peter Naur deu à palavra em 1985. Este ensaio é sobre como reconhecer essa falha antes dela acontecer, e o que fazer a respeito.

O quadrante de delegação

Antes de chegar em Naur, um framework prático. Quando alguém me pergunta “por onde começar com digital workers?”, eu desenho dois eixos.

O primeiro eixo é reversibilidade da ação: quão caro é desfazer um erro que o agente cometeu? Cancelar um envio de e-mail que nunca devia ter saído é caro. Reprocessar uma triagem de ticket interno é barato. Reverter uma decisão arquitetural incorporada em seis sprints de código é praticamente impossível.

O segundo eixo é explicitude do contexto: o conhecimento necessário pra decidir bem está codificado em algum lugar legível — documentação, dados, histórico estruturado, regras escritas — ou mora só na cabeça das pessoas que fazem o trabalho? Reconciliação contábil é alto-explícito: existem regras, existe um plano de contas, existe uma verdade externa contra a qual comparar. Feedback de performance é baixo-explícito: o que faz um feedback ser bom depende de coisas que ninguém nunca escreveu e que talvez nem consiga escrever.

Cruzando os dois eixos, você tem quatro quadrantes. O mais interessante é o canto superior direito — alto-reversível, alto-explícito. Esse é o território onde delegação plena funciona: triagem, classificação, reconciliação, primeira passada de código, resumos estruturados, enriquecimento de dados. Erro é barato de corrigir, e o contexto necessário já está em algum lugar que o agente pode consultar.

O canto oposto — baixo-reversível, baixo-explícito — é território humano. Decisões arquiteturais de longo prazo, negociações com clientes estratégicos, resposta a crise, feedback interpessoal. Aqui, o agente pode preparar (reunir informação, rascunhar opções, estruturar o problema), mas a decisão continua sendo humana, e idealmente o humano que tem mais contexto implícito sobre a situação.

Os dois quadrantes mistos exigem julgamento. Alto-reversível mas baixo-explícito (onde você não tem o contexto escrito mas pode errar barato) é território de experimentação com guardrails curtos. Alto-explícito mas baixo-reversível (onde o contexto existe mas o erro é caro) exige uma camada de revisão humana antes de qualquer ação chegar no mundo.

Esse quadrante é útil. Eu uso ele. Times que adotaram ele pararam de empurrar casos errados pra automação. Mas ele esconde uma pergunta que, quando você olha de perto, desmonta metade dos pilotos que entraram em produção: o que exatamente significa “contexto explícito”?

A pergunta que o quadrante não responde

A resposta ingênua é “o contexto está em algum lugar que o agente pode ler”. Documentação, base de conhecimento, histórico de tickets, playbooks. Se está escrito, está explícito.

Só que qualquer pessoa que já tentou onboardar um funcionário humano sabe que não é assim que funciona. Você entrega a documentação, o playbook, as regras — e o funcionário ainda leva três meses pra entregar bem. O que ele aprende nesses três meses não está na documentação. Não porque a documentação foi mal escrita, mas porque certas coisas resistem estruturalmente à escrita.

É aqui que Peter Naur entra.

Naur: programar é construir teoria

Em 1985, Peter Naur publicou um artigo curto com um título enganosamente acadêmico: “Programming as Theory Building”. A tese é simples e, quando você a absorve, muda o jeito como você enxerga desenvolvimento de software — e, por extensão, qualquer trabalho de conhecimento.

Naur argumenta que o resultado real do trabalho de programar não é o código. O código é um artefato — um resíduo visível de algo que aconteceu na cabeça dos desenvolvedores. Esse algo Naur chama de teoria: um modelo mental do domínio, do sistema, das decisões que foram tomadas e, mais importante, das decisões que foram descartadas e por quê. A teoria é o que permite que um programador responda a uma pergunta nova sobre o sistema — “se a gente mudar X, o que quebra?” — sem ter que reler o código inteiro.

O experimento mental de Naur é cruel. Imagine um sistema que foi construído por um time, entregue, e está funcionando bem. O time original é dissolvido. Um novo time recebe o código-fonte, a documentação, os testes — tudo o que normalmente consideramos “o produto”. Naur argumenta que esse novo time, por mais competente que seja, é estruturalmente incapaz de manter o sistema da mesma forma. Eles podem fazer modificações mecânicas. Eles podem corrigir bugs óbvios. Mas não conseguem tomar as decisões de design de segunda ordem — as que preservam a coerência interna do sistema — porque não têm a teoria. A teoria morreu quando o time se dissolveu.

Aplicado a digital workers, o argumento de Naur tem uma consequência específica: você não pode delegar uma função cuja teoria nunca foi construída, ou que existe apenas na cabeça de um time que não participa da delegação.

Essa é a falha que eu vejo repetidamente. O time pega um processo de negócio, descreve em passos, entrega pro agente, e fica surpreso quando o agente executa os passos corretamente mas produz um resultado que ninguém aceita. O problema não é o modelo. O problema é que os passos descritos nunca foram o trabalho — eles eram o que as pessoas fazem quando não precisam pensar. O trabalho real está nas exceções, nas decisões que os operadores experientes tomam sem perceber, nas vezes em que “o procedimento diz X mas nesse caso a gente faz Y porque Z”. Isso é teoria. E teoria raramente está escrita, porque ela não precisava estar escrita enquanto as pessoas que a carregavam continuavam fazendo o trabalho.

Polanyi: sabemos mais do que conseguimos dizer

Naur não estava sozinho. A intuição que ele articulou pra programação já tinha sido articulada de forma mais geral por Michael Polanyi em The Tacit Dimension (1966). A frase famosa do livro resume tudo: “We can know more than we can tell.”

Polanyi estava interessado em como humanos adquirem e transmitem habilidades que não conseguem explicar. O exemplo dele é andar de bicicleta — um ciclista experiente não consegue descrever as micro-correções que faz pra manter o equilíbrio, mas as executa impecavelmente. A tentativa de explicitar o conhecimento destrói ele: se você pensar ativamente em como está equilibrando, você cai. Polanyi chama isso de conhecimento tácito, e argumenta que ele não é uma fase transitória a caminho do conhecimento explícito. É uma forma estável, talvez dominante, de como o conhecimento humano realmente funciona.

Trabalho de conhecimento tem quantidades imensas de dimensão tácita. Um advogado experiente sabe que um contrato “está estranho” antes de conseguir dizer por quê. Um médico sabe que um paciente não está bem antes de ter evidência. Um gerente sabe que uma reunião vai dar errado pelo jeito que as pessoas sentaram. Nenhuma dessas intuições é mágica — elas são padrões acumulados em milhares de casos, comprimidos em reconhecimento rápido, muitas vezes inacessíveis à introspecção consciente.

Pra digital workers, isso tem uma consequência desconfortável. Se o trabalho que você quer delegar depende de conhecimento tácito, nenhuma quantidade de prompts, few-shot examples ou RAG vai recuperar esse conhecimento — porque ele nunca foi registrado em lugar nenhum. Ele vive na forma como o especialista pondera, não no que o especialista escreve. Você pode chegar perto reunindo exemplos anotados suficientes pra que o agente aprenda por indução, mas o preço é alto: exige que alguém com a competência tácita faça a anotação com cuidado, e aceite que o resultado vai ser uma aproximação imperfeita, nunca uma transferência.

Polanyi reforça Naur. Naur descreve o que se perde quando um time se dissolve. Polanyi explica por que isso se perde estruturalmente, e não por preguiça documental.

Suchman: planos são recursos, não determinantes

A referência mais importante desse ensaio é também a menos citada nesse debate. Em 1987, Lucy Suchman publicou Plans and Situated Actions, um livro que começou como uma crítica etnográfica a um sistema de help desk fotocopiadora e terminou como uma demolição filosófica da abordagem dominante em inteligência artificial da época — a IA baseada em planejamento.

O argumento central de Suchman é este: quando humanos agem no mundo, eles não executam planos. Eles usam planos como recursos pra ação, mas a ação em si é continuamente renegociada com as circunstâncias concretas em que acontece. Um plano é um mapa, e o mapa não é o território; na hora de caminhar, você responde ao terreno, não ao mapa. Suchman chama isso de situated action — ação situada.

A crítica de Suchman foi dirigida a sistemas de IA dos anos 80 que tentavam modelar ação humana como execução de planos hierárquicos pré-definidos. O ponto dela era que esses sistemas falhavam não porque os planos estavam incompletos — sempre vão estar — mas porque a própria ideia de que ação é execução de plano é um erro categórico. Humanos competentes improvisam constantemente dentro de quadros flexíveis. Quando a situação muda, eles não replanejam; eles re-respondem.

Eu não conheço um texto que anteveja melhor o que acontece quando você tenta especificar um digital worker via “job description”.

O modelo mental que a maior parte das organizações traz pra delegação a agentes é exatamente o modelo que Suchman demoliu quarenta anos atrás: defina o objetivo, liste os passos, enumere as exceções, entregue a especificação. O agente executa. Onde a realidade não bate com a especificação, o agente falha visivelmente (e pode ser corrigido) ou — mais perigoso — falha invisivelmente, produzindo uma execução sintaticamente correta mas semanticamente errada.

Digital workers que funcionam bem em produção não são os que recebem a melhor spec. São os que operam dentro de um loop de feedback curto com humanos que mantêm a teoria viva. A spec serve como ponto de partida, como acordo inicial, como documento de referência — nunca como substituta do julgamento situado. Suchman descreveria isso dizendo que o plano continua sendo um recurso, não um determinante. Naur descreveria dizendo que a teoria precisa continuar sendo construída coletivamente. Os dois estão dizendo a mesma coisa.

Relendo os três modos de falha

Com Naur, Polanyi e Suchman na mesa, os padrões de falha em digital workers ficam mais fáceis de diagnosticar. Três se repetem.

O primeiro é antropomorfização. O time começa a tratar o agente como um colega júnior — fala com ele, explica coisas, espera que ele “aprenda” entre as interações. Quando o agente não aprende (porque a maioria dos deployments não tem memória persistente ou tem uma versão muito rudimentar), a frustração vira decepção, e a decepção vira abandono. O erro aqui é categórico: o agente não é um aprendiz humano adquirindo teoria por imersão. Ele é um processo estatístico operando sobre o contexto que você explicitamente entrega. O tácito não migra pra ele por osmose. Se você quer que ele se comporte como se tivesse aprendido algo, você tem que codificar esse algo — e, como Polanyi avisou, certas coisas resistem à codificação.

O segundo é delegação cega. O time empurra trabalho pro agente sem estabelecer o loop de revisão, e descobre o problema semanas depois num relatório que chegou no cliente errado. Esse é o modo Suchman: acreditaram que a spec era suficiente, esqueceram que ação é situada, e pagaram o preço da confiança mal calibrada. A correção não é mais spec — é loop mais curto. Revisão por amostragem, canary deployments, humanos olhando os primeiros N casos antes do agente rodar em escala. Isso não é “falta de confiança no modelo”. É reconhecimento de que teoria se mantém viva pela prática, não pela especificação.

O terceiro é paralisia de governança. O oposto dos dois primeiros: o comitê de IA vê os riscos de delegação cega, reage com um processo de aprovação tão pesado que nada sai do piloto. O paradoxo é que essa postura também é uma falha de teoria — só que invertida. A suposição implícita é que, se a gente definir controles suficientes, a gente vai chegar num deployment seguro sem precisar construir teoria na prática. Não vai. A teoria de operar digital workers só se constrói operando. Organizações que ficam presas no comitê não aprendem a operar, e quando finalmente precisam, descobrem que a competência — que é tácita, situada, acumulada por exposição — não está em lugar nenhum.

Os três modos são a mesma falha vista de ângulos diferentes: tratar digital workers como se eles pudessem ser totalmente especificados a partir de fora. Antropomorfização é a versão otimista (“ele vai aprender”). Delegação cega é a versão ingênua (“a spec basta”). Paralisia é a versão pessimista (“se a spec não basta, então nada basta”). Todas ignoram o mesmo fato: teoria só vive onde tem prática, e digital workers só se tornam parte da teoria se forem parte da prática.

Context engineering como trabalho de legibilidade

A implicação prática desse diagnóstico é menos glamorosa do que a promessa inicial da automação por agentes, e mais profunda.

Se você quer delegar bem a um digital worker, seu trabalho não é escrever uma spec. Seu trabalho é tornar a teoria do processo suficientemente legível — pra humanos novos e pra agentes — que ela possa ser compartilhada. James Scott, em Seeing Like a State, descreveu como estados modernos transformaram práticas locais complexas em categorias legíveis pra poderem governar; o preço sempre foi alguma perda. Context engineering, quando feito com seriedade, é o mesmo trabalho aplicado à teoria operacional da sua organização. Você está tornando explícito o que, até agora, vivia só na prática. E como Scott mostrou, parte sempre se perde no caminho — a questão não é se você vai perder, é o quê você escolhe preservar.

Na prática concreta, isso significa algumas coisas bem específicas. Significa que documentação viva — atualizada por quem faz, referenciada por quem decide — deixa de ser “boa prática opcional” e vira infraestrutura. Significa que os exemplos anotados que alimentam o agente precisam ser curados por quem tem a competência tácita, não por quem tem tempo livre. Significa que os loops de revisão humana não são um custo temporário a ser eliminado — eles são o mecanismo pelo qual teoria continua sendo construída depois que o agente entra em produção. Significa que o papel de quem revisa o agente é mais parecido com o de quem mentora um funcionário novo do que com o de quem faz QA de um sistema determinístico.

E significa, acima de tudo, que o investimento em digital workers não escala linearmente com o número de agentes. Ele escala com a qualidade da teoria compartilhada da organização. Uma organização com teoria tácita bem desenvolvida e documentação fraca vai lutar. Uma organização com documentação forte mas sem prática de revisão e refinamento contínuo também vai lutar. A combinação que funciona é a que reconhece que context engineering e operação de agentes são duas faces do mesmo trabalho.

Digital workers não se configuram, se onboardam

A palavra configuração sugere que existe um estado final, alcançável, em que o agente está pronto pra operar autonomamente. Essa palavra carrega o modelo mental errado. Digital workers bem-sucedidos não são configurados — são onboardados, continuamente, pelo grupo humano que mantém a teoria do trabalho viva. O onboarding nunca termina, porque a teoria nunca para de evoluir. Novos casos aparecem, decisões antigas são revisadas, o domínio muda. Um agente que entrou em produção há seis meses e nunca mais foi reajustado provavelmente já está derivando em direção a um lugar onde ninguém concorda mais com o que ele entrega.

Isso é inconveniente pra métricas de ROI que assumem um investimento inicial seguido de retorno puro. Mas é consistente com tudo que sabemos sobre como conhecimento organizacional funciona, desde Polanyi até Naur até Suchman. A boa notícia é que organizações que abraçam esse modelo — que tratam digital workers como novos participantes da teoria, não como recursos configurados — acabam ganhando uma coisa que não estava no plano original: uma disciplina interna de explicitação que vale por si só, independente dos agentes.

Talvez essa seja a contribuição menos discutida e mais durável dos digital workers pra forma como as organizações trabalham. Não a automação em si. O que a automação força você a deixar explícito.

Referências

Naur, P. (1985). Programming as Theory Building. Microprocessing and Microprogramming, 15(5).

Polanyi, M. (1966). The Tacit Dimension. University of Chicago Press.

Suchman, L. (1987). Plans and Situated Actions: The Problem of Human-Machine Communication. Cambridge University Press.

Scott, J. C. (1998). Seeing Like a State: How Certain Schemes to Improve the Human Condition Have Failed. Yale University Press.