El 7 de octubre Anthropic agregó dos clases nuevas, todavía en beta, a los SDKs de Python y TypeScript de Claude: una para controlar un navegador y otra para controlar un escritorio completo. No es el anuncio más ruidoso del mes, pero resuelve algo que cualquiera que haya construido un agente conoce de memoria: lo feo que es escribir el tool loop a mano.
Qué cambia exactamente
Hasta esta semana, si querías que un agente de Claude navegara una página web o manejara un escritorio virtual, tenías que escribir tú mismo el loop completo: recibir la respuesta del modelo, decidir qué acción ejecutar, correrla contra tu automatización de navegador o de escritorio, formatear el resultado y mandarlo de vuelta. Ese código se repite en cada proyecto nuevo y es justo donde aparecen más bugs, sobre todo cuando el agente encadena quince pasos y uno falla a la mitad.
Las clases nuevas —Anthropic las documenta como BrowserUseTool y ComputerUseTool— invierten el orden: heredas de una clase base y solo escribes un método por acción (clic, scroll, escribir texto, tomar una captura) contra tu propia implementación. El SDK se encarga del loop, de las políticas de URL y de archivos que definas, y del callback de aprobación antes de que el agente haga algo que no se puede deshacer.
Esto llega casi dos meses después de que Anthropic sacara de beta el paquete completo —computer use, el toolset de browser use, la Files API, Agent Skills y la gestión de usuarios de la Admin API— el 19 de agosto. Las herramientas en sí, identificadas como browser_toolset_20260801 y computer_toolset_20260801, ya corrían sobre Opus 5, Sonnet 5, Haiku y hasta el viejo Opus 4.8, incluyendo despliegues en Google Cloud. Lo nuevo es la capa de SDK que las hace manejables sin reinventar el loop cada vez que arrancas un proyecto.
Por qué importa si construyes agentes (no solo si los usas)
La mayoría de proyectos de agentes que no llegan a producción no fallan por el modelo, fallan por el código alrededor del modelo. Un tool loop mal hecho, sin reintentos claros y sin un límite explícito de qué puede tocar el agente, es la receta del típico "funcionaba en la demo y se rompió con el primer usuario real". Tener esa pieza como clase del SDK, con políticas de URL y de archivos configurables desde fuera del prompt, es justo el tipo de barandal que evita que un agente termine navegando a un dominio que no debía o abriendo un archivo fuera de su carpeta de trabajo.
En LATAM esto pega directo en un problema conocido: muchos portales de proveedores, bancos y entidades de gobierno simplemente no tienen API. Si tu equipo automatiza con n8n o con scripts de Python, en algún punto se topa con una pantalla que solo se opera por clic. Antes la salida era Selenium o Playwright a pelo, sin ningún razonamiento del lado del agente. Ahora puedes meter a Claude en el medio para que decida qué clic hacer según el contexto, en vez de seguir un script rígido que se rompe en cuanto el proveedor cambia el diseño de la página.
- ▸Automatizar flujos web sin API: portales de proveedores, formularios de reserva, paneles que solo exportan a PDF
- ▸Dar acceso controlado a un escritorio virtual para tareas que necesitan una app de escritorio y no solo el navegador
- ▸Definir con código —no con una instrucción en el prompt que el modelo podría ignorar— qué URLs y qué carpetas puede tocar el agente
Lo que casi nadie cuenta de las demos de "un agente que navega solo": en producción, el 80% del trabajo de verdad está en las políticas de aprobación, no en el prompt que le diste al modelo.
Browser use y computer use no son lo mismo
Browser use controla específicamente un navegador: clics, scroll, rellenar formularios, leer el DOM de la página. Computer use va un nivel más abajo y controla el escritorio completo —cualquier ventana, cualquier aplicación— a partir de capturas de pantalla y coordenadas. Para la mayoría de los casos de automatización empresarial, un portal web o un ERP que vive en el navegador, con browser use alcanza y sale más barato en tokens, porque no tiene que interpretar una captura completa en cada paso. Computer use entra cuando de verdad necesitas tocar una aplicación de escritorio sin versión web, como ciertos sistemas contables viejos que todavía solo corren sobre Windows.
Si ya usas MCP para conectar Claude con tus herramientas internas, esto no lo reemplaza: resuelve un problema distinto. Un servidor MCP expone funciones que tú ya construiste, como consultar una base de datos o llamar una API interna. Browser use y computer use entran cuando no hay nada que exponer como función porque la única interfaz que existe es la gráfica, que es exactamente el caso de un portal sin API.
Un ejemplo del tipo de proceso que esto resuelve: una empresa que concilia pagos contra el portal de un banco sin API de descarga masiva, solo un dashboard que hay que revisar fila por fila. Antes, la opción era un script de Playwright rígido que alguien del equipo tenía que mantener cada vez que el banco cambiaba el diseño de la página. Con un agente de Claude en el medio, el agente razona sobre lo que ve en vez de seguir coordenadas fijas, así que tolera mejor esos cambios menores de interfaz que antes rompían el script.
Cómo probarlo sin que te explote en la cara
Está en beta, trátalo como tal. Arranca en un entorno de pruebas, no en tu CRM de producción ni en el portal bancario de un cliente. Define primero qué dominios o carpetas son territorio permitido, conecta después el callback de aprobación para las acciones que de verdad importan —enviar un formulario, borrar un archivo, confirmar un pago— y automatiza el resto solo al final. Si ya trabajas con Claude Code, la lógica es la misma que usas con los permisos de herramientas: mejor restringir de más al principio que descubrir en producción que el agente hizo algo que no debía.
- Define la lista blanca de dominios o carpetas antes de escribir una sola línea de automatización
- Conecta el callback de aprobación a las acciones irreversibles primero: enviar, borrar, confirmar, pagar
- Corre el agente en staging con datos de prueba al menos una semana antes de tocar producción
- Registra cada acción que ejecuta el agente, no solo los errores: vas a necesitar ese log el día que algo salga mal
Dónde aprender a construir esto bien
Si quieres meterte de lleno a construir agentes con Claude (herramientas, MCP y ahora browser/computer use), el curso de Claude Code For Developer es el punto de entrada más directo. Y si tu meta no es un script suelto sino diseñar la arquitectura completa de un agente en producción, la ruta AI Agentic Engineer cubre justo ese salto.
Si prefieres verlo funcionar antes de meterte solo, cada semana hacemos un taller práctico en la Comunidad AI Builders: por 19 USD al mes puedes sentarte a ver cómo otros equipos están resolviendo este mismo tipo de problema.
Para seguir: el curso de Claude Code For Developer, la ruta AI Agentic Engineer, o el catálogo completo de cursos de IA en DataPath.
