Que es Vento
Vento es una plataforma open-source para construir y conectar “objetos inteligentes” con IA: agentes que leen sensores, evalúan estados y ejecutan acciones sobre dispositivos reales (ESP32/ESPHome, MQTT, boards visuales y soporte MCP). Dicho en corto, Vento saca a los agentes de la pantalla y les da un lugar de trabajo en el mundo físico, donde una decisión ya no corrige un documento sino que enciende, apaga o mueve algo.
Problema
La mayoría de conversaciones sobre agentes sigue atrapada en software: tickets, código, documentos, CRM, dashboards, calendarios y chats.
Pero la empresa real no vive solo en pantallas. Vive también en almacenes, maquinaria, teléfonos, sensores, cámaras, bombas, puertas, vehículos, líneas de producción, equipos de campo y espacios físicos que no esperan a que un prompt termine.
Cuando un agente solo escribe, el riesgo principal es el output. Cuando un agente también actúa sobre dispositivos, el riesgo cambia de categoría: puede encender, apagar, mover, avisar, registrar, bloquear o abrir un proceso físico.
Ese salto necesita otro tipo de arquitectura.
Tesis
Vento importa porque plantea una pregunta que muchas empresas todavía no están listas para responder:
que pasa cuando el agente deja de ser interfaz y se convierte en sistema de control.
La señal no es “IA para IoT”. La señal es más profunda: agentes que leen estado físico, razonan sobre reglas y ejecutan acciones sobre actuadores. En ese terreno, la gobernanza no puede quedarse en prompts, dashboards o aprobaciones genéricas.
Necesitas un operating model para agentes con consecuencias físicas.
Framework
Un agente físico necesita cinco capas mínimas:
| Capa | Que controla | Pregunta crítica |
|---|---|---|
| sensores | que puede observar | el dato es fiable, fresco y calibrado |
| actuadores | que puede ejecutar | que acción puede producir daño o coste |
| estado | que condición cree que existe | que pasa si el estado llega tarde o incompleto |
| decisión | por que actúa | que regla, modelo o umbral justifico la acción |
| corte | como se detiene | quien puede parar, revertir o aislar el sistema |
La diferencia frente a un agente de oficina es clara: en software puedes corregir un documento. En físico, una mala decisión puede contaminar inventario, parar una máquina, abrir una puerta, activar una bomba o enviar a una persona al sitio equivocado.
Por que importa ahora
Vento se presenta como una plataforma open-source para construir y conectar “objetos inteligentes” con IA. Su repositorio describe una arquitectura donde los agentes leen sensores, evalúan estados y disparan acciones sobre dispositivos, con integración para ESP32/ESPHome, MQTT, agentes Go/Python/Android, boards visuales y soporte MCP.
Eso conecta tres tendencias que antes vivían separadas:
- IA agéntica: el sistema no solo contesta; decide una acción.
- IoT operativo: sensores y actuadores dejan de ser periferia técnica.
- No-code/visual ops: personas no necesariamente developers pueden modelar flujos y dispositivos.
La combinación es potente, pero también peligrosa si se vende como magia. “No coding required” reduce fricción de entrada. No reduce la necesidad de permisos, límites, simulación, observabilidad y kill switch.
Mini-caso: una pyme agrícola conecta sensores de humedad, una bomba de riego y alertas de campo. Un agente puede leer estado, detectar sequía y activar riego. Bien diseñado, ahorra visitas y evita perdidas. Mal diseñado, riega con datos obsoletos, ignora una válvula atascada o activa una acción cuando una persona esta haciendo mantenimiento.
Señal medible: porcentaje de acciones físicas ejecutadas por agentes con estado validado, límite de actuación, log reproducible y mecanismo de parada.
Postura: cuanto más cerca esta el agente del mundo físico, menos puede depender de confianza implícita.
Anti-ejemplo
“Si funciona con un sensor y una demo, lo conectamos a producción.”
Ese es el camino corto hacia automation debt. En un entorno físico, la demo suele ignorar las partes feas: sensores ruidosos, latencia, desconexión, mantenimiento, acciones simultaneas, contexto humano, condiciones ambientales y fallos mecánicos.
El agente no debe tener permiso porque entiende la instrucción. Debe tener permiso porque el sistema sabe contener su error.
Protocolo (3 pasos)
- Clasifica acciones por impacto. Leer temperatura no es lo mismo que encender una bomba, abrir una puerta o parar una máquina.
- Simula antes de actuar. Todo flujo físico debería tener modo sombra: el agente decide, pero no ejecuta, hasta comparar decisión y resultado esperado.
- Diseña el corte antes de la autonomía. Manual override, límites por tiempo, límite por coste, aislamiento de red y auditoría por acción.
| Riesgo | Ejemplo | Control mínimo |
|---|---|---|
| lectura incorrecta | sensor descalibrado | validación cruzada o umbral de confianza |
| acción irreversible | motor, bomba, cerradura | approval o límite físico de ejecución |
| estado obsoleto | dispositivo offline | fail closed y alerta |
| acción repetida | loop de encendido | rate limit y cooldown |
| contexto humano | mantenimiento en curso | bloqueo manual visible |
| fallo de modelo | razonamiento incorrecto | reglas deterministas para límites duros |
Relacionado
- Sandboxed Work: el nuevo perímetro de ejecución para agentes en producción
- Microsoft Foundry Local + Scout: cuando el trabajo agente se mueve al perímetro
- Tool Registry: el nuevo mapa de riesgos de los agentes enterprise
- Agent Identity: el pasaporte operativo que separa agente útil de riesgo invisible
Fuentes consultadas
Próximo paso
Elige un flujo físico donde hoy haya sensores, acción manual y coste por retraso. Antes de automatizarlo, dibuja tres listas: que puede observar el agente, que puede accionar y quien lo puede parar.
Si no puedes completar esas tres listas, no tienes un caso de IA física. Tienes una demo conectada a riesgo operativo.
Si ya tienes agentes conectados a dispositivos y no sabes cual es tu exposición real, una auditoría de IA mapea que ejecutan, quien los posee y donde se detienen antes de escalarlos.