Towards AI’s seneste udgave, opdateret 15. maj 2026, beskriver et tydeligt skifte: AI bevæger sig fra demos til produktion, og infrastrukturen rykker fra kulisse til kerneprodukt. Når agenter får lov at handle i rigtige systemer, er det ikke kun et promptspørgsmål. Det handler om pålidelig eksekvering, en robust platform og en arkitektur, der kan bære fejl i virkeligheden.
Towards AI kobler skiftet til en lagvis udvikling i praksis: fra store sprogmodeller til RAG, videre til agenter og mønstre som MCP. Det fremstilles som en syntese fra feltet, drevet af produktionserfaringer og fejlscenarier i virkelige systemer – ikke som en universel kronologi for alle organisationer.
Hvorfor det bider nu
Towards AI fremhæver et konkret produktionsproblem: agent‑retries kan udløse dublet‑handlinger, hvis systemet ikke er idempotent. Eksemplerne fra publikationen er klare: samme email sendt to gange, to refunds på samme ordre, duplikerede supporttickets eller et betalingsflow, der kører et trin igen. Argumentkontrol er ikke nok, fordi handlingen kan være gennemført, selv om input ligner.
Anbefalingen fra Towards AI er tilsvarende konkret: giv hvert værktøjskald en unik handling‑ID, gem status før eksekvering, og tjek status før et retry. Det er basale principper for transaktionel sikkerhed anvendt i agent‑arkitektur – og de mindsker de stille fejl, der ellers opdages sent.
Idempotens og handlingsstatus i praksis
Towards AI anbefaler at knytte en unik action‑ID til både brugerforespørgsel og handlingstype, skrive en “pending” status til et persistent lager før eksekvering og kun gentage efter statusopslag. Det kan suppleres med etableret API‑praksis: brug idempotency keys, når udbydere understøtter det (kilder: Stripe API‑dokumentation om idempotency keys og Adyen’s idempotency‑vejledning). For interne writes kan databaser håndhæve unikhed med constraints (kilde: PostgreSQL’s dokumentation om unique constraints).
Det operationelle mål er enkelt at teste: et retry må ikke skabe en ny sideeffekt, hvis den oprindelige handling allerede blev gennemført. Et korrelationsspor baseret på action‑ID gør både retry‑logik og efterfølgende fejlanalyse mulig uden gætteri.
Hvad der skal til ud over retries
Towards AI peger på, at tjek af argumenter ikke er nok, fordi en handling kan være sket alligevel. En simpel arkitekturregel følger heraf: ingen eksekverende værktøjskald uden forudgående persist af action‑ID og status samt et statuscheck før genkørsel. Det øger driftssikkerheden i betalings‑, ticket‑ og mailflows, hvor dubletter er dyre. Rådet er direkte afledt af eksemplerne i publikationen.
Summen er ikke prangende, men effektiv: gør handlinger sporbare og gentagelser harmløse. Det er mindre spektakulært end nye modelnavne, og det er præcis sådan, produktionssystemer undgår dubletfejl.
Voice agents kræver orkestrering
AWS beskriver, hvordan realtids‑stemmeagenter i produktion kræver et samspil: speech‑to‑speech‑modeller, lav‑latenstid audio‑streaming og styring af forbindelsens livscyklus på tværs af web, mobil og desktop. I deres gennemgang indgår Stream’s Vision Agents integreret med Amazon Bedrock og Amazon Nova 2 Sonic – med funktioner som function calling, automatisk genforbindelse og flersproget stemmestøtte – underbygget af kodeeksempler.
I AWS‑materialet er kravsbilledet praktisk: der er fokus på lav end‑to‑end latenstid og stabil session‑håndtering. Konkrete millisekundmål afhænger af brugssag og miljø og måles i den enkelte pipeline; kilderne angiver ikke universelle tal.
Fra demo til holdbarhed i produktion
Ifølge Snillds manual brief er udfordringen, særligt for virksomheder, at gøre AI holdbar ved at kombinere teknik og drift: robust MLOps med versionering, overvågning og rollback, klare eksekverings‑SLA’er, samt sikkerhed og datakvalitet fra start. Briefet fremhæver også behovet for observability på beslutningsstier.
Sammenholdt med Towards AI’s anbefalinger om action‑ID og statuspersist betyder det i praksis, at sporbarhed og idempotens bliver grundlaget, før man skalerer. Snillds brief vurderer, at fokus på engineering, governance og operationel modenhed er det, der flytter en løsning fra demo til drift.
Prioriteringer der kan implementeres
På linje med Towards AI’s råd bør et minimumskrav i agentprojekter være: ingen eksekverende værktøjskald uden en genereret action‑ID, der er persistet med status, før kaldet foretages. Før ethvert retry tjekkes status. For eksterne API’er bruges idempotency keys, hvor udbyderen understøtter det (kilder: Stripe, Adyen). For interne writes håndhæves unikhed via databasen (kilde: PostgreSQL unique constraints).
Snillds brief anbefaler derudover observability, så en agents beslutning kan korreleres til det konkrete værktøjskald og eksterne svar. Towards AI’s action‑ID‑spor gør den korrelation praktisk, når noget går galt.
Konkrete byggeklodser
Tre lavthængende greb kan løfte stabiliteten, alle kildeunderstøttede: 1) Idempotency keys ved eksterne POST‑kald, når udbyderen tilbyder det (kilder: Stripe, Adyen). 2) Unikke constraints i databasen på relevante domænenøgler, så samme handling ikke kan bogføres to gange (kilde: PostgreSQL). 3) Unik action‑ID og statuspersist før eksekvering frem for efter, så retries er sikre (kilde: Towards AI).
Fællesnævneren er enkel og veldokumenteret: bind handlinger til en ID, gem state før du handler, og slå state op før du gentager. Det reducerer de fejl, Towards AI advarer om, når agenter går fra demo til virkelige systemer.
Stemmesporet, kort opsummeret
AWS’ indlæg med Stream’s Vision Agents og Amazon Nova 2 Sonic viser, hvordan realtids‑stemmesystemer bygges med lav latenstid, robust session‑styring og funktioner som function calling og auto‑reconnect, understøttet af kodegennemgange. Materialet peger på konkrete integrationsmønstre, der kan løftes direkte ind i en produktionskontekst.
Den praktiske konsekvens følger kilderne: fokusér på lav latenstid gennem hele kæden og verificér stabilitet på tværs af platforme. Tærskler varierer efter brugssag og bør derfor måles og overvåges i egen pipeline.
Bundlinjen
Towards AI formulerer hovedlinjen skarpt: Skiftet fra demo til drift afhænger af, hvor moden infrastrukturen er. Når agenter får lov at handle, skal systemet kunne gentage uden dubletter og efterlade et spor, der kan forklares. Giv hver handling en ID, en status og et korrelationsspor. Resten kan bygges ovenpå.
