Visão de agentes é a camada de percepção que define o que um agente de software consegue observar, interpretar e transformar em decisão. A tela do sistema legado piscou, o agente clicou no lugar errado e a operação travou. Quem já acompanhou uma automação de perto conhece esse momento: o modelo respondeu bem, mas enxergou mal.
A maioria das conversas sobre agentes de IA foca no raciocínio, nos prompts e nos modelos. Mas a diferença entre um agente que funciona e um que quebra quase sempre está no que ele vê. Sem uma percepção confiável, o raciocínio mais sofisticado produz decisões erradas.
Este texto abre a caixa do que o agente consegue ver, de onde vem essa informação, onde ele erra e como conferir se o que ele fez está certo. Nada de mágica.
- A camada de percepção de um agente de software é o conjunto de sensores, conectores e modelos que transformam o estado do ambiente em observações utilizáveis para decisão.
- Um passo de raciocínio com screenshot em modelo de visão-linguagem custa entre 1 e 6 segundos de latência, e uma tarefa realista consome de 8 a 30 passos, tornando inviável automação síncrona sem streaming ou fallback humano.
- A maioria das iniciativas de IA agêntica trava na etapa de visibilidade: falta inventário de agentes, o que acessam e o que estão executando, tornando a observabilidade e o humano no loop obrigatórios em produção.
A camada invisível que decide se o agente acerta ou erra
Por trás de cada ação autônoma existe uma etapa de percepção que quase ninguém discute. Em um sistema legado, o agente não apenas clica: ele precisa observar a tela, entender os campos, ler validações e então decidir o próximo passo.
Na minha leitura de projetos nacionais, essa camada costuma ser a última a ser pensada — e a primeira a derrubar o piloto.
No Brasil, isso é ainda mais crítico porque portais do governo, ERPs antigos e sistemas de backoffice foram desenhados para humanos, não para máquinas. Quem ignora essa camada descobre tarde que o agente não é ruim de raciocínio, é ruim de visão.
Antes de contratar ou construir qualquer agente, mapeie o que ele precisa enxergar: telas, APIs, documentos ou vídeo. Esse inventário define custo, latência e fragilidade de tudo que virá depois.
Visão de agentes: a camada que define o que um agente pode saber

Visão de agentes é o conjunto de sensores, conectores e modelos que transformam o estado do ambiente em observações utilizáveis para decisão. Ela define o que o agente pode saber, com que latência, com que ruído e com que custo. Sem essa camada confiável, o raciocínio mais sofisticado produz decisões erradas.
Na prática, é o espaço de observação somado ao pipeline que o alimenta: captura, normalização, interpretação e injeção no contexto do modelo. Em sistemas com interface legada, isso inclui screenshot, árvore de acessibilidade ou leitura de documentos.
Quem projeta agentes precisa tratar a percepção como um problema de engenharia, não como um detalhe de integração. A escolha da fonte de observação muda o limite do que o agente consegue fazer.
Não é visão computacional: entenda a diferença

A visão computacional clássica extrai padrões de imagens e vídeos; a visão de agentes entrega contexto acionável para o próximo passo do agente. A primeira identifica objetos, rostos ou anomalias. A segunda transforma a observação em um estado que alimenta o loop percepção-ação. Confundir as duas leva a escolher a ferramenta errada: um modelo de detecção de objetos não resolve a leitura de um formulário.
Onde a percepção entra no loop percepção → raciocínio → ação
A percepção alimenta o raciocínio com o estado do ambiente, e o raciocínio decide a ação que pode alterar esse estado. Todo agente opera sobre três blocos: percepção, raciocínio e ação. A percepção é a porta de entrada; se ela entrega um estado errado, o raciocínio planeja sobre uma base falsa e a ação corrompe o processo. Esse recorte aparece na literatura como observação parcial: o agente nunca vê o mundo inteiro, apenas um recorte ruidoso e atrasado.
Os tipos de percepção que um agente pode ter (e o que cada um custa)
Um agente pode perceber por API, por tela, por documento, por vídeo ou por telemetria, e cada fonte tem latência, custo e fragilidade próprios. A escolha depende do processo, do sistema e do nível de robustez necessário.
Percepção estruturada via API: rápida, barata e cega fora do contrato
A percepção por API entrega dados estruturados com latência baixa e custo previsível, mas só funciona enquanto o contrato da interface permanece estável. Sistemas internos e ERPs modernos expõem endpoints que devolvem JSON limpo. O agente não precisa ‘ver’ nada; ele consome campos e executa tool calling. Porém, qualquer mudança fora do contrato, como um campo novo ou um endpoint depreciado, cega o agente.
Percepção por tela: quando o agente lê a interface como um humano
A percepção por tela usa capturas de interface, árvore de acessibilidade ou DOM para transformar pixels e elementos em observações que o agente pode interpretar. É a saída para sistemas legados, portais do governo e ERPs sem API. O agente lê a tela com um modelo de visão-linguagem, identifica campos, botões e validações, e decide o próximo passo. O custo é maior latência e maior fragilidade a alterações de interface.
Documentos, vídeo e telemetria: quando o mundo não é uma tela
Processos que envolvem notas fiscais, contratos, câmeras ou logs exigem percepção multimodal: reconhecimento de documentos, detecção de anomalia em vídeo e leitura de telemetria de agentes. O agente combina fontes heterogêneas. Em backoffice financeiro, por exemplo, ele extrai dados de um PDF e depois confere com a telemetria de um sistema interno. Cada modalidade adiciona latência e exige normalização antes de entrar no contexto.
Como um agente enxerga uma tela de computador, passo a passo
O agente captura a tela, normaliza a informação, interpreta com modelo de visão-linguagem e injeta o resultado no contexto de decisão. Esse pipeline é a base da percepção visual.
Eu considero o grounding visual o ponto mais negligenciado nesse fluxo: erros ali se transformam em cliques errados.
Screenshot, DOM ou árvore de acessibilidade: escolhendo a fonte de observação
Cada fonte de observação de tela oferece um equilíbrio diferente entre riqueza visual e estrutura semântica. Screenshot dá a imagem completa, mas exige grounding visual para transformar pixels em elementos clicáveis. O DOM e a árvore de acessibilidade entregam estrutura com textos e papéis, reduzindo a necessidade de interpretação visual, mas podem ficar dessincronizados com o que o usuário realmente vê.
Grounding visual: como pixels viram elementos clicáveis
O grounding visual é o processo que mapeia caixas delimitadoras e rótulos semânticos sobre a imagem para que o agente localize e clique no elemento certo. Modelos de visão-linguagem devolvem coordenadas normalizadas. O agente converte essas coordenadas em ação de clique ou digitação. A precisão depende da resolução, da clareza do layout e da consistência dos elementos.
Por que o agente clica no botão errado
O clique errado quase sempre vem de ambiguidade visual, baixa resolução, ou desalinhamento entre a captura e o momento da ação. Botões com textos parecidos, pop-ups inesperados, e animações de carregamento confundem o modelo. Se a tela foi capturada antes de um overlay surgir, o agente clica onde o botão estava, não onde ele está.
Percepção por API versus percepção por tela: o trade-off que define o projeto
API é estável e barata, mas exige contrato; tela é flexível, porém mais lenta e frágil a alterações de interface. A decisão não é binária; muitos agentes combinam as duas: usam API para o que tem contrato e tela para o que não tem. O ponto é mapear o processo e identificar onde a percepção visual é inevitável.
O que muda quando o sistema é legado e não tem API
Sistemas legados sem API forçam a percepção por tela, o que aumenta a complexidade, a latência e a necessidade de testes de robustez. No Brasil, portais públicos e ERPs antigos são comuns. O agente precisa lidar com layouts inconsistentes, validações client-side e ausência de estados claros. O projeto deve prever tempo para ajustar seletores e tratar falhas visuais.
Por que a visão é o gargalo real dos agentes de IA hoje
A visão limita o que o agente pode saber, com que latência e com que ruído, e por isso ela se torna o gargalo antes mesmo do raciocínio. Modelos de linguagem são geralmente rápidos e baratos para raciocinar; a captura e interpretação visual consomem tempo e tokens. Se a percepção falha, o agente repete passos, consome mais contexto e erra a tarefa.
Eu costumo repetir: sem observação confiável, o raciocínio trabalha sobre areia.
Latência: de 1 a 6 segundos por passo, de 8 a 30 passos por tarefa
Um passo de raciocínio com screenshot leva entre 1 e 6 segundos, e uma tarefa realista consome de 8 a 30 passos, totalizando pelo menos 40 segundos. Isso inviabiliza atendimento síncrono sem streaming ou fallback humano. Para processos assíncronos, a latência é tolerável, mas para interação com cliente, não. Cada passo com imagem gasta milhares de tokens, o que eleva o custo da operação.
Onde os agentes quebram: formulários com validação, CAPTCHA e layout novo
Benchmarks de navegação mostram taxas de conclusão entre um terço e dois terços, com erro concentrado em formulários com validação, CAPTCHA, pop-ups e alterações no layout. Formulários validam campos de forma assíncrona, o agente pode submeter antes da validação. CAPTCHA é desenhado para bloquear automação. Alterações no layout quebram seletores e coordenadas.
Em multiagentes, o custo de ‘ver’ cresce mais rápido que o time de agentes
Cada agente que precisa ‘ver’ o que o outro fez duplica tokens de observação, fazendo o custo de contexto crescer exponencialmente. Em um sistema multiagente, a comunicação entre agentes exige que um agente supervisor observe o estado compartilhado. Sem poda de contexto e protocolo de comunicação entre agentes eficientes, o custo de observação domina o orçamento.
Onde a visão de agentes já é realidade nas operações brasileiras
Atendimento, backoffice financeiro, varejo e logística concentram os casos de uso mais maduros no Brasil porque combinam sistemas legados com alto volume de tarefas repetitivas.
Atendimento, backoffice financeiro, varejo e logística: os quatro campos mais quentes
No atendimento, agentes leem telas de CRM e ERPs para consultar pedidos e atualizar cadastros. No backoffice financeiro, extraem dados de notas fiscais e conciliam com sistemas internos. No varejo e logística, monitoram câmeras e sensores para detectar filas, rupturas de estoque e anomalias operacionais.
Dúvidas que aparecem antes do primeiro piloto
Três dúvidas travam a maioria dos pilotos: se é só RPA, como auditar as ações e quando o humano precisa entrar no loop.
Isso não é só RPA com outro nome?
RPA executa passos determinísticos baseados em seletores fixos; um agente com visão interpreta o estado e decide o próximo passo mesmo com variação. O agente lida com ambiguidade e exceções que quebrariam um robô. Mas ele também é mais imprevisível, exige testes e monitoramento.
Não consigo auditar o que ele fez, então como confiar?
A auditoria de agentes exige observabilidade de agentes: registros do que ele viu, do que decidiu e do que executou, com possibilidade de reprodução da sessão. Sem isso, o agente é uma caixa-preta. É obrigatório ter trace distribuído, logs de tool calling e capturas de tela em pontos críticos.
Quando o humano no loop deixa de ser opcional?
O humano no loop é obrigatório quando a ação é irreversível, o custo do erro é alto ou a confiança do agente é baixa. Transferências de valores, envio de documentos oficiais e respostas a clientes exigem validação humana. O agente deve pausar e pedir aprovação com contexto claro.
Depois de analisar tantos projetos, fico com uma sensação desconfortável: a maioria das equipes trata a visão do agente como um detalhe de implementação, não como uma decisão de arquitetura. Elas escolhem o modelo mais potente, escrevem prompts elegantes, e só então descobrem que o agente não consegue preencher um formulário do portal do governo. A culpa não é do modelo, é da fonte de percepção. Eu mesmo já caí nessa armadilha ao subestimar o custo de normalizar telas de um ERP antigo. A lição que carrego é simples: antes de qualquer prompt, mapeie o que o agente precisa ver e como essa visão será capturada, normalizada e injetada no contexto. É isso que separa um piloto que impressiona de um agente que funciona em produção.
Dentro do pipeline de percepção: captura, normalização, interpretação e injeção
O pipeline de percepção tem quatro etapas: captura, normalização, interpretação e injeção no contexto do agente. Cada etapa influencia a qualidade da observação e o custo total.
Captura: o que coletar, com que frequência e com qual resolução
A captura define a fonte, a frequência e a resolução da observação, e cada escolha afeta latência, custo e qualidade. Screenshots de alta resolução melhoram a leitura, mas consomem mais tokens e tempo. A árvore de acessibilidade reduz ruído, mas pode ignorar informações visuais relevantes. A frequência ideal é orientada por eventos: capturar antes e depois de cada ação, não continuamente.
Normalização: cortar ruído antes de gastar tokens
A normalização remove elementos irrelevantes, redimensiona imagens e extrai regiões de interesse para reduzir o consumo de tokens. Barras de navegação, cabeçalhos e propagandas são cortados. No caso de documentos, o pré-processamento pode aplicar OCR e estruturar campos. Isso reduz a carga do modelo e melhora a precisão.
Contexto de execução: o que realmente entra na memória de trabalho do agente
A memória de trabalho do agente recebe apenas a observação relevante para o passo atual, não todo o histórico bruto. O contexto de execução combina a percepção atual com objetivos, restrições e resultados anteriores. Sem poda, o agente gasta tokens com informações irrelevantes e perde foco.
Observação parcial: o que o POMDP explica sobre agentes que enxergam pouco
Um POMDP formaliza a condição de observação parcial: o agente nunca vê o estado real completo, apenas observações ruidosas e atrasadas.
Estado real do ambiente versus crença do agente
O agente mantém uma crença sobre o estado do ambiente, e essa crença pode divergir do estado real. Por exemplo, o agente acredita que o formulário foi preenchido, mas um campo oculto não foi atualizado. A crença precisa ser atualizada a cada observação, e a incerteza deve guiar a decisão de pedir ajuda.
O que o agente esquece entre um passo e outro
Entre passos, o agente pode perder contexto se a memória não for gerenciada de forma explícita. Modelos com janela de contexto limitada descartam observações antigas. Por isso, agentes robustos usam memória de longo prazo, resumos e anotações para reter o que importa.
Visualização de agentes: o painel que mostra o que ele vê, faz e custa
A visualização de agentes é o painel que expõe, em tempo real, o estado de cada agente, suas observações, ações e custos acumulados.
Trace, span e reprodução da sessão: anatomia de uma auditoria que funciona
Trace distribuído registra a cadeia de chamadas; span detalha cada etapa; reprodução da sessão recria a sequência exata de telas e cliques. Esses três elementos permitem reconstruir o que o agente viu e fez, identificar onde errou e gerar evidência para auditoria.
Despachar sessões paralelas sem perder o controle
Sessões paralelas exigem isolamento de contexto por agente e um painel que permita intervir em qualquer sessão. O operador precisa ver status, fila, erros e custo por sessão. Sem isso, escalar agentes em produção vira um risco operacional.
Governança: inventário, identidade e permissões por agente
Governança de agentes exige inventário atualizado, identidade única e permissões mínimas para cada agente.
Por que a maioria das iniciativas trava na etapa de visibilidade
A maioria das empresas não sabe quantos agentes existem, o que acessam e o que estão executando. Essa falta de visibilidade bloqueia auditoria, segurança e melhoria contínua. Implantar um inventário de agentes é o primeiro passo para a governança.
Sandbox, credenciais isoladas e limites de execução
Executar agentes em sandbox, com credenciais isoladas e limites de passos e ações, reduz o impacto de falhas. Cada agente deve ter um escopo mínimo de permissões. Limites de execução impedem loops infinitos e gastos descontrolados.
Como reduzir latência e custo da camada de percepção
Reduzir latência e custo começa por escolher a fonte de observação certa e otimizar o pipeline de normalização.
OCR estruturado ou VLM: quando cada um compensa
OCR estruturado é mais rápido e barato para documentos com layout fixo; visão-linguagem (VLM) é necessário para telas complexas e contexto visual. Para notas fiscais padronizadas, OCR extrai campos com alta precisão e baixa latência. Para interfaces dinâmicas, o VLM entende a semântica e os elementos clicáveis.
Cache de observação, poda de contexto e streaming de resultados
Cache de observação evita reprocessar telas iguais; poda de contexto remove tokens irrelevantes; streaming permite mostrar progresso enquanto o agente trabalha. Essas técnicas combinadas podem reduzir latência percebida e custo de tokens sem sacrificar a precisão.
Fallback humano: quando errar custa mais caro que esperar
O fallback humano deve ser acionado quando o agente encontra baixa confiança, validação bloqueada ou ação irreversível. Em vez de insistir e errar, o agente pausa e transfere a tarefa com o contexto visual e histórico para um operador.
Robustez a mudanças de layout: o que realmente segura o agente de pé
A robustez vem de âncoras semânticas e guardrails de validação, não de seletores fixos ou coordenadas absolutas.
Âncoras semânticas em vez de seletores frágeis
Âncoras semânticas usam textos, papéis e proximidade para localizar elementos, resistindo a mudanças de posição e estilo. Em vez de depender de um XPath que quebra, o agente procura ‘botão de enviar’ pelo rótulo e pelo contexto visual.
Guardrails e validação antes de cada ação irreversível
Guardrails são validações programáticas que bloqueiam ações se pré-condições não forem atendidas. Antes de clicar em ‘confirmar pagamento’, o agente verifica valor, destino e saldo. Isso evita erros catastróficos mesmo quando a percepção está ruidosa.
Eu sempre recomendo validar cada ação irreversível com guardrails, mesmo quando o agente parece confiante.
Agentes que enxergam o mundo físico: vídeo em borda
Agentes de vídeo em borda processam imagens localmente em câmeras e sensores, reduzindo latência e custo de transmissão.
Inferência local em loja, indústria e condomínio
A inferência local permite detectar eventos em tempo real sem depender de nuvem, essencial para segurança e operação. Uma loja pode detectar filas ou prateleiras vazias; uma indústria, paradas de máquina; um condomínio, acesso indevido.
Detecção de anomalia: o que fazer com o alerta
O alerta de anomalia deve disparar uma ação definida: notificar humano, acionar outro agente ou registrar incidente. Sem uma resposta clara, o alerta vira ruído. O agente precisa integrar o evento visual ao fluxo de trabalho.
Erros comuns de quem constrói ou contrata agentes com visão
Os erros mais comuns são confiar cegamente no modelo e subestimar o custo de tokens de imagem.
Confiar em benchmarks de navegação em vez de testar no ambiente real
Benchmarks como WebArena medem taxas de conclusão em tarefas padronizadas, mas não capturam a variabilidade de sistemas legados brasileiros. Eles são úteis para comparar modelos, mas não substituem testes no ambiente real. O agente que vai bem no benchmark pode quebrar em um portal público com CAPTCHA.
Confiar no modelo em vez de na fonte de percepção
Um modelo forte não compensa uma percepção pobre; se a captura é ruim, o raciocínio será ruim. Avalie a qualidade da observação antes de trocar o modelo. Às vezes, melhorar a árvore de acessibilidade resolve mais que um modelo maior.
Subestimar tokens de imagem no orçamento da operação
Cada passo visual pode consumir milhares de tokens, e tarefas com 20 passos multiplicam esse custo rapidamente. Projetos que ignoram o custo de percepção estouram orçamento e inviabilizam escala. É preciso medir custo por passo e definir limites.
Checklist para avaliar uma plataforma de agentes com visão
Ao avaliar uma plataforma, pergunte sobre latência por passo, reprodução da sessão, isolamento de credenciais e suporte a humano no loop.
As perguntas sobre latência por passo, reprodução da sessão e isolamento de credenciais
A plataforma deve informar latência típica por passo, capacidade de reprodução da sessão e como gerencia credenciais de forma isolada. Sem essas respostas, a promessa de agente autônomo esconde riscos operacionais.
Sinais de que a plataforma só disfarça RPA com IA
Se a plataforma exige seletores fixos, não lida com alterações de interface e não oferece observabilidade, ela é RPA com verniz de IA. Agentes de verdade interpretam estado e decidem; automação tradicional segue regras fixas.
Três passos para começar hoje sem se perder no ruído
Na Prática · O Que Fica
- 01A Escolha Certa: Mapeie o processo e decida onde a percepção por API resolve e onde a tela é inevitável. Em sistemas legados brasileiros, prepare-se para percepção visual com fallback humano.
- 02Ponto de Atenção: Não confunda agente com RPA. A diferença está na capacidade de interpretar estado e decidir com incerteza, mas isso exige auditoria constante.
- 03Na Prática: Antes de qualquer piloto, monte um inventário de agentes, credenciais isoladas, log do que foi visto, reprodução da sessão, limite de passos e gatilho de escalonamento humano.
A maioria das implementações quebra porque tenta escalar antes de ter visibilidade. Comece pequeno, com um agente, uma tarefa e um painel de reprodução da sessão. A confiança vem da evidência, não da promessa.
O que separa um agente confiável de um demo impressionante não é o modelo de linguagem, é a camada de percepção por trás dele. Visão de agentes define o teto da automação: sem observação estruturada, auditoria e humano no loop, qualquer projeto desmorona em produção.
Escolha um processo real, mapeie o que ele precisa ver e monte um piloto com observabilidade desde o primeiro dia. Você vai descobrir gargalos que nenhuma apresentação de vendas mostra. Visão de agentes é engenharia de observação, não mágica.

