Seu agent deveria conseguir ver a tela
A última milha do 'fazer tudo' é o software sem API. Um agent que consegue ver a tela e clicar alcança o trabalho trancado atrás de UIs que integrações nunca vão tocar.
Apollo Space Research
Apollo Space
Existe um portal estadual pelo qual uma empresa faz declarações todo trimestre. Ele não tem API. Não tem export. Tem um login, um dropdown que não abre até o de cima ser preenchido, um seletor de arquivo, e um botão de enviar que fica cinza até três outros campos ficarem verdes. Uma pessoa faz isso em vinte minutos, xingando o tempo todo, e esquece como até o próximo trimestre.
Toda plataforma de agent no mercado consegue ler o email dessa empresa, atualizar seu CRM e rascunhar seus contratos. Nenhuma delas consegue preencher aquele formulário, porque não há nada para chamar. O trabalho não é difícil. Ele só está trancado atrás de uma tela para a qual nenhuma integração jamais foi construída.
Aquele portal não é um caso extremo. Ele é a forma de um terço do trabalho na maioria das empresas.
A tese: um agent que não consegue ver a tela não consegue fazer o trabalho que não tem API
Aqui está a linha em torno da qual este post inteiro orbita. A última milha do “fazer tudo” é o software sem API, e um agent o alcança só quando consegue ver a tela e clicar. Todo o resto é integrações, e integrações param exatamente onde o conector termina.
A promessa que as pessoas vendem quando dizem “a IA vai fazer o trabalho” assume silenciosamente que o trabalho tem uma porta que a máquina consegue abrir, um endpoint REST, um webhook, um bloco de Zapier. Para muito do SaaS moderno, tem. Mas no momento em que o trabalho vive num site de registros do município, num ERP de uma década atrás, no portal de fornecedor sob medida de um supplier, num app de desktop de 2014, a porta não está trancada. Não há porta. Há uma janela, a tela, e até o agent conseguir olhar por ela e enfiar a mão, aquele trabalho fica manual para sempre.
O mecanismo que conserta isso não é um modelo mais inteligente. É um sentido que o modelo não tinha. Eis por que a abordagem óbvia fica sem estrada, e o que a substitui.
A versão ingênua: conecte uma API para tudo
O jeito limpo de fazer um agent agir sobre o mundo é dar a ele APIs. Você conecta o email, o calendário, o CRM, os docs, o tracker de projetos. Cada conexão é um contrato: aqui estão as coisas que você pode ler, aqui estão as coisas que você pode fazer, aqui está a forma dos dados. O agent chama uma função, o sistema faz a coisa, um resultado estruturado volta. É confiável, é auditável, é rápido. Quando funciona, nada supera.
Então você conecta as dez ferramentas em que a empresa vive, e por uma semana gloriosa parece que você automatizou tudo.
Aí alguém pede ao agent para renovar a licença de negócio no portal estadual. E não há conector. Nunca ia haver um conector. Um site de registros do governo servindo quatro municípios não lança uma API, e nenhum time de integrações na Terra vai construir e manter uma para ele. O agent, o que acabou de rascunhar um contrato impecável, fica ali, incapaz de clicar um botão que um temporário clicaria no primeiro dia.
Esse é o muro, e vale ser preciso sobre por que é um muro e não uma lacuna que você pode fechar. Uma API tem que ser construída para um agent pelo dono do software. Essa é a dependência. O CRM expõe uma API porque o fornecedor do CRM decidiu. O portal estadual não expõe nada porque ninguém decidiu, e você não consegue fazê-los decidir. O modelo de integração dá ao agent alcance exatamente tão amplo quanto a generosidade dos outros. A maior parte da cauda longa do software de negócio nunca foi generosa, e nunca será.
Conte as superfícies que uma empresa real de fato toca numa semana: o SaaS moderno com APIs limpas, sim, mas também a ferramenta interna legada com um login e nenhuma documentação, o portal de fornecedor que é diferente para cada fornecedor, o app de contabilidade de desktop, a interface web do banco, o site de declarações do regulador. Imagine que a abordagem de integração cobre o primeiro balde limpamente e uma fatia fina do segundo. O resto, chame de a parte do trabalho que vive atrás de uma UI e nada mais, é invisível para ela. Não lenta. Não instável. Invisível.
O gargalo não desapareceu quando você adicionou conectores. Ele se moveu para tudo que os conectores não alcançam.
Por que “é só construir a integração” perde a cauda longa
Há uma resposta tentadora para o muro: tudo bem, vamos construir as integrações que os fornecedores não construíram. Faça scraping do portal, faça engenharia reversa do formulário, escreva um adapter customizado para cada caso isolado. Times fazem isso. Funciona para os primeiros poucos. Aí a economia alcança.
Cada adapter customizado é uma pequena peça de software que mira o HTML exato de um site, a ordem exata de campos de um formulário, os truques exatos de um fluxo de login. O site é redesenhado, e um redesenho sobre o qual ninguém te avisou é a norma para software sem API, porque não há contrato de API para manter estável, e seu adapter quebra silenciosamente. Você agora está mantendo uma frota de scrapers frágeis, um por caso isolado, cada um uma responsabilidade permanente que falha na próxima vez que alguém move um botão. A cauda longa é longa precisamente porque cada ferramenta é usada por poucas empresas demais para justificar alguém mantendo uma interface limpa para ela. Construir um adapter sob medida por ferramenta só relocaliza essa mesma manutenção não-econômica para cima de você.
A integração ingênua perde a cauda longa porque a cauda longa é definida por não valer a pena integrar, uma ferramenta de cada vez.
Então a pergunta muda. Você para de perguntar “como construímos uma interface para cada uma dessas ferramentas?” e começa a perguntar “qual interface todas essas ferramentas já compartilham?”. E há uma. Cada uma delas, o portal, o ERP, o app de desktop, o site do banco, já expõe exatamente a mesma interface, a que construíram para os humanos que as usam todo dia. A tela. O ponteiro. O teclado.
Essa é a interface que o agent deveria mirar. Não mil APIs customizadas. A única API universal que toda peça de software na Terra já lança: a própria UI.
A nossa versão: dê olhos ao agent
A ideia é simples de enunciar e a maior parte do trabalho está em levá-la a sério. Um agent que consegue ver a tela e clicar alcança o trabalho que não tem API, porque ele para de precisar da permissão do software e começa a usar o software do jeito que uma pessoa usa.
Concretamente, o agent ganha um sentido que não tinha. Ele consegue tirar um screenshot, olhá-lo e entender o que está nele, isto é um formulário de login, aquilo é o dropdown, este botão cinza está desabilitado, aquele texto vermelho é um erro de validação. Do entendimento, ele age: mova o ponteiro aqui, clique, digite naquele campo, aperte tab, espere a página assentar, olhe de novo. Ver, decidir, agir, ver de novo. É o mesmo loop que uma pessoa roda sem perceber que está rodando.
Essa é a parte que a abordagem ingênua estruturalmente não conseguia fazer, então vale ser concreto sobre o que ela destrava. O agent não pergunta mais “essa ferramenta tem um endpoint que eu tenho permissão de chamar?”. Ele pergunta “eu consigo ver essa tela?”, e a resposta é sim para toda ferramenta que um humano consegue usar, porque se um humano consegue usá-la, ela renderiza numa tela. A dependência da generosidade do fornecedor acabou. A interface é a que o fornecedor já lançou para seus próprios usuários e tem todo motivo para manter estável, porque seus usuários se revoltariam se o formulário de login mudasse toda semana.
Duas propriedades fazem isso funcionar na prática em vez de numa demo, e ambas vêm direto das falhas acima.
A primeira é que a visão degrada graciosamente onde adapters se estilhaçam. Um scraper amarrado a uma estrutura HTML exata quebra completamente quando um campo se move, porque ele estava lendo o esqueleto invisível da página. Um agent que lê a tela renderizada do jeito que uma pessoa lê vê que o botão “Enviar” se moveu três centímetros para baixo e o clica onde ele está agora, do mesmo jeito que você faria, sem nem notar o redesenho. Ele está lendo o significado dos pixels, não a marcação frágil por baixo. O redesenho que mata o adapter é um não-evento para os olhos.
A segunda é que o agent opera sob as mesmas permissões da pessoa para quem trabalha. Ele não precisa de uma credencial de integração especial que o fornecedor nunca emitiu. Ele faz login do jeito que o funcionário faz login, vê o que o funcionário vê, consegue fazer o que o funcionário tem permissão de fazer, e nada além. A fronteira do seu alcance é a fronteira da conta que está usando, que é exatamente a fronteira que você já entende e já controla.
Então o loop, desenhado claramente, é: o agent olha a tela, decide a próxima ação, a executa, e olha de novo para confirmar o que aconteceu antes de decidir a próxima. Ele não dispara uma sequência cega de cliques e torce. Ele confere o próprio trabalho a cada passo, porque a tela diz a ele se a última ação aterrissou, o dropdown abriu ou não, o campo ficou verde ou lançou um erro. Agir e verificar são o mesmo sentido.
Olhos são um fallback, não um substituto
Seria um erro ler isso como “telas vencem APIs”. Não vencem. Quando uma API limpa existe, ela vence toda vez, é mais rápida, retorna dados estruturados, não tem que ler pixels, e não consegue errar o clique. Um agent deveria sempre preferir o endpoint quando há um.
O ponto é a ordem do fallback. Vá para a API primeiro. Quando não há API, vá para o export. Quando não há export, vá para a tela. A maioria das plataformas de agent para no passo um e chama o resto de impossível. O argumento inteiro deste post é que o passo três é onde o trabalho trancado vive, e a tela é o que o destrava.
Junte os dois sentidos e o alcance do agent vira a união, não a interseção: tudo com uma API, mais tudo que um humano consegue operar. Essa união é o que “fazer tudo” de fato exige. Sem os olhos, “fazer tudo” sempre foi silenciosamente “fazer tudo que veio com um conector”, uma promessa muito menor, muito mais confortável.
É também aqui que mora a cautela honesta, porque pixels são uma interface menos precisa que uma chamada de função. Um agent agindo numa tela real, com botões de enviar reais, precisa de um freio, um momento de confirmação humana antes de preencher o formulário, mandar a transferência, clicar na coisa irreversível. Ver a tela é o que dá ao agent alcance. Um humano no loop no clique consequente é o que torna esse alcance seguro de conceder. Os dois lançam juntos ou nenhum deveria lançar.
A virada: o trabalho que ninguém automatiza é o trabalho que ninguém quer
Dê um passo atrás do mecanismo, porque o mecanismo não é o ponto. O ponto é quem vem fazendo esse trabalho, e o que ele vem custando.
Agora mesmo, na maioria das empresas, as telas sem API são operadas na mão, e é quase sempre uma pessoa cujo tempo vale muito mais que a tarefa. O operador que faz login no portal estadual todo trimestre. A pessoa de finanças que re-digita números no app de desktop que o auditor insiste. O gerente de conta que preenche um portal de fornecedor diferente para cada fornecedor, cada um um labirinto de dropdowns. Esse é o trabalho que nunca entrou no roadmap de automação de ninguém, precisamente porque não tinha API para automatizar contra, então caiu para quem estava sentado mais perto, para sempre.
Esse trabalho parece o custo de fazer negócio. Ele é na verdade o trabalho mais automatizável do prédio, escondido atrás da única barreira que o fazia parecer impossível. A barreira nunca foi que a tarefa fosse difícil. Um temporário a aprende numa manhã. A barreira era que o software só conseguia agir através de portas que outras pessoas construíram, e ninguém construiu uma porta para o site de registros do município. Dê olhos ao software e a barreira sumiu, a tarefa sempre foi simples, ela só era inalcançável.
A promessa não é que um agent vá fazer trabalho esperto que humanos não conseguem. É que um agent vá finalmente fazer o trabalho chato, trancado, sem-API que humanos não deveriam, a declaração trimestral, a maratona do portal, a re-digitação, para que a pessoa que ficou presa fazendo isso ganhe de volta as manhãs para o trabalho que de fato precisava de um humano.
É isso que estamos construindo na Apollo Space: não um agent que é só tão capaz quanto os conectores que recebeu, mas um que alcança a última milha, o software sem API, vendo a tela e clicando, do mesmo jeito que as pessoas lá já fazem. Se sua empresa roda em ao menos um portal para o qual ninguém nunca construiu uma integração, você já sabe exatamente de qual tela estamos falando.
A Apollo cuida da operação repetitiva da sua empresa pro seu time não precisar.
Entre na lista de espera: acesso antecipado, preço de usuário fundador e um lugar na primeira fila enquanto a gente constrói.
Entrar na lista de esperaO imposto oculto dos agents em paralelo é um diamante de migrations
Seis agents escrevendo para um schema conflitam no banco de dados, não no código, e a CI morre em "multiple heads".
EngenhariaUm orchestrator que não sobrevive ao próprio crash não é um
Um crash que apaga o raciocínio do orchestrator perde a única coisa que você não consegue reconstruir.
EngenhariaColoque um portão determinístico na frente do seu revisor mais esperto
A pega-defeito mais barata é um script burro que checa se duas branches mergeadas ainda sobem antes de qualquer julgamento.