Problema
La mayoria de conversaciones sobre agentes sigue atrapada en software: tickets, codigo, documentos, CRM, dashboards, calendarios y chats.
Pero la empresa real no vive solo en pantallas. Vive tambien en almacenes, maquinaria, telefonos, sensores, camaras, bombas, puertas, vehiculos, lineas de produccion, equipos de campo y espacios fisicos que no esperan a que un prompt termine.
Cuando un agente solo escribe, el riesgo principal es el output. Cuando un agente tambien actua sobre dispositivos, el riesgo cambia de categoria: puede encender, apagar, mover, avisar, registrar, bloquear o abrir un proceso fisico.
Ese salto necesita otro tipo de arquitectura.
Tesis
Vento importa porque plantea una pregunta que muchas empresas todavia no estan listas para responder:
que pasa cuando el agente deja de ser interfaz y se convierte en sistema de control.
La senal no es “IA para IoT”. La senal es mas profunda: agentes que leen estado fisico, razonan sobre reglas y ejecutan acciones sobre actuadores. En ese terreno, la gobernanza no puede quedarse en prompts, dashboards o aprobaciones genericas.
Necesitas un operating model para agentes con consecuencias fisicas.
Framework
Un agente fisico necesita cinco capas minimas:
| Capa | Que controla | Pregunta critica |
|---|---|---|
| sensores | que puede observar | el dato es fiable, fresco y calibrado |
| actuadores | que puede ejecutar | que accion puede producir dano o coste |
| estado | que condicion cree que existe | que pasa si el estado llega tarde o incompleto |
| decision | por que actua | que regla, modelo o umbral justifico la accion |
| 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 fisico, una mala decision puede contaminar inventario, parar una maquina, 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, evaluan estados y disparan acciones sobre dispositivos, con integracion para ESP32/ESPHome, MQTT, agentes Go/Python/Android, boards visuales y soporte MCP.
Eso conecta tres tendencias que antes vivian separadas:
- IA agentica: el sistema no solo contesta; decide una accion.
- IoT operativo: sensores y actuadores dejan de ser periferia tecnica.
- No-code/visual ops: personas no necesariamente developers pueden modelar flujos y dispositivos.
La combinacion es potente, pero tambien peligrosa si se vende como magia. “No coding required” reduce friccion de entrada. No reduce la necesidad de permisos, limites, simulacion, observabilidad y kill switch.
Mini-caso: una pyme agricola conecta sensores de humedad, una bomba de riego y alertas de campo. Un agente puede leer estado, detectar sequia y activar riego. Bien disenado, ahorra visitas y evita perdidas. Mal disenado, riega con datos obsoletos, ignora una valvula atascada o activa una accion cuando una persona esta haciendo mantenimiento.
Senal medible: porcentaje de acciones fisicas ejecutadas por agentes con estado validado, limite de actuacion, log reproducible y mecanismo de parada.
Postura: cuanto mas cerca esta el agente del mundo fisico, menos puede depender de confianza implicita.
Anti-ejemplo
“Si funciona con un sensor y una demo, lo conectamos a produccion.”
Ese es el camino corto hacia automation debt. En un entorno fisico, la demo suele ignorar las partes feas: sensores ruidosos, latencia, desconexion, mantenimiento, acciones simultaneas, contexto humano, condiciones ambientales y fallos mecanicos.
El agente no debe tener permiso porque entiende la instruccion. 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 maquina.
- Simula antes de actuar. Todo flujo fisico deberia tener modo sombra: el agente decide, pero no ejecuta, hasta comparar decision y resultado esperado.
- Disena el corte antes de la autonomia. Manual override, limites por tiempo, limite por coste, aislamiento de red y auditoria por accion.
| Riesgo | Ejemplo | Control minimo |
|---|---|---|
| lectura incorrecta | sensor descalibrado | validacion cruzada o umbral de confianza |
| accion irreversible | motor, bomba, cerradura | approval o limite fisico de ejecucion |
| estado obsoleto | dispositivo offline | fail closed y alerta |
| accion repetida | loop de encendido | rate limit y cooldown |
| contexto humano | mantenimiento en curso | bloqueo manual visible |
| fallo de modelo | razonamiento incorrecto | reglas deterministas para limites duros |
Relacionado
- Sandboxed Work: el nuevo perimetro de ejecucion para agentes en produccion
- Microsoft Foundry Local + Scout: cuando el trabajo agente se mueve al perimetro
- Tool Registry: el nuevo mapa de riesgos de los agentes enterprise
- Agent Identity: el pasaporte operativo que separa agente util de riesgo invisible
Fuentes consultadas
Proximo paso
Elige un flujo fisico donde hoy haya sensores, accion 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 fisica. Tienes una demo conectada a riesgo operativo.