En ny builder‑tutorial på MarkTechPost går et skridt, mange demoprojekter springer over: den giver en agent både vedvarende hukommelse, operationel kontekst og evnen til at skrive tilbage til databasen. Scenariet er bevidst fiktivt – et premium tennisevent kaldet “MongoDB Open” på dag 6 – og ikke en produktionsdeploy eller kundecase. Alligevel er pointen reel: her begynder agenter at ligne noget, man kan drive forretning på – ikke bare en pæn demo.
Hvad tutorialen rent faktisk viser
Ifølge tutorialen er målet ikke at lave endnu en “planlæg vejret for mig”-chatbot. Agenten skal kunne læse aktuel tilstandsdata for arenaen, hente tidligere erfaringer og segmenteret gæstekontekst, reagere på ændringer (regn på vej, begrænset overdækket kapacitet) og skrive en konklusion tilbage som memory til næste gang et lignende mønster opstår. Det er et flow, ikke en enkelt prompt.
Forløbet er bundet op på to fiktive gæster, Mikiko (førstegangsbesøgende) og Nina (premium‑gæst med historik). Agenten skelner mellem dem, prioriterer forskelligt og forsøger at beskytte oplevelsen, mens der stadig er ledig hospitality‑kapacitet. Stramt fortalt – og rigtigt tænkt ift. drift.
Komponenterne og hvordan de hænger sammen
Arkitekturen er tredelt: 1) En guidet, deterministisk UI med fire faner, der gør historien let at følge. 2) En hosted Vercel‑demo med et offentligt link. 3) Live API’er og scripts: Atlas Vector Search, hybrid retrieval (vektor plus leksikal scoring), visual‑dokument RAG ind i en vision‑model, LangGraph‑kørsel og valgfri Langfuse‑traces. Backenden er en FastAPI‑app, der kan køre lokalt og deployes til Vercel.
I databasen oprettes flere collections: operationel tilstand, semantisk hukommelse, agenthandlinger og LangGraph‑checkpoints. Embeddings er Voyage multimodale, lagret i Atlas, og søgningen går via Atlas Vector Search. Der er også et endpoint, som kombinerer vektorlignende matchning med klassiske søgetermer. Hybrid‑delen bliver vigtig for relevans senere.
Hvad agenten faktisk gør i demoen
Agenten læser “venue state” i Atlas, kalder retrieval for at hente tilsvarende hændelser og gæsteprofiler og vurderer kapacitetslofter. Den tilpasser valgene efter segmentet (Mikiko vs. Nina), reagerer på et vejrvindue (regn om lidt) og reserverer handlinger, før kapaciteten ryger. Resultatet – en konklusion plus hvad der blev gjort – skrives tilbage som en memory‑post. Det giver en spiral, hvor næste disruption kommer med mere kontekst.
Det hele er bundet op på en LangGraph‑graf, som i tutorialens udgave stadig kører som script‑validering og ikke som et offentligt endpoint. Forløbet understøttes af valgfri Langfuse‑tracing, så man kan se, hvad retrieval og orkestrering lavede undervejs.
Hvorfor vedvarende hukommelse og write‑back ændrer spillet
At kunne skrive tilbage bryder med de fleste lab‑demos. Med write‑back opstår tre krav: adgangsstyring, konfliktkontrol og revisionsspor. Man bør kun tillade, at bestemte handlinger persistenteres – med klare roller og politikker. Og når to processer konkurrerer om den sidste overdækkede plads, skal man have låse, idempotens og transaktionsgrænser, så man ikke sælger samme stol to gange.
RAG og vektorlageret i Atlas er ikke pynt; de er kontekstmotoren. Her kan historik, gæsteoptegnelser og dokumenter – driftsplaner, seating charts, sikkerhedsanvisninger – hentes effektivt. Når retrieval bliver en primær komponent, bliver datamodellen, index‑design og vedligeholdelse vigtigere end selve prompten. Det lyder banalt, men er det sjældent i praksis.
Sikkerhed, governance og audit – de ubehagelige men nødvendige spørgsmål
Tutorialen demonstrerer write‑back, men beskriver ikke en produktionsklar auth‑ eller rollekontrol. Det efterlader åbne spørgsmål: Hvem må skrive hvilke memorytyper? Hvornår kræves menneskelig godkendelse? Hvilke felter må agenten aldrig røre? Hvilken retention gælder for gæsteprofiler og hændelseslog?
Auditlogning er det næste. Hver beslutning bør have et revisionsspor: hvilke dokumenter blev læst, hvilke embeddings blev brugt, hvilke værktøjskald skete i hvilken rækkefølge, og hvem (eller hvad) autoriserede ændringen. Uden sporbarhed bliver det svært at forklare fejlvurderinger over for ledelse eller myndigheder. GDPR spøger også: persistente “guest memories” kræver formål, lovhjemmel, slettepolitik og gennemsigtighed. Tutorialen rører ikke disse emner i dybden; det hul skal lukkes før go‑live.
Performance og retrieval – hybrid er godt, men ikke gratis
Atlas Vector Search giver solid ydeevne til semantiske opslag, og hybrid retrieval øger ofte præcisionen, især når data er blandet eller ordvalg varierer. Men hver ekstra retrievalvej koster: flere indexer, større lagringsaftryk, flere scoringstrin, potentielt ekstra round‑trips. Latenstid stiger, og under event‑load føles selv 200‑300 ms ekstra dyrt, når man kun har et 20‑minutters vindue til at flytte gæster rundt.
Tutorialen indeholder ikke benchmarks for embeddings‑opsætninger, indexstørrelser eller latenstid. Fair for en builder‑demo – men produktionshold bør planlægge egne tests: top‑k, re‑ranking, ANN‑parametre og hvor cut‑off for hybrid skal ligge pr. forespørgselstype. Ellers bliver omkostninger og performance et gæt.
Observérbarhed, tracing og rollback
Langfuse optræder som valgfrit. Alligevel er det en af de vigtigste tråde i hele historien. Uden tracing ved man ikke, hvorfor agenten vælger, som den gør. LangGraph‑checkpoints er et andet konkret plus: de gør grafens tilstand inspicerbar og muliggør at hoppe tilbage og køre forfra efter en rettelse. Det er ikke bare rart for udvikling; det er produktionshåndværk – især når write‑back er slået til.
I praksis skal observérbarhed kobles med alarmer og simple guardrails: hvis latenstid stiger over en tærskel, skift til kun‑lexical fallback. Hvis konfidens er lav, pause write‑back. Hvis kontekstvinduet fyldes af gentagelser, de‑duplikér memory før nye kørselstrin. Tutorialen peger på mekanismerne, men overlader ingeniørarbejdet til læseren.
Hvorfor det betyder noget økonomisk
Tutorialen henviser til, at 2025‑udgaven af US Open slog rekorder i fremmøde, seertal og digital rækkevidde – og at der blev udbetalt 90 millioner dollars i samlet præmiepenge. Den nævner også USTA’s påstand om mere end 1,2 milliarder dollars i årlig økonomisk effekt for New York City samt PwC‑tal om, hvor meget velhavende amerikanske sportsfans vil bruge på særlige events. Tallene er anført som kontekst i tutorialen; før man citerer dem som faktum i en dybdeanalyse, bør originalkilderne dobbelttjekkes.
Pointen holder alligevel: marginale forbedringer i “guest experience” kan være pengene værd i en branche, hvor kapacitet er knap og tidsvinduer små. Men over‑automatisér, og man brænder relationel kapital af. Fejlagtige opgraderinger, uigennemsigtige prioriteringer eller en agent, der ikke forstår billetregler, bliver hurtigt dyrt – både økonomisk og omdømmemæssigt.
Hullerne i demoen, som produktion kræver udfyldt
Der er ingen produktionsklar adgangskontrol til write‑back. Ingen SLA’er for retrieval. Ingen multi‑tenant‑model, hvis flere arenaer eller brands deler platform. Ingen diskussion af offline‑tilstand, selvom store venues ofte har pletter med dårlig dækning. Complianceområdet – GDPR, dataminimering, retention – er ikke gennemgået.
Der mangler også kapacitetsplaner: Hvor bredt skalerer Atlas‑collections, når events multipliceres? Hvor længe tager index‑rebuilds? Hvordan opdateres embeddings, når dokumenter versioneres? Hvad med køer og backpressure, hvis flere parallelle beslutningsforløb skal skrive tilbage på samme tid?
Den praktiske betydning for arkitektur og drift
Memory‑modellen er arkitekturens anker. Hvilke hukommelsestyper findes? Som minimum: episodiske hændelser (hvad skete), semantiske sammenfatninger (hvad gælder for næste gang) og gæsteprofiler (hvem, præferencer, undtagelser). Hver type skal have klar retention og adgangsregler.
Hybrid retrieval kræver, at man designer både vektorindeks og klassiske tekstindeks med omtanke. Log feature‑brug pr. endpoint, ellers løber omkostningerne. Og write‑back skal behandles som en ændrings‑API med transaktioner – ikke som en løs “gem hukommelse”-funktion. Først dér bliver systemet forklarligt og testbart – og kedeligt på den gode måde.
Sådan kan et team gå fra demo til drift
Her er en kort, håndgribelig prioriteringsliste. Ikke alt på én gang – men i den rækkefølge gør det en forskel.
- Definér hukommelsestyper og retention: episodisk, semantisk, profil. Sæt slettepolitikker og dataminimering fra dag ét.
- Indfør write‑guards: RBAC, felt‑niveau tilladelser, menneskelig godkendelse for risikofyldte felter. Log alt.
- Byg audit trail: værktøjskald, kilde‑dokumenter, scoringsmetadata, beslutningsgraf. Gør det søgbart.
- Etabler CI/CD for agentlogik: fixtures for retrieval, deterministiske tests for graf‑forløb, regressionstests for prompts.
- Load‑test Atlas Vector Search: mål latenstid vs. top‑k, hybrid‑gain vs. omkostning, og find fallback‑grænser.
- Observérbarhed som standard: Langfuse eller tilsvarende, plus LangGraph‑checkpoints. Alarmer på latency og fejlrate.
- Plan for compliance: DPO‑review, formål, hjemmel, oplysningspligter, datarettigheder. Gør “export/delete” muligt.
Tradeoffs man ikke bør overse
Hybrid retrieval løfter ofte kvaliteten, men slider på latenstid og budget. Stram jeres recall‑mål, ellers betaler I dobbelt. Multimodale embeddings hjælper dokumenter med billeder og layouts, men kræver disciplin i versionering. Vision‑RAG er flot, indtil der ligger fire næsten‑ens PDF‑udgaver i hukommelsen.
Og write‑back: For hver ny memorytype stiger behovet for governance. Det er fristende at gemme “alt, hvad agenten lærer”. Det ender typisk som støj og juridisk risiko. Sparsomhed er en funktion, ikke en mangel.
Det større billede – hvorfor arkitekturen føles rigtig
At samle operationsdata og memory i Atlas giver kort vej mellem læs og skriv. LangGraph gør forløb eksplicit i stedet for at gemme logik i én lang prompt. Voyage‑embeddings er en fornuftig standard. Og valgfri tracing er bedre end ingen – om end “valgfri” i praksis nok bør blive “obligatorisk” før produktion.
Der er huller, ja. Men grebene, der er valgt, adresserer det, der skiller en demo fra drift: vedvarende hukommelse, sikker skrivning, audit og hybrid kontekst. Det er svært at kalde det et stunt, når arkitekturen lægger op til daglig drift med virkelige data – efter de manglende lag er bygget.
Hvad der stadig bør dokumenteres før nogen går live
Tre ting bør afklares med leverandør‑docs eller egne tests: 1) præcise autorisationsmønstre for write‑back i Atlas (felt‑niveau, transaktioner, konflikthåndtering), 2) realistiske performancekurver for vektor‑ og hybridspørgsmål under event‑load og 3) observérbarhedens dækningsgrad – hvor dybt går tracing, og kan man reproducere en fejlbeslutning entydigt?
Derudover: multi‑tenant‑adskillelse og data‑lokalisering for internationale events samt strategi for offline‑tilstand og netværksflimren. Ingen af delene er dækket i tutorialen, men de afgør succes i felten.
Konklusion
Tutorialen er ærlig om, hvad den er: en fiktiv builder‑demo, ikke en referenceimplementering med sikkerhedsgodkendelse. Alligevel rammer den det rigtige problemfelt og foreslår en arkitektur, der kan bære videre: Atlas som fælles operations‑ og memory‑lag, Voyage til semantik, LangGraph til styring, hybrid retrieval for præcision og write‑back for læring over tid.
Det, der overraskede mig, var, hvor jordnært det føles, når write‑back først er tænkt ind. Så holder man op med at tale om trylleri og begynder at tale om rettigheder, arbejdsgange og rollback. Ikke smukkere – bare mere rigtigt.
