Markedsovervågning: LangGraph og Strands

Markedsovervågning er i sin natur en langvarig, statefuld opgave. Agenten skal indsamle data fra flere kilder, vurdere relevans, korrelere signaler og eskalere, når noget kræver opmærksomhed, alt sammen over timer eller dage, ikke sekunder. Det stiller et krav, som jeg ser mange agentsystemer overse: hvad sker der, når processen fejler halvvejs igennem et langt kørselsforløb?

I dette mønster løses det ved at adskille to lag klart fra hinanden. LangGraph styrer selve flowet, tilstandsmaskinen der afgør, hvilket trin agenten er i, og hvad der skal ske næste gang. Strands Agents håndterer selve ræsonneringen, altså den del, der fortolker data og træffer beslutninger om, hvornår et signal er vigtigt nok til at handle på. AgentCore binder det sammen som driftsplatform med hukommelse, observability og skalering indbygget, i stedet for at man selv skal bygge det infrastrukturlag.

Det er fristende at tænke på orkestrering og ræsonnering som samme opgave, men de er ikke det. LangGraph er godt til at modellere flowet som en graf: hvilke trin følger efter hvilke, hvor er der forgreninger, og hvornår skal processen vente på nyt input. Det er strukturarbejde. Strands Agents er derimod bygget til selve tænkedelen, hvor en model skal veje flere datapunkter op mod hinanden og formulere en vurdering eller et svar.

Ved at holde de to lag adskilt kan man opdatere ræsonneringslogikken uden at røre ved flowet, og omvendt. Det gør systemet nemmere at fejlsøge, fordi et problem enten er et flowproblem (agenten gik det forkerte sted hen) eller et ræsonneringsproblem (agenten traf en dårlig beslutning et bestemt sted). Det er den samme adskillelse, jeg har bygget ind i den agentflåde, jeg selv driver hos Agent Enterprise: et flowproblem og et ræsonneringsproblem kræver hver sin fejlsøgning, og blander man dem, ender man med at gætte i stedet for at rette.

Det mest driftskritiske element i denne arkitektur er checkpoint-baseret recovery. LangGraph gemmer løbende tilstanden undervejs i et kørselsforløb, så hvis processen afbrydes, en infrastrukturfejl, en timeout, en netværksafbrydelse, kan agenten genoptages fra det seneste checkpoint i stedet for at starte forfra.

For en markedsovervågningsagent, der potentielt kører i timevis og har akkumuleret kontekst fra flere datakilder undervejs, er det forskellen på et system, man kan stole på i produktion, og en skrøbelig demo, der ser flot ud på en scene, men falder sammen ved det første netværkshik. Jeg ser det samme i min egen drift af Agent Enterprises agenter: genoptagelighed er det, der afgør, om et agentsystem kan gå fra prototype til noget, driftsafdelingen tør stole på klokken tre om natten, ikke fordi det aldrig fejler, men fordi et checkpoint betyder, at et nedbrud koster minutter og ikke hele kørslen.

AgentCore leverer to ting, som ellers typisk skal bygges selv: struktureret hukommelse og observability. Hukommelsen gør det muligt for agenten at holde styr på, hvad den allerede har set og vurderet, så den ikke gentager arbejde eller mister kontekst mellem kørsler. Observability betyder, at man som driftsansvarlig kan se præcis, hvilke trin agenten gennemløb, hvilke beslutninger den traf, og hvor i flowet en eventuel fejl opstod.

Det er værd at bemærke, at AgentCore leverer det her som administreret cloud-infrastruktur hos AWS. Det er en gyldig vej, men ikke den eneste. Hos AI Enterprise Konsulenten kører jeg selv agentsystemer på lokal, GDPR-sikker infrastruktur, fordi jeg vil have kontrol over, hvor data om markedssignaler og kunder ligger, ikke kun over selve agentlogikken. Hukommelse og observability er lige så nødvendige, uanset om de kører i en administreret tjeneste eller på en boks, jeg selv kontrollerer, men spørgsmålet om, hvor dataene bor, forsvinder ikke, fordi platformen klarer resten for dig.

Det sidste punkt, indsigten i beslutningsstien, er ofte det, jeg selv går efter først. Uden indsigt i beslutningsstien er en agent en sort boks, og jeg sætter aldrig en sort boks til at overvåge markedsdata uden opsyn, uanset hvor godt den ser ud til at ræsonnere.

Det, der gør dette mønster interessant, er ikke selve idéen om en markedsovervågningsagent, den findes i mange varianter allerede. Det interessante er, hvordan arkitekturen adskiller ansvar tydeligt: flow i LangGraph, ræsonnering i Strands, drift i AgentCore. Den adskillelse er det, der gør systemet vedligeholdbart, når kravene ændrer sig, og det er den samme adskillelse, der gør checkpoint-recovery muligt i første omgang.

Om det skal være netop den stack, er mindre interessant end selve designprincippet. For virksomheder, der overvejer at bygge lignende statefulde agentsystemer, egnet til overvågning, compliance eller andre kontinuerlige processer, er pointen ikke at kopiere denne konkrete opsætning. Pointen er at anerkende, at en agent, der skal køre længe og pålideligt, kræver et andet designfundament end en agent, der besvarer ét spørgsmål og lukker ned igen, og at spørgsmålet om, hvor data bor og hvem der har adgang, hører hjemme i det fundament fra starten, ikke som en eftertanke.