0905 | Agentes con agenda: la nueva ola de la IA aplicada

||Download

Show notes

En este episodio recorremos la semana en IA: los nuevos modelos frontera de OpenAI y Google, agentes que ya tienen calendario y sistema operativo, herramientas que ponen contexto y métricas donde antes había puro ruido, y aplicaciones prácticas que van del clima a los comentarios web. Todo desde los lanzamientos y la discusión de Product Hunt.

Línea de tiempo

  • 00:00:04 Apertura
  • 00:00:44 Duelo de modelos frontera: GPT-6 Astra y Gemini 3.8
  • 00:05:27 Darles a los agentes un día de trabajo: calendario y sistema operativo
  • 00:09:56 Revisión visual del código cuando los agentes escriben todo
  • 00:12:32 Contexto y métricas donde antes había cajas negras
  • 00:14:57 Herramientas cotidianas: organigramas que se escriben solos y respuestas con contexto
  • 00:17:39 Aprender, comentar y predecir: IA para el día a día
  • 00:18:35 Cierre

Enlaces relacionados

Este episodio es producido por Bri. Bri usa tecnología avanzada de IA para convertir los feeds que te importan en podcasts pensados para escuchar. Puedes escribirnos a hi@bri.so.

Transcript

Clara Vega: ¡Hola y bienvenidos a otra edición del briefing! Yo soy Clara Vega.

Mateo Ruiz: Y yo Mateo Ruiz. Y sí, como suena, esto es un repaso de lo que se lanzó y se comentó en las últimas veinticuatro horas, con productos bien distintos entre sí pero con un hilo muy claro que los conecta: la inteligencia artificial dejó de ser un chat y se está convirtiendo en algo que trabaja, ejecuta, agenda y hasta se revisa a sí mismo.

Clara Vega: Exacto. Vamos a hablar de modelos frontera enfrentados, de agentes que tienen calendario laboral, de cómo revisas visualmente lo que un agente escribió, de herramientas que explican en lugar de solo etiquetar, y de apps cotidianas que te preguntan en lugar de que tú les escribas datos. Empezamos por lo más ruidoso del día: el duelo de modelos frontera.

Mateo Ruiz: Sí, porque ayer fue día grande. OpenAI presentó GPT-6 Astra, que describen como su modelo más capaz para trabajo de principio a fin: razonamiento complejo, ingeniería de software, uso de computadora, ciencia y trabajo profesional. Y lo interesante no es solo el número de versión, es para qué está construido.

Clara Vega: Para agentes, básicamente. Astra trae llamada asíncrona de herramientas y steering a mitad de tarea, o sea, puedes corregir el rumbo del modelo mientras está en medio de un flujo de varios pasos, no solo cuando terminó. Eso cambia la sensación de uso: uno de los comentarios en la discusión lo decía muy bien, que con mid-turn steering se siente como un compañero de trabajo real y no como una máquina tragamonedas.

Mateo Ruiz: Y hay detalles de disponibilidad y precio concretos. El identificador del modelo en la API es gpt-6-astra, con precio de diez dólares por millón de tokens de entrada y cincuenta por millón de salida en contexto corto. El despliegue es escalonado: primero vía Trusted Access y Daybreak, y después llegará a los planes Plus, Pro, Business, Enterprise y a la API en los próximos días.

Clara Vega: Y hay un dato de seguridad que no es menor: Astra es el primer modelo de OpenAI que cruza lo que llaman el umbral de capacidad crítica en ciberseguridad, con el acceso a capacidades ciber avanzadas limitado. Ojo, eso lo dice OpenAI, es su declaración, no una auditoría externa. Pero marca el tono de a dónde está llegando esta generación de modelos.

Mateo Ruiz: Hubo también una nota práctica en la discusión: un mensaje de Thibault Sottiaux decía que darán un reset bancado por cada día que no tengas acceso a Astra en tu plan de pago de ChatGPT. O sea, reconocen que el rollout está tardando y están compensando a los usuarios. Eso es honesto, pero también te dice que todavía no todo el mundo lo puede probar.

Clara Vega: Ahora, del otro lado del ring, Google movió ficha el mismo día con Gemini 3.8 Flash y Gemini 3.8 Flash Cyber. Y aquí el contraste es interesante, porque OpenAI está vendiendo el modelo más capaz y Google está vendiendo algo distinto: la relación entre inteligencia y costo.

Mateo Ruiz: Sí. Gemini 3.8 Flash está posicionado como el caballo de batalla más inteligente hasta ahora para código y agentes. Y hay cifras concretas: 73.7 por ciento en DeepSWE v1.1, que mide ingeniería de software de larga duración donde el modelo resuelve problemas complejos de forma autónoma. Ahí dicen que supera a la mayoría de modelos frontera más grandes, solo que a una fracción del costo.

Clara Vega: Y en Terminal-bench 2.1 llega al 89.4 por ciento, y en HLE-Verified, que cruza STEM, humanidades y campos profesionales, al 54.9 por ciento. También dicen que supera a 3.7 Flash y a otros modelos frontera en benchmarks de agentes financieros como Vals Finance Agent V2 y el benchmark de agente legal de Harvey. De nuevo: son resultados reportados por Google, no verificados por nosotros.

Mateo Ruiz: El detalle técnico que me parece el más interesante de la ficha del modelo es la explicación de por qué rinde así: 3.8 Flash trabaja más. En tareas complejas ejecuta pasos de razonamiento adicionales y llama herramientas de forma iterativa, y a veces gasta más tokens para maximizar rendimiento. Y si el costo de cómputo es tu restricción principal, puedes usar niveles de esfuerzo más bajos o quedarte en 3.7 Flash, que sigue soportado.

Clara Vega: En precio y disponibilidad: mismo precio de introducción que 3.7, setenta y cinco centavos y tres dólares setenta y cinco por millón de tokens hasta el treinta y uno de diciembre. Y está vivo hoy en la app de Gemini para Pro y Ultra, AI Studio, Antigravity, Gemini Enterprise y la API. Es el tercer lanzamiento Flash en seis semanas, o sea que el ritmo de Google aceleró muchísimo.

Mateo Ruiz: Y la variante Cyber es la respuesta de Google al tema que tocamos con Astra: Gemini 3.8 Flash Cyber está construida para defensores confiables, con foco en detección de vulnerabilidades y parcheo automatizado. Fíjate en el paralelo: OpenAI dice que cruzó un umbral ofensivo y lo limita; Google enfatiza el lado defensivo. Los dos laboratorios están hablando de ciberseguridad, pero desde ángulos distintos.

Clara Vega: Ahora, hay una pregunta que la comunidad hizo y que me parece la más importante de todo este bloque. Alguien preguntó: el steering a mitad de tarea funciona muy bien para llamadas a herramientas que puedes deshacer. Pero cuando un paso del flujo ya es externo y está comprometido, un pago hecho, un email enviado, una llamada telefónica que ya está sonando, ¿puedes todavía desviar al modelo de un plan que ya empezó a ejecutar? ¿O el steering solo aplica a lo que aún no salió del sandbox?

Mateo Ruiz: Y en la fuente no hay respuesta a eso. Es una pregunta abierta, y es la correcta, porque si los agentes van a operar en el mundo real, la utilidad del control en vivo depende exactamente de esa frontera. Dicho eso, la pregunta que se desprende de todo esto es: si tienes un modelo capaz de ejecutar flujos de varios pasos, ¿dónde y cómo lo pones a trabajar? Y justo ahí entra lo siguiente.

Clara Vega: Sí, porquehay herramientas que se plantean exactamente esa pregunta. La primera se llama Clockwork, y la idea se resume en una frase: el calendario donde tus agentes de IA se presentan a trabajar.

Mateo Ruiz: El creador, Vimox Shah, cuenta el origen: estaba pagando capacidad de Claude que estaba ociosa unas dieciocho horas al día, mientras reescribía a mano las mismas tareas de mantenimiento del repositorio cada semana. Su planteamiento es simple: si un agente puede hacer el trabajo, dale una jornada laboral. Un espacio en el calendario, un presupuesto, reglas de permisos, y un reporte cuando termina.

Clara Vega: ¿Y cómo funciona en concreto? Reservas un trabajo en un calendario real, con vista de mes, recurrencia, políticas para corridas perdidas y mutex por repositorio. Clockwork ejecuta el agente sin supervisión en un sandbox de macOS Seatbelt, dentro de un worktree de git por corrida, con las escrituras confinadas a ese worktree. Cuando algo se ve riesgoso, la corrida se pausa y te pregunta.

Mateo Ruiz: Y los límites son duros, no sugerencias. Topes de presupuesto en dólares, límites de turnos y timeouts de reloj de pared, y están impuestos por el supervisor, no por la buena intención del modelo. Eso es una frase del propio creador y me parece bien puesta, porque separa la política de ejecución del modelo que intenta cumplirla.

Clara Vega: Hay un punto de higiene de credenciales que vale la pena contar: el entorno de la corrida es una lista de permitidos, así que el SSH_AUTH_SOCK y los tokens de tus proveedores nunca llegan al proceso del agente. Y aquí viene lo que para mí es la mejor decisión del producto: no te piden que confíes en esa afirmación.

Mateo Ruiz: Exacto. El perfil de Seatbelt, la lista de denegación de credenciales y la lista de permitidos del entorno están publicados bajo Apache-2.0 en el repositorio, con pruebas que escriben un secreto falso en ~/.ssh y ~/.aws, y luego ejecutan cat dentro de un sandbox real y afirman que falla. El resto de la app es source-available bajo licencia propietaria, y el creador pide explícitamente que no lo llamen open source. Prefiere ser preciso antes que halagador, dice.

Clara Vega: Eso es raro y refrescante. En un mercado donde todo se llama "open source" por marketing, este tipo dice: la frontera de seguridad es abierta y verificable, la aplicación no, y no la llamamos de otra manera. Y también es honesto con las limitaciones: las corridas necesitan tu Mac despierta, mantiene el equipo despierto durante las ventanas reservadas cuando está conectado, y te avisa con estridencia cuando se perdió una corrida por suspensión.

Clara Vega: No está notarizado todavía, es solo Apple silicon por ahora, y es gratis, sin nivel de pago disponible hoy.

Mateo Ruiz: En la discusión hubo preguntas muy concretas que quedaron abiertas. Alguien preguntó qué pasa con una franja recurrente cuando la corrida anterior sigue esperando aprobación: ¿la salta, la encola, o arranca otro worktree aislado? Otro preguntó por el timeout de reloj de pared: si el agente está en medio de un commit o un rebase cuando se acaba su franja, ¿el supervisor deja terminar la operación de git o corta donde esté y deja el worktree a medio hacer para la siguiente corrida?

Clara Vega: Y otra pregunta muy práctica: si el agente pide aprobación a las dos de la mañana, ¿la franja muere o espera hasta que digas que sí? También pidieron webhooks, para ejecutar algo cada vez que hay un release nuevo. Ninguna de esas tiene respuesta en lo que tenemos; son exactamente los detalles que separan un demo de un sistema confiable.

Mateo Ruiz: Ahora, Clockwork le da a los agentes un lugar de trabajo en tu Mac. Pero hay un proyecto que va mucho más lejos en la misma dirección: Omarchy, el Linux de DHH, que presentaron en su versión 4.0.0 llamada Quattro. Y la idea es casi filosófica.

Clara Vega: Omarchy es un escritorio Arch con Hyprland, y lo que lo hace relevante en esta conversación es que está pensado para que los propios agentes puedan inspeccionarlo y reconfigurarlo. El argumento es que los archivos y los comandos son el idioma natural de los agentes, así que en vez de construir una interfaz para que el agente opere tu computadora, haces que el sistema operativo entero sea legible y manipulable por él.

Mateo Ruiz: O sea, Clockwork dice "te doy una franja aislada y con presupuesto", Omarchy dice "todo el escritorio es tuyo". Y con eso aparece la pregunta abierta que alguien dejó en la discusión y que me parece la más inquietante: si un agente rompe tu configuración, ¿cómo la reviertes con precisión? ¿Puedes ver exactamente qué cambió y deshacer solo eso? Eso es el mismo problema de gobernanza que mencionábamos con el steering, pero trasladado al sistema operativo.

Clara Vega: Y fíjate que esa pregunta conecta directo con lo siguiente, porque si los agentes van a escribir y modificar todo, alguien tiene que revisar el resultado. Y no solo el diff de código en un terminal: cómo se ve y se siente la cosa.

Mateo Ruiz: Para eso existe sidebranch. El creador parte de un argumento que me gustó porque no es hype: con el código agéntico, los equipos están produciendo miles de PRs en el tiempo que antes tomaba hacer unos pocos a mano. Con evals y verificación, nos acercamos a un mundo ideal donde el 99 por ciento de los PRs se escriben, se evalúan y se revisan enteramente por agentes. Pero queda el 1 por ciento donde todavía quieres experimentar en persona cómo se ve un feature antes de aprobarlo.

Mateo Ruiz: Y ese 1 por ciento es donde vive sidebranch.

Clara Vega: Concretamente: es una extensión de navegador emparejada con un daemon local. Desde un widget dentro de tu app corriendo, escoges cualquier rama y la construye en un worktree aislado en su propio servidor de desarrollo. Tu árbol de trabajo, cambios sin commit incluidos, jamás se toca. Y luego puedes comparar las dos versiones lado a lado, con modos de mezcla y "onion diff", donde los cambios de UI se resaltan.

Mateo Ruiz: Los detalles técnicos son limpios: es agnóstico al framework, Next, Vite, Django, Rails, cualquier cosa que responda HTTP en un puerto. Y cero dependencias: toda la herramienta son builtins de Node, sin paquetes externos. Solo loopback, o sea que no escucha en la red.

Clara Vega: Ahora, la comunidad no se quedó en el elogio, y eso es lo valioso de la discusión. Hubo dos críticas muy sustantivas. La primera, sobre seguridad: alguien señaló que "solo loopback, cero dependencias" suena como la respuesta de seguridad, pero lo que de verdad habría que examinar es la frontera entre la extensión del navegador y el daemon.

Clara Vega: Si el daemon escucha en un puerto local para servir cambios de worktree y diffs, ¿qué impide que otra pestaña u otro proceso local golpee ese mismo puerto y dispare un cambio de rama contra un repositorio que no debería tocar? Loopback mantiene fuera a internet, no automáticamente a lo que ya está en tu propia máquina.

Mateo Ruiz: Y es una crítica técnicamente sólida. La segunda crítica es sobre el flujo de trabajo: alguien que dice tener 111 flujos de un clic escribió que comparar dos ramas no es la parte difícil; lo difícil es saber qué pantalla abrir. Un PR agéntico puede mover silenciosamente algo en cualquiera de esos flujos, así que lo que necesita es una lista que diga "estas 4 páginas cambiaron visualmente, ve a mirar esas".

Mateo Ruiz: Si el sidecar pudiera recorrer las rutas y marcar las que se movieron, esa sería la versión que instalaría. Esa detección automática de páginas cambiadas es una limitación real y reconocida del producto tal como está.

Clara Vega: También preguntaron si podría servirle a los propios agentes: alguien usa agentes para construir mocks funcionales y quiere que el agente verifique visualmente, inspeccionando entre los diffs y por árbol de elementos, si está construyendo según el mock acordado. Eso también quedó como pregunta abierta.

Mateo Ruiz: Bueno, hasta aquí hemos hablado de agentes que producen trabajo. Pero hay otro frente del mismo problema: cuando la IA detecta o clasifica algo, un label no basta. Quieres contexto y explicación. Y ahí entramos en Compliance by TwelveLabs.

Clara Vega: Es una aplicación SaaS que revisa tu biblioteca de video contra reglas que escribe tu equipo, no ellos. Ingiere el material, aplica tus propios paquetes de reglas de cumplimiento, y devuelve hallazgos listos para revisión, con contexto, no solo un timestamp y una etiqueta. Está impulsado por su modelo Pegasus, que explica por qué un momento puede violar una regla, para que el revisor acepte, rechace o anote en una sola cola.

Mateo Ruiz: Simon, el jefe de Field Engineering, explicó el problema de origen, y es una frase que vale repetir: si los revisores tienen que volver a ver el video entero para validar las alertas de la IA, ¿qué hemos ahorrado realmente? La revisión de cumplimiento sigue siendo mayormente manual, y cada mercado trae reglas distintas. Detectar "violencia" no es suficiente; el revisor necesita entender qué pasó, en qué contexto y por qué importa bajo la política que está aplicando.

Clara Vega: Por eso el énfasis está en que los equipos de cumplimiento son dueños de sus reglas: adaptan paquetes regionales, editan reglas, ajustan umbrales y publican versiones sin esperar al proveedor. Además hay detección de medios sintéticos integrada: el detector de video sintético de NVIDIA suma puntuación a nivel de cuadro junto al análisis contextual. Y los hallazgos vienen con reportes firmados y acceso por API.

Mateo Ruiz: Un detalle de honestidad con las metas: plantean como objetivo una tasa de rechazo de revisores del 15 por ciento o menos. Ojo: eso es una meta declarada, no un resultado verificado. Uno de los comentarios lo tomó como métrica de falsos positivos y tiene sentido interpretarla así, menos tiempo persiguiendo falsas alarmas, más tiempo en decisiones que requieren juicio humano.

Clara Vega: Pero el mismo comentarista hizo la observación más importante de toda la discusión: para una herramienta de cumplimiento, la preocupación real está en la otra dirección. Los falsos positivos los atrapa eventualmente un humano en la cola; un falso negativo simplemente nunca aparece. La violación que la IA no marca jamás es la que nadie revisa.

Clara Vega: Y preguntó directamente: ¿hay forma de muestrear el material "aprobado" para atrapar lo que Pegasus dejó pasar, o el sistema entero depende de que el paquete de reglas esté completo desde el inicio?

Mateo Ruiz: Y eso no tiene respuesta en la fuente. Es la pregunta que cualquier comprador serio debería hacer, y nota el patrón con lo que vimos en los modelos: la métrica que te dan dice algo, pero la métrica que te falta puede decirlo todo.

Clara Vega: Bueno, de la IA que revisa trabajo pasemos a la IA que organiza a las personas. Y esta es quizás la más simple y la más ingeniosa del día: Snitch.

Mateo Ruiz: Snitch es un agente de Slack con una sola función muy específica: ser dueño del organigrama. Hace una pregunta a cada persona de tu Slack, ¿a quién reportas?, y construye el organigrama con las respuestas. Después responde preguntas sobre él: cadenas de mando, tamaños de equipo, quién es dueño de qué. Sin sistema de RRHH que conectar, sin nada que llenar manualmente.

Clara Vega: El giro clave es quién hace la entrada de datos. Nada se infiere de un campo de perfil, nada se adivina: cada línea la declara la persona que está parada sobre ella. Y cuando alguien entra nuevo, Snitch le manda el mensaje esa misma mañana y queda en el gráfico antes de que le llegue la laptop. Si hay una reorganización, la persona le dice a Snitch y la línea se mueve con ella.

Clara Vega: Cuando un jefe se va y tres personas siguen reportando a la silla vacía, Snitch lo marca y les vuelve a hacer la pregunta.

Mateo Ruiz: También se delata a sí mismo, en el buen sentido: marca gerentes faltantes, ciclos de reporte, el ocasional segundo CEO. Y responde preguntas en lenguaje natural en cualquier canal: "@Snitch, ¿cuántas personas reportan hacia mí, todos los niveles?" y responde con el número y las ramas.

Clara Vega: En cuanto a privacidad, la FAQ aborda directamente la pregunta "¿esto es espeluznante?": solo maneja cosas que tus colegas ya dicen en voz alta, cada quien responde por sí mismo, no hay forma de presentar un reporte sobre otra persona, nadie recibe un DM hasta que un admin aprueba el texto exacto, y el gráfico terminado es visible solo en tu workspace.

Mateo Ruiz: El proceso de implementación es de tres pasos: autorizas por OAuth de Slack, Snitch lee el directorio y no hace nada hasta que lo digas, tú apruebas las rondas, puedes excluir gente y leer el mensaje exacto, y lanzas. Todo el mundo responde en dos toques. Y hay precio concreto: Starter a 19 dólares al mes hasta 50 personas, Growth a 39 de 51 a 100, Scale a 59 de 101 a 200. Y ahora mismo, 45 días gratis sin tarjeta.

Clara Vega: Y de nuevo la comunidad puso el dedo en la llaga. Hubo dos preguntas que quedaron abiertas. La primera: la pregunta de "¿a quién reportas?" funciona el día uno, pero el mes seis es lo que preocupa, ¿Snitch vuelve a preguntar cuando alguien cambia de equipo o el gráfico se va a la deriva? Aunque el sitio muestra que sí se actualiza cuando la persona misma lo dice, la duda es sobre las personas que no avisan.

Mateo Ruiz: Y la segunda es la que yo haría: los reportes de línea punteada. En empresas grandes mucha gente reporta a una persona para headcount y a otra distinta para el trabajo del día a día. ¿Snitch permite dos respuestas, o fuerza un solo "¿a quién reportas?" y se queda con la que escribas primero? Esa distinción es donde los organigramas de verdad se rompen.

Clara Vega: Bueno, Mateo, recapitulemos un poco, porque mirando todo el día en conjunto se ve un patrón clarísimo.

Mateo Ruiz: Sí. Los modelos frontera ya no compiten en conversación, compiten en ejecución: flujos de varios pasos, herramientas asíncronas, control a mitad de tarea. Y toda la capa de producto de abajo está resolviendo las consecuencias de eso: dónde corren los agentes, con qué presupuesto, quién aprueba lo riesgoso, cómo revisas lo que producen, cómo verificas que lo que detectaron es real, y cómo capturas la información que antes vivía en cabezas y hojas de cálculo.

Clara Vega: Y en todos los casos, las preguntas más agudas no vinieron del marketing sino de la comunidad: ¿el steering funciona cuando el paso ya se ejecutó? ¿Cómo reviertes con precisión lo que un agente rompió? ¿Cómo detectas las páginas que un PR movió silenciosamente? ¿Cómo atrapas la violación que nunca se marca? ¿El organigrama se mantiene al mes seis?

Mateo Ruiz: Ninguna tiene respuesta todavía, y eso no es una debilidad del análisis, es exactamente el estado del arte: las herramientas llegaron antes que las respuestas de gobernanza.

Clara Vega: Así es. Eso fue todo por hoy. Gracias por acompañarnos, y nos vemos en el próximo briefing.

Mateo Ruiz: ¡Hasta la próxima!