Thinking Machines Lab har udgivet et forskningspreview af interaction models – en modelklasse, hvor interaktivitet er bygget ind i selve modellen i stedet for at blive klistret på i kanten. Ifølge laboratoriet, refereret af MarkTechPost, adresserer det en flaskehals i almindelig enterprise‑brug af AI netop nu. Timingen er oplagt: realtime har længe været på vej, men det meste har stadig føltes som pæn tur‑tagning med pauser og hårde kanter.
Hovedpointen i previewet er et opgør med vent‑og‑svar. Thinking Machines Lab argumenterer for, at modeller mister opmærksomhed både mens vi taster eller taler, og mens de selv genererer – en blindhed, der spænder ben for samarbejde. Forslaget er en multi‑stream, micro‑turn arkitektur, der lader modellen lytte, se og svare kontinuerligt. Mindre “sig noget, stilhed, vent” – mere som en kollega, der bekræfter, afbryder kort og samtidig slår noget op i baggrunden (kilde: MarkTechPost/Thinking Machines Lab).
Det er forskning – men sigter direkte ind i enterprise‑virkeligheden. Dagens realtidsstakke, der binder ASR, VAD, TTS og UI‑logik sammen, bliver langsomme og skrøbelige ved belastning. Thinking Machines Labs påstand er klar: skaler interaktiv adfærd i modellen, ikke i en ydre sele af komponenter (kilde: MarkTechPost/Thinking Machines Lab).
Hvorfor det er et praktisk problem
Ifølge Thinking Machines Lab hænger de fleste “realtids‑assistenter” i dag på en ydre harness – ofte med voice activity detection, der gætter, hvornår du er færdig med at tale. Den gætter jævnligt forkert. Resultatet er akavet stilhed eller afbrydelser netop som brugeren finder ordene frem (kilde: MarkTechPost).
Konsekvenserne er konkrete: når modellen er blind under input, mister den mikrotegn som tøven og afbrudte sætninger – og når perception fryser under generering, kan den ikke rette sig selv, hvis noget ændrer sig i rummet. MarkTechPost opsummerer det som en for snæver kanal for samarbejde mellem menneske og model.
Snillds erfaring: harness‑tilgangen skaber også teknisk gæld. Hvert ekstra led – VAD, separat ASR, TTS‑lag, timinglogik – forlænger kæden og øger risikoen for sync‑fejl. I et anonymiseret internt PoC i marts så vi, at et skred på omkring 150–200 ms mellem lyd og tekst, ophobet over minutter, gav en tydelig “robotstemme der svarer for sent”‑fornemmelse. Det er en enkelt observation, ikke en generel måling, men vi genkender mønsteret.
Arkitekturen forklaret teknisk men anvendelsesorienteret
Ifølge MarkTechPost/Thinking Machines Lab bygger designet på to samarbejdende modeller: en interaction model, der kører konstant og håndterer samtalen i realtid, og en background model, der tager de dybe, asynkrone opgaver. Fronten lytter, ser og svarer løbende; baggrunden slår op, bruger værktøjer, henter dokumenter og planlægger længere træk.
Når noget kræver længere tænkning, sender fronten en kontekstpakke til baggrunden – ikke kun et spørgsmål, men samtalens tilstand. Resultater strømmer tilbage løbende, og interaction‑modellen fletter dem ind, når det passer til, hvad brugeren gør i øjeblikket. Begge modeller deler kontekst kontinuerligt for at undgå huller (kilde: MarkTechPost).
Nøglen er micro‑turns. I stedet for hele inputture eller hele svar, arbejder modellen i små, tidsjusterede bidder. MarkTechPost beskriver en rytme omkring 200 ms input og 200 ms output ad gangen, så modellen kan tale, mens den lytter, reagere på et nik uden prompt og kalde værktøjer midt i samtalen. Previewet nævner tidlig, let fusion af lyd og video med minimal forbehandling. Retningen er tydelig: færre lag, kort pipeline, mere samtidighed. Det kræver en anden form for orkestrering end et klassisk request‑response API.
Praktiske konsekvenser for implementering og drift
Arkitektur først. En kontinuerlig, multi‑stream model kalder på event‑infrastruktur. I stedet for at poste tekst til et endpoint og få et svar, har du lyd, video, tekst, værktøjsopkald og baggrundsnoter, der alle er i bevægelse. Vores vurdering (Snilld): planlæg med event‑streaming og realtids‑orkestrering for at bevare styring af samtidighed, retries og rækkefølge. Vi hælder ofte til Kafka eller Redis Streams sammen med orkestrering som Temporal eller Netflix Conductor, fordi de er modne og har gode retries og historik. Det er præferencer, ikke universalløsninger – vælg efter jeres sprogstak, SRE‑kompetencer og latencykrav.
Sikker kontekstdeling som andet. Når interaktionen er kontinuerlig, flytter man ikke bare prompts – man flytter sessionstilstand. Det kræver adgangsstyring på kontekstpakker, ikke kun på API‑nøgler. Vores anbefaling (Snilld): kortlivede tokens, krypterede kontekstobjekter og eksplicitte politikker for, hvad background‑modellen må læse og skrive. Ellers kan brugerdata sive ind i utilsigtede logstrømme. Det har vi set ske. Oprydning tager tid.
Drift og overvågning som tredje. Kontinuerlige assistenter fejler sjældent med et tydeligt 500‑kald – de glider. Mål derfor latency pr. micro‑turn, drop‑rates på streams og konsistenskontroller for kontekst. I vores anonymiserede PoC faldt de oplevede hak først, da vi flyttede QoS‑logik ud i en lille stream‑gateway og begyndte at alarme på out‑of‑sync mellem ASR‑tokenstrøm og TTS‑buffer. Det er dér, oplevelsen står eller falder.
Case: Amazon Finance bekræfter retning
Bygger virksomheder allerede kontinuerte AI‑flows? Ja – typisk i tekstdomænet og med stærk state‑håndtering. AWS beskriver, hvordan Amazon Finance bruger generativ AI på Bedrock og andre tjenester til at strømline regulatoriske forespørgsler: udtrække information, hente støttedata fra flere systemer og samle svar inden for frister (kilde: AWS‑bloggen).
Det er ikke en interaction model i Thinking Machines Labs forstand, men peger i samme retning: fra ad‑hoc prompts til stateful, orkestrerede processer med klare ansvarsområder og løbende opdateringer. Casen viser, at enterprise‑skala på kontinuerlig videnshentning og svargenerering er mulig – og at governance og sporbarhed er en del af produktet, ikke en eftertanke.
Læser man AWS‑bloggen tæt, træder nogle mønstre frem: dedikerede knowledge bases pr. team, tydelig samtalestatus og integrationer på tværs af systemer. Det er de samme grundelementer, man får brug for, hvis en realtime front skal kobles med en dygtig baggrundsmodel. Samme orkestreringsproblem – bare uden lyd og video oveni.
Governance og compliance
Løbende modeller ændrer audit. Når kontekst flyder konstant, skal revisionsspor fange mikrobeslutninger – ikke kun slut‑svar. Vores anbefaling (Snilld): log beslutnings‑events med årsag og inputudsnit, men praktisér dataminimering. Nok til at forklare en handling, ikke nok til at genskabe hele indholdet af et følsomt opkald.
Gør det håndgribeligt. En beslutnings‑event kan fx logges med felter som: timestamp, trigger, context_hash, inputs (hash/udsnit), decision, responsible_agent, tool_calls, output_ref. Suppler med en enkel TTL‑strategi: f.eks. 30–90 dage for fulde kontekstudsnit i sikrede logs, længere retention for hashes og metadata. Det er ikke lovtekst – det er en operationel start, der kan godkendes.
Sporbarhed kræver kontrakter for kontekstpakker. Hvem ejer dem, hvor længe lever de, kan de tilbagekaldes midt i en samtale? Previewet beskriver ikke implementationen, så vær pragmatiske: definer TTL pr. datatype, brug revokerbare tokens, og lad baggrundsmodellen kun få det nødvendige – ikke hele butikken. Ellers kolliderer man hurtigt med både GDPR og mavefornemmelsen.
Hvad Snilld anbefaler — hands‑on
Vores anbefaling (Snilld) er at gå trinvist. Først et 4‑ugers analyse‑ og PoC‑forløb, hvor I måler end‑to‑end‑latency, kontekstintegritet og fejlmønstre på en smal use case. Foreslåede KPI‑mål for piloten: micro‑turn latency under ~200 ms i 95‑percentilen, maksimal stream drop‑rate 0,5 %, og målbar reduktion i kontekstskift per sag (baseline vs. pilot). Output: arkitekturvurdering, stream‑topologi og tre aftalte KPI’er, der giver mening for jeres drift.
Næste skridt er en 2‑ugers governance‑workshop med produkt, sikkerhed og drift. Vi definerer kontekstkontrakter, logningspolitik, dataminimering og godkendelsespunkter. Output: en praktisk do/don’t‑liste og et sæt standarder for events og adgang, som compliance faktisk kan godkende.
Til sidst en 6–12 ugers pilot, hvor en kontinuerlig assistent kobles på en baggrundsmodel og et event‑system. Fokus er drift og observability: micro‑turn latency, stream‑drop rates, context‑consistency checks og fallback‑strategier. Vi insisterer på en rullende “game day” hver uge – ellers opdager man først fejlene mandag kl. 08.12, når telefonerne ringer.
Omkostninger og måling
Realtime samarbejde koster andre ting end klassisk chat: GPU‑tid ved kontinuerlig lytning/produktion, netværksbåndbredde til flere samtidige streams, og persistens til events og sessionstilstand. Sæt derfor simple økonomi‑KPI’er i piloten: cost per aktiv session per minut, gennemsnitlig GPU‑sekunder per løst sagstrin, og netværksforbrug per session. Sammenlign med besparelse i håndteringstid og færre eskalationer. Det er ikke pæne tal i starten, men de bliver bedre med trimming.
Begrænsninger og åbne spørgsmål
Forskningspreviewet er stærkt på idé og arkitektur, men svagt på tal: ingen produktionsmålinger for latency, throughput eller driftsomkostning. Der er heller ikke peer‑review eller uafhængige benchmarks i materialet, vi har set. Det gør ren ROI‑beregning svær – og det er værd at notere tydeligt (kilde: MarkTechPost, egen vurdering).
Sikkerhedsdetaljer omkring delte kontekstpakker er ikke beskrevet. Hvilken kryptering, nøglestyring og hvordan audit kæder mikro‑events sammen, står åbent. Det samme gælder interoperabilitet: hvordan migrerer man fra dagens VAD‑baserede harness til en interaktionsmodel, og hvad kan genbruges?
Brugersikkerhed i realtid er heller ikke operationaliseret i previewet. Når en model kan handle proaktivt, mens du stadig taler – hvem sætter tempo og grænser? Vi savner også standarder for API‑kontrakter omkring kontekst og sync. Indtil da må hver virksomhed tage stilling – bevidst og eksplicit.
Alt i alt peger Thinking Machines Labs interaction models, som refereret af MarkTechPost, på et skifte fra queries til flows. Det føles rigtigt i hånden – hos os blev det tydeligt, da vi fjernede en enkelt heuristik, og samtalen pludselig gled. Det betyder ikke, at alle bør springe nu. Men hvis jeres frontlinjer lever af samtaler, sager og skiftende kontekst, er det værd at teste i et afgrænset hjørne. Man opdager forskellen, når man sidder med det i hænderne.
