OpenWorker: los agentes de IA de código abierto de Andrew Ng

Si quieres un sistema de IA que termine el trabajo en lugar de solo responder prompts, la idea principal de OpenWorker en una línea es esta: planifica tareas, usa herramientas y se detiene para pedir aprobación antes de acciones de alto riesgo.

Yo lo resumiría así: OpenWorker es un framework de agentes de código abierto y local-first que se ejecuta a través de una aplicación de escritorio y un servidor Python local, enruta trabajos entre modelos en la nube y locales, y usa 4 niveles de permiso para controlar el acceso a archivos, la ejecución de comandos y los mensajes externos. Encaja con equipos que quieren un control más estricto de los datos, menos fricción de configuración entre modelos y una verificación humana clara antes de que ocurra algo arriesgado.

Aquí va la versión corta:

• Qué hace: convierte un objetivo en un flujo de trabajo de varios pasos
• Cómo se ejecuta: aplicación de escritorio Tauri 2 + interfaz React 18 + servidor local FastAPI/Uvicorn
• Acceso a modelos: proveedores en la nube y modelos locales a través de aisuite, más Ollama para uso local
• Modelo de seguridad: read, write_local, exec y external
• Revisión humana: cada paso exec y external espera aprobación
• Herramientas conectadas: archivos, calendarios, Slack y otros sistemas del equipo
• Opción de endpoint de modelo: APIMart a través de una única API compatible con OpenAI
• Trabajo idóneo: informes, investigación, paquetes de contenido, tareas de soporte y pipelines multimedia
• Necesidades de producción: trazabilidad, evaluaciones, versionado de prompts, seguimiento de gasto y un flujo de revisión de outbox

Destacan algunos datos. OpenWorker usa 4 tipos de acción, bloquea el 100 % de las acciones exec y external hasta que una persona las aprueba, y puede cambiar entre modelos como GPT-5, Claude Sonnet 4.6 y Gemini 3 Pro Preview sin cambiar la lógica del flujo de trabajo.

Si tuviera que decidir si encaja con mi equipo, miraría primero una cosa: ¿tengo trabajo repetible con pasos claros y necesidad de aprobación humana en acciones arriesgadas? Si es así, OpenWorker tiene sentido.

Andrew Ng: State of AI Agents | LangChain Interrupt

Cómo funciona OpenWorker: arquitectura, modelos y permisos

La fiabilidad de OpenWorker proviene de tres capas: ejecución local, enrutamiento de modelos y puertas de aprobación.

Aplicación de escritorio y servidor de agente local

OpenWorker se ejecuta como una aplicación de escritorio Tauri 2 con una interfaz React 18, emparejada con un servidor Python 3.10+ local que usa FastAPI y Uvicorn. En términos sencillos, la aplicación que ves en tu escritorio trabaja codo a codo con un servidor local que se ejecuta en tu máquina.

Esa configuración mantiene el agente cerca tanto de los datos como del usuario. También ayuda a mantener las cosas más controladas, ya que el servidor escucha en localhost de forma predeterminada.

Enrutamiento de modelos entre LLM en la nube y locales

OpenWorker usa aisuite para enrutar solicitudes entre proveedores de modelos en la nube y entornos de ejecución locales como Ollama. Eso da a los equipos margen para decidir a dónde debe ir cada tarea en lugar de enviarlo todo por una sola ruta.

Por ejemplo, los equipos pueden mantener las tareas privadas en local y enrutar el trabajo de menor riesgo a otro lugar. Si los datos son sensibles, las tareas pueden enviarse a un modelo local a través de Ollama.

Planificación de tareas, acciones tipadas y puertas de aprobación

Cuando le das un objetivo a OpenWorker, este divide ese objetivo en pasos discretos y asigna un tipo de permiso a cada acción antes de ejecutar nada. Así, en lugar de una gran caja negra, obtienes una serie de pasos que se pueden verificar y revisar.

Los cuatro tipos de permiso se corresponden directamente con el nivel de riesgo:

Las puertas de aprobación bloquean cada acción exec y external hasta que un humano la aprueba. Ese modelo de control es lo que hace práctica la siguiente capa de integraciones.

Herramientas, integraciones y acceso a modelos impulsado por APIMart

Trabajar entre archivos, calendarios, Slack y sistemas del equipo

OpenWorker se conecta a archivos locales, calendarios, Slack y otros sistemas del equipo a través de herramientas integradas, integraciones alojadas y conectores.^[4] Eso lo hace útil para automatizar trabajo conectado, no solo tareas puntuales.

Así se ve en la práctica. Un equipo de operaciones le pide a OpenWorker que prepare el informe de rendimiento semanal y lo comparta con el equipo. El agente lee las exportaciones de analítica locales, compone un documento pulido en una carpeta compartida, redacta un resumen de Slack con las métricas clave y luego se detiene a pedir aprobación antes de enviar nada fuera del equipo.^[4] OpenWorker hace la coordinación. Las personas siguen decidiendo qué sale.

Los equipos de contenido y marketing pueden usar la misma configuración para paquetes de contenido. OpenWorker puede extraer investigación de origen de archivos locales, redactar un brief o un documento de blog y marcar fechas límite de revisión en el calendario del equipo, todo sin tocar sistemas externos hasta que alguien dé el visto bueno.^[4]

Usar APIMart como endpoint de modelo unificado

Una vez conectadas las herramientas, el siguiente paso es el acceso a modelos. OpenWorker puede usar APIMart como su endpoint de modelo unificado a través de una única URL base compatible con OpenAI.^[2][3]

La configuración es bastante sencilla:

• Crea una clave de API de APIMart
• Envía payloads JSON estándar compatibles con OpenAI para solicitudes de chat, completions y multimedia

Desde el punto de vista de OpenWorker, APIMart parece un único proveedor estable. Pero detrás de ese único endpoint, los equipos pueden cambiar entre modelos como GPT-5, Claude Sonnet 4.6 o Gemini 3 Pro Preview sin cambiar en absoluto el flujo de trabajo del agente. Eso significa una sola capa de enrutamiento y menos mantenimiento entre los modelos que usa un equipo.

Flujos de trabajo multimodales para equipos de contenido y multimedia

Esa misma configuración de enrutamiento también admite trabajo multimodal más allá del texto. Con APIMart, OpenWorker puede pasar de la investigación al guion y a la generación de vídeo a través de un solo endpoint.^[1]

Para un equipo que produce contenido de vídeo semanal, OpenWorker puede coordinar todo el pipeline —investigación, guion, generación de recursos y preparación para revisión— mientras APIMart gestiona la selección de modelos en segundo plano. El flujo de trabajo permanece igual. Solo cambia el modelo.

Ejecutar OpenWorker de forma fiable en producción

El uso en producción necesita trazabilidad, controles y visibilidad de costes entre modelos, tareas y equipos. Construida sobre los permisos y el enrutamiento de modelos ya establecidos, esta sección cubre la capa operativa que hace que esos fundamentos funcionen en la práctica. El siguiente paso es convertir esa configuración en algo que puedas observar, auditar y controlar en producción.

Trazabilidad, evaluaciones y versionado de prompts

La fiabilidad en producción empieza con visibilidad de cada paso de cada ejecución.

Cada ejecución del agente debería registrar el estado completo de la ejecución: estado de la conversación, entradas y salidas de las herramientas, qué modelo se usó, recuentos de tokens y latencia por paso. Sin eso, la depuración se convierte en adivinar. Con eso, puedes ver exactamente dónde falló un flujo de trabajo y arreglar esa parte sin alterar el resto.

El versionado de prompts importa igual de mucho. Cuando un equipo actualiza un system prompt para mejorar la calidad de salida, siempre existe la posibilidad de que rompa algo que ya funcionaba. Ejecutar golden tests —un pequeño conjunto de entradas conocidas y buenas con salidas esperadas— contra cada cambio de prompt ayuda a detectar regresiones antes de que lleguen a producción. Los golden tests detectan regresiones de prompts antes del despliegue.

Controles de riesgo y supervisión humana para acciones sensibles

Cuando un agente puede afectar a sistemas compartidos, la ejecución necesita una transferencia revisable.

Para acciones sensibles, usa un patrón outbox: el agente registra las acciones previstas para su revisión antes de ejecutarlas.^[5] Esto encaja bien con los sistemas compartidos, donde la revisión humana debería ocurrir antes de la ejecución, no después de que se haya causado el daño.

Esto se relaciona directamente con los tipos de permiso exec y external establecidos antes: el patrón outbox gobierna la transferencia final de esas acciones de mayor riesgo. En configuraciones multiagente más complejas, una estructura de carpetas construida en torno a directorios inbox/, outbox/ y workspace/ mantiene limpios los límites de datos y predecibles las transferencias.^[5] Cada agente sabe de dónde leer y dónde escribir, lo que facilita auditar el pipeline.

Gestión de costes y modelos con el enrutamiento de APIMart

Una vez que los flujos de trabajo están en marcha, el control de costes se convierte en un requisito operativo.

Con APIMart como endpoint central, los equipos pueden hacer seguimiento del gasto, establecer topes de precio y monitorizar la latencia en un solo lugar. Si ya ejecutas flujos de trabajo multimodelo, el enrutamiento centralizado reduce la sobrecarga de gestionar claves, SDK y paneles separados para cada proveedor.

Con claves directas, los picos de coste a menudo se descubren solo al final de un ciclo de facturación. Con el enrutamiento de APIMart, los equipos pueden establecer topes de precio y reglas de enrutamiento antes de que un flujo de trabajo se convierta en un problema caro.

Casos de uso prácticos y conclusión

Investigación, operaciones de contenido y flujos de trabajo multimedia

Una vez configurados los controles del flujo de trabajo, OpenWorker tiende a brillar en trabajo repetitivo y de alto volumen. Funciona mejor cuando una tarea sigue el mismo conjunto de pasos una y otra vez.

Por eso encaja tan bien con los flujos de trabajo de marketing, investigación y multimedia. Los equipos pueden automatizar el ensamblaje de contenido coordinando distintas partes del proceso y contrastando la salida final con los estándares de marca. En un solo pipeline, un equipo puede redactar copy, generar imágenes y crear vídeos cortos a través de un único endpoint.

Esa configuración hace mucho más fluido el salto de la investigación a la generación de texto, imagen y vídeo. En lugar de unir herramientas a mano, los equipos pueden ejecutar todo el flujo en un solo lugar.

Automatización de soporte, operaciones y operaciones internas

La misma idea se traslada al soporte y las operaciones internas. OpenWorker puede hacer más que enviar respuestas simples. Puede responder, verificar y actuar sobre tareas rutinarias como consultas de estado de pedidos, restablecimientos de contraseña y solicitudes de facturación.

Para los equipos, eso importa porque mucho trabajo interno no es difícil. Simplemente es repetitivo. OpenWorker ayuda a sacar adelante ese trabajo mientras mantiene las acciones sensibles detrás de puertas de aprobación.

Conclusión: qué pueden construir los equipos hoy

En conjunto, estos flujos de trabajo muestran dónde es más fuerte OpenWorker en este momento. Su diseño de código abierto da a los equipos control directo sobre la personalización, los datos y el coste. Esa configuración se construye en torno a la ejecución local-first y una automatización práctica que termina el trabajo en lugar de solo iniciarlo.

Una forma inteligente de empezar es sencilla: comienza con un flujo de trabajo repetitivo y de alto volumen, demuestra el valor y luego expande.

Preguntas frecuentes

¿Para quién es mejor OpenWorker?

OpenWorker funciona mejor para equipos multifuncionales, desarrolladores y unidades de negocio que quieren llevar la IA de las demos a una automatización fiable y lista para producción.

Encaja bien con equipos que escalan flujos de trabajo de varios pasos en investigación, operaciones de contenido, atención al cliente y automatización de procesos de negocio, especialmente cuando quieren mantener el control de la personalización, las integraciones y los costes.

¿Puede OpenWorker mantener los datos sensibles en local?

Sí. Los frameworks de agentes de código abierto a menudo admiten despliegue local, para que los desarrolladores puedan construir y probar agentes manteniendo los datos sensibles dentro de sus propios sistemas.

Con modelos de despliegue local y protocolos de comunicación basados en archivos, los equipos pueden mantener límites de datos estrictos y las operaciones internas.

¿Qué tareas deberían automatizar primero los equipos?

Empieza con flujos de trabajo de alto volumen y basados en reglas. Los mejores objetivos iniciales son las tareas repetitivas, fáciles de medir y ya vinculadas a sistemas como CRM, ERP o mesas de ayuda.

Buenos primeros casos de uso incluyen la clasificación de soporte al cliente y el procesamiento de facturas. ¿Por qué estos primero? Pueden reducir rápidamente el trabajo manual y bajar los costes de servicio sin una gran revisión de procesos.

A partir de ahí, los equipos pueden ramificarse hacia el procesamiento de documentos, la extracción de datos y la generación de contenido.