Problem
De fleste samtaler om agenter sidder stadig fast i software: tickets, kode, dokumenter, CRM, dashboards, kalendere og chats.
Men den virkelige virksomhed lever ikke kun på skærme. Den lever også i lagre, maskiner, telefoner, sensorer, kameraer, pumper, døre, køretøjer, produktionslinjer, felthold og fysiske rum, der ikke venter på, at et prompt bliver færdigt.
Når en agent kun skriver, er hovedrisikoen outputtet. Når en agent også handler på enheder, skifter risikoen kategori: den kan tænde, slukke, flytte, advare, registrere, låse eller åbne en fysisk proces.
Det spring kræver en anden type arkitektur.
Tese
Vento er vigtig, fordi den rejser et spørgsmål, som mange virksomheder stadig ikke er klar til at svare på:
hvad sker der, når agenten holder op med at være en grænseflade og bliver et styresystem.
Signalet er ikke “AI til IoT”. Signalet er dybere: agenter, der læser fysisk tilstand, ræsonnerer over regler og udfører handlinger på aktuatorer. I det terræn kan governance ikke blive i prompts, dashboards eller generiske godkendelser.
Du har brug for en driftsmodel for agenter med fysiske konsekvenser.
Rammeværk
En fysisk agent har brug for mindst fem lag:
| Lag | Hvad det styrer | Kritisk spørgsmål |
|---|---|---|
| sensorer | hvad den kan observere | er data pålidelige, friske og kalibrerede |
| aktuatorer | hvad den kan udføre | hvilken handling kan skade eller koste |
| tilstand | hvilken betingelse den tror eksisterer | hvad sker der, hvis tilstanden er forsinket eller ufuldstændig |
| beslutning | hvorfor den handler | hvilken regel, model eller tærskel berettiger handlingen |
| stop | hvordan den standses | hvem kan stoppe, tilbageføre eller isolere systemet |
Forskellen i forhold til en kontoragent er tydelig: i software kan du rette et dokument. I fysisk kan en dårlig beslutning kontaminere lager, stoppe en maskine, åbne en dør, aktivere en pumpe eller sende en person det forkerte sted hen.
Hvorfor det er vigtigt nu
Vento præsenterer sig som en open-source platform til at bygge og forbinde “smarte objekter” med AI. Dets repository beskriver en arkitektur, hvor agenter læser sensorer, evaluerer tilstande og udløser handlinger på enheder, med integration til ESP32/ESPHome, MQTT, Go/Python/Android-agenter, visuelle boards og MCP-understøttelse.
Det forbinder tre tendenser, der før levede hver for sig:
- Agentisk AI: systemet svarer ikke kun; det beslutter en handling.
- Operationel IoT: sensorer og aktuatorer stopper med at være teknisk periferi.
- No-code/visual ops: personer, der ikke nødvendigvis er udviklere, kan modellere flows og enheder.
Kombinationen er stærk, men også farlig, hvis den sælges som magi. “No coding required” reducerer adgangsbarrierer. Det reducerer ikke behovet for tilladelser, grænser, simulering, observerbarhed og kill switch.
Mini-case: en lille landbrugsvirksomhed forbinder fugtighedssensorer, en vandingspumpe og markalarmer. En agent kan læse tilstand, opdage tørke og aktivere vanding. Godt designet sparer den besøg og undgår tab. Dårligt designet vander den med forældede data, ignorerer en tilstoppet ventil eller aktiverer en handling, mens en person udfører vedligehold.
Målbart signal: procentdel af fysiske handlinger udført af agenter med valideret tilstand, aktuatorgrænse, reproducerbar log og stopmekanisme.
Holdning: jo tættere agenten er på den fysiske verden, desto mindre kan den stole på implicit tillid.
Anti-eksempel
“Hvis det virker med en sensor og en demo, kobler vi det til produktion.”
Det er den korte vej til automation debt. I et fysisk miljø overser demoen normalt de grimme dele: støjende sensorer, latenstid, afbrydelser, vedligeholdelse, samtidige handlinger, menneskelig kontekst, miljøforhold og mekaniske fejl.
Agenten skal ikke have tilladelse, fordi den forstår instruktionen. Den skal have tilladelse, fordi systemet ved, hvordan dets fejl kan inddæmmes.
Protokol (3 trin)
- Klassificér handlinger efter impact. At læse temperatur er ikke det samme som at tænde en pumpe, åbne en dør eller stoppe en maskine.
- Simulér før du handler. Ethvert fysisk flow bør have en skygge-tilstand: agenten beslutter, men udfører ikke, før beslutning og forventet resultat er sammenlignet.
- Design stoppet før autonomien. Manuel overstyring, tidsgrænser, omkostningsgrænse, netværksisolering og revision pr. handling.
| Risiko | Eksempel | Minimumskontrol |
|---|---|---|
| forkert aflæsning | ikke-kalibreret sensor | krydsvalidering eller konfidensgrænse |
| irreversibel handling | motor, pumpe, lås | godkendelse eller fysisk eksekveringsgrænse |
| forældet tilstand | offline enhed | fail closed og alarm |
| gentaget handling | tænd-loop | rate limit og cooldown |
| menneskelig kontekst | vedligehold i gang | synlig manuel blokering |
| modelfejl | forkert ræsonnement | deterministiske regler for hårde grænser |
Relateret
- Sandboxed Work: den nye eksekveringsperimeter for agenter i produktion
- Microsoft Foundry Local + Scout: når agentarbejdet flyttes til periferien
- Tool Registry: det nye risikokort for enterprise-agenter
- Agent Identity: det operationelle pas der adskiller nyttig agent fra usynlig risiko
Konsulterede kilder
Næste skridt
Vælg et fysisk flow, hvor der i dag er sensorer, manuel handling og omkostning ved forsinkelse. Før du automatiserer det, skal du tegne tre lister: hvad agenten kan observere, hvad den kan aktivere, og hvem der kan stoppe den.
Hvis du ikke kan udfylde de tre lister, har du ikke et fysisk AI-case. Du har en demo forbundet til operationel risiko.
Oversat fra den spanske original med AI-hjælp og gennemset for nøjagtighed. Læs originalen på spansk.