Un agente ve lo que ve un lector de pantalla
En este artículo
Le di a Claude Code una frase en una terminal: hazme un collage con las fotos de la playa y mándalo a mi canal de Telegram, que lo quiero en el móvil. Cuatro minutos después lo tenía en el móvil. Había abierto Fotos, seleccionado el álbum, exportado ocho fotos, montado el collage, comprobado el resultado en Vista Previa, pegado la imagen en Telegram, escrito el pie de foto y enviado.
Ninguna de esas apps tiene una API para eso. Fotos no la tiene, y yo no iba a montar un bot de Telegram para que publicase en mi nombre. El agente manejó las apps con agent-desktop, una CLI de código abierto de Vercel Labs que hace una sola cosa: lee el árbol de accesibilidad de cada app y actúa sobre él.
Ese árbol es la misma estructura que macOS le entrega a VoiceOver. Así que la pregunta que me rondaba mientras veía la ejecución no era «¿puede un agente usar mi Mac?». Era: ¿cuánto de mi Mac puede ver de verdad?
Un árbol, dos lectores
Cada ventana nativa de macOS publica un árbol de elementos: un rol (button, textfield, menuitem), un nombre, a veces un valor, y las acciones que admite. Un lector de pantalla recorre ese árbol y lo lee en voz alta. agent-desktop recorre el mismo árbol y lo devuelve como JSON con una referencia por elemento, de modo que el agente puede decir «pulsa @e12» en lugar de adivinar coordenadas sobre una captura.
Eso cambia lo que significa «computer use». No es visión. El agente no mira píxeles; lee lo que la app ha decidido describir de sí misma. Si la app se describe bien, el agente es rápido y preciso. Si no, no hay nada que leer.
Qué enseñan 23 apps
Así que lo medí. Abrí las apps que tengo instaladas, una a una, y leí el árbol de la ventana principal con agent-desktop tres veces cada una: cuántos elementos expone, qué parte tiene nombre y cuántos admiten una acción. Solo recuentos, sin contenido.
Algunas cosas llaman la atención:
- Telegram expone 1.493 elementos y todos tienen nombre. Cada chat, cada mensaje, cada contador. Para un agente es la app más legible del ordenador.
- Spotify expone casi los mismos, pero la mitad sin nombre. Un botón sin nombre es un botón que el agente tiene que adivinar. Y quien usa un lector de pantalla, también.
- El emulador de Android expone un elemento: la ventana. Todo el teléfono que hay dentro es una imagen. El agente ve que existe una ventana llamada «Android Emulator» y nada más.
- Docker Desktop no respondió. Tres lecturas de 45 segundos, ningún árbol.
- ChatGPT pasó de 12 elementos a 406 entre la primera lectura y la segunda. Recién abierta solo enseñaba el armazón; unos segundos después, toda la interfaz. Si la hubiera medido en frío la habría dado por opaca.
- La Terminal expone 17 elementos, porque toda la transcripción es un único campo de texto. El agente la puede leer, pero como un bloque de texto, no como estructura.
Dos matices. Son recuentos de un ordenador en un día, de la ventana con la que abrió cada app, y un árbol más grande no es por fuerza más usable: la proporción de elementos con nombre dice más que el tamaño. Pero los extremos no son sutiles: entre «un elemento» y «1.493 elementos con nombre» no hay error de medida que cambie la conclusión.
Después repetí el censo en un ordenador con Windows 11, donde agent-desktop lee el árbol de UI Automation, y el panorama se mantuvo. La misma app se lee más o menos igual en los dos sistemas: Telegram expone allí 1.509 elementos frente a 1.493 aquí, Slack 483 frente a 616. La primera lectura en frío también pasa allí: Spotify dio 183 elementos y luego 1.651. De las reglas que vienen más abajo, la del escritorio actual se cumplió; las otras dos no, porque en Windows el menú de una app en segundo plano se lee activo y el diálogo de guardar pertenece al propio proceso de la app.
Expuesto no es lo mismo que operable
La segunda mitad me la enseñó el propio collage, y es la parte que un censo no muestra. Telegram, la app más legible del gráfico, fue también donde el agente más sufrió.
Para mandar una imagen la pega en la caja de mensajes y Telegram abre un panel de envío con un campo de pie de foto y dos botones. Todo ese panel está en el árbol, con buenos nombres. Y aun así:
- El campo del pie de foto informa de un valor vacío mientras la pantalla enseña el texto. El agente no podía comprobar leyendo lo que había escrito; tuvo que hacer una captura de esa zona y mirarla.
- Send y Cancel no admiten la acción de pulsar. La herramienta se negó a hacer clic sobre ellos por la vía semántica, y un clic físico a través de ella también falló. Lo que funcionó fue el teclado: Enter envía, Escape cancela.
- Ni siquiera escribir funcionaba ahí. El campo nunca anunciaba que tenía el foco, así que la herramienta se negaba a teclear en él. El rodeo fue poner el texto en el portapapeles y pegarlo.
Telegram no es la excepción. Otras cosas con las que me encontré por el camino, y que el agente ahora sigue como reglas:
- Los menús solo funcionan en la app que está delante. Si le pides a Fotos Archivo › Exportar mientras está en segundo plano, la opción aparece desactivada. Traes la app al frente y se activa.
- El diálogo de guardar es otro proceso. El panel donde eliges carpeta no pertenece a Fotos, así que los atajos de teclado que le mandas a Fotos nunca le llegan. En uno de los ensayos, un clic semántico sobre una carpeta dentro del panel guardó la exportación directamente en esa carpeta.
- Las acciones pueden llegar tarde. Un pegado que parecía no haber funcionado apareció un momento después, y el panel acabó con dos copias de la imagen. Cada paso necesita mirar de nuevo antes del siguiente.
- El agente solo ve el escritorio actual. Cambias a otro escritorio de macOS y todas las ventanas de ahí desaparecen del árbol.
- Hay árboles demasiado grandes para leerlos enteros. Un chat largo de Telegram pasó del límite de 1 MB de la herramienta; el agente tuvo que leer la ventana por arriba y luego bajar solo a la lista de mensajes.
Nada de esto es exótico. Son las mismas costuras con las que choca quien usa teclado o lector de pantalla: un valor que la app no publica, un control sin acción, un diálogo que vive en otro proceso.
Qué le llegaría a quien usa un lector de pantalla
No hice estas tareas con VoiceOver, así que aquí voy con cuidado. Pero VoiceOver le hace las mismas preguntas a la misma API. Un pie de foto que informa de un valor vacío es, para él, un campo vacío. Un botón sin acción de pulsar es un botón al que la propia orden de activar de VoiceOver no tiene nada que llamar; tendría que recurrir a simular un clic de ratón, como hizo el agente. Una ventana de emulador con un elemento es, para una persona ciega, una ventana sin etiqueta.
La diferencia es quién paga. Quien usa un lector de pantalla se encuentra estos huecos de uno en uno y los rodea con paciencia. Un agente también se los encuentra, pero luego se convierten en reglas: «pulsa Enter, el botón no admite clics», «pega, no escribas». Los rodeos que necesitó el agente son un mapa de dónde está rota la accesibilidad de una app.
Me recordó a lo que encontré midiendo agentes sobre código degradado: en repositorios grandes, cómo está escrito el código reduce a la mitad lo que un agente resuelve. Aquí es la misma lección una capa más arriba. El agente es tan bueno como lo que puede leer, y lo que puede leer es lo que alguien se tomó la molestia de describir.
Si haces apps, o agentes
Si haces apps: la accesibilidad iba de las personas que usan tecnologías de apoyo. Sigue yendo de eso, y eso solo ya es razón suficiente. Pero ese mismo árbol es ahora la interfaz de cualquier agente que maneje un ordenador como lo haría una persona. Pon nombre a tus controles, publica sus valores, dales a tus botones una acción de pulsar. Esa es toda la lista, y sirve a los dos lectores a la vez.
Si haces agentes encima de esto: trata cada app como si tuviera sus propias reglas y verifica después de cada acción, porque el árbol a veces te dirá que algo funcionó cuando no, o que falló cuando no había fallado. La ejecución que por fin salió limpia, en algo menos de cuatro minutos, no fue un modelo más listo. Fue una lista corta de lo que cada app deja hacer.
Si una app es accesible, es una herramienta. Si no lo es, para un agente casi no existe.
Medido en macOS 15.7 con agent-desktop 1.0.2: ventana principal de cada app, tres lecturas, solo recuentos. Figma y Cursor no arrancaron desde la línea de comandos en este ordenador y no están en el gráfico. La comparación con Windows se midió en Windows 11 con el mismo método; el gráfico muestra la tanda de macOS.