ESP-Mosaico: qué cambia cuando la IA empieza a trabajar con hardware
Gonzalo Gálvez ·
Espressif presentó ESP-Mosaico. Mi lectura sobre los agentes de IA, los prototipos físicos y las pruebas que importan al crear juguetes conversacionales.
El 20 de octubre de 2026, Espressif presentó ESP-Mosaico. Su propuesta lleva los agentes de IA al desarrollo de hardware modular. Me interesa qué pueden aportar cuando reciben información del dispositivo.
Para quienes pensamos en objetos con los que una persona puede hablar, jugar o crear, esa pregunta merece más atención que una lista de especificaciones. Quiero compartir mi lectura del anuncio y las pruebas que me gustaría exigir a cualquier prototipo que termine en una casa.
Qué trae esta novedad
Según Espressif, la plataforma combina una unidad con pantalla y módulos, y permite a los agentes generar, compilar y probar aplicaciones usando información del hardware conectado.
Es una plataforma para desarrollar prototipos. El anuncio describe capacidades del fabricante; este artículo es una reflexión sobre ellas, sin una evaluación práctica del equipo.
Espressif describe ejecución local para las funciones que no dependen de servicios en línea. Esa afirmación no aclara, por sí sola, dónde se ejecuta cada modelo de IA ni qué datos procesa un producto terminado.
Lo que me interesa como creador de Nebu
Imaginemos una idea sencilla: un objeto que propone el comienzo de una historia y espera a que la persona la continúe. Para probarla hacen falta varias decisiones: cómo empieza el turno, cómo se reconoce una interrupción, cuánto dura una respuesta y qué señal indica que el aparato está escuchando.
Poder cambiar esas reglas y comprobar el resultado sobre un dispositivo abre una forma interesante de explorar. Me gustaría usar esa rapidez para comparar comportamientos concretos: una respuesta breve frente a una larga, una señal luminosa frente a un sonido, o una petición abierta frente a otra más guiada.
Cada comparación necesita una pregunta clara. «Genera una experiencia divertida» deja demasiadas cosas a la interpretación. «Deja de hablar cuando se pulsa el botón y espera una nueva petición» permite observar si el comportamiento esperado realmente ocurre.
Esa diferencia entre una intención y una prueba es donde pondría buena parte del trabajo.
Una demo también debe pasar por los días difíciles
Para un prototipo de juguete conversacional, prepararía al menos estas pruebas:
- Se corta internet a mitad de una interacción. Observar qué oye la persona, cómo se comunica la interrupción y qué debe hacer para continuar.
- Hay ruido o dos personas hablan a la vez. Comprobar si el sistema pide repetir la frase o responde a algo que entendió mal.
- La persona decide terminar. Verificar que el control para detener la interacción siga siendo fácil de encontrar y usar.
- El sistema entrega una respuesta equivocada. Revisar cómo puede un adulto intervenir y orientar la conversación.
- Se actualiza el software. Repetir las pruebas anteriores y comprobar que los cambios conservan los comportamientos que ya habíamos aceptado.
Estas son pruebas que propongo como criterio de diseño. Para afirmar que un producto las supera hacen falta resultados observados y documentados.
La velocidad ayuda cuando deja evidencia
Otra novedad reciente apunta en esa dirección. El 16 de octubre, Espressif publicó la versión 2.3.0 de su extensión de ESP-IDF para VS Code. Entre sus funciones, permite enviar la salida de una compilación fallida al chat de IA para ayudar a diagnosticar el problema.
Me parece útil que el trabajo parta de un error concreto, con información que otro desarrollador pueda revisar. Aplicaría el mismo criterio a una experiencia de voz: guardar qué comportamiento se esperaba, cómo se probó y qué ocurrió realmente.
Un registro así permite volver a una decisión semanas después y entenderla. También ayuda a descubrir cuándo un cambio que parecía pequeño alteró otra parte de la experiencia.
Qué puede mirar una familia
La familia que elige un juguete conectado puede llevar esta conversación a preguntas muy prácticas: ¿cómo se apaga?, ¿qué necesita para funcionar?, ¿qué ocurre si pierde la conexión?, ¿dónde se explican los datos que procesa?
Cuando miro herramientas nuevas, me interesa saber si facilitarán responder esas preguntas con ejemplos comprensibles. Una buena demostración debería permitir ver tanto una interacción que sale bien como la forma de terminarla o recuperarse de un fallo.
Si estás comenzando a explorar este tipo de objetos, en el blog tenemos una guía sobre qué es un peluche con IA y cómo funciona. Puede servir para comparar propuestas antes de decidir qué encaja con tu familia.
ESP-Mosaico me deja con ganas de explorar prototipos más fáciles de observar y modificar. La prueba que me gustaría ver es sencilla de describir: proponer una interacción, ejecutarla en el objeto y poder explicar, con evidencia, qué ocurrió.
Nota editorial: las ideas de este artículo no anuncian una incorporación de ESP-Mosaico ni nuevas prestaciones en los modelos actuales de Nebu.