Fejl i agent‑løsninger bliver ofte opdaget for sent. Vi har siddet i mødelokaler, hvor en supportbot gentog samme misforståelse i dagevis. VentureBeat beskriver det samme: Mønstre opdages først, når skaden er sket. LangChains svar er LangSmith Engine i public beta, som forsøger at lukke hele debugging‑løkken automatisk — fra fejlopdagelse til forslag til fix — med menneskelig godkendelse som sidste trin.
LangSmith Engine overvåger produktionstraces for flere slags signaler, klynger dem til sager, matcher mod den levende kodebase, udarbejder en pull request og foreslår en evaluator, der kan fange problemet næste gang. Godkendelsen ligger stadig hos jer. Kilderne, både LangChains blog og VentureBeat, fremhæver den automatiserede kæde med human‑in‑loop til sidst. Vores læsning, sammenholdt med kundearbejde: Der er tid at hente, men det kræver justeret arkitektur, rettigheder og governance.
Hvad Engine gør i praksis
Engine kigger efter eksplicitte fejl, online evaluator‑fails, afvigelser i traces, negativ brugerfeedback og usædvanlig adfærd — fx når brugere spørger om noget agenten ikke er designet til. De signaler samles og prioriteres som navngivne issues. I blogeksemplet opstår en sag om forkerte svar ved opsigelse af abonnement med alvorlighed, tidslinje og links til konkrete beviser. Det gør triage mere håndterlig end en rå logstrøm.
Når en sag er prioriteret, læser Engine mod kodebasen, lokaliserer årsagen, danner en PR med foreslået ændring og skitserer en custom evaluator, så regressioner kan fanges. Det bygger på LangSmiths eksisterende tracing- og eval‑infrastruktur og kan spille sammen med jeres egne evaluator‑resultater. Det er en stram kæde af kendte MLOps‑trin samlet i én arbejdsgang.
Hvordan det adskiller sig fra observability
De fleste værktøjer giver målinger, dashboards og sporbarhed — W&B, Arize, Phoenix, Honeyhive m.fl. VentureBeat fremhæver, at Engine går hele vejen fra detect til diagnose til et konkret fix‑forslag. Ikke kun observability, men en automatiseret bevægelse fremad i workflowet.
Praktisk betyder det, at I i stedet for at samle fejl manuelt, åbne tickets, tilkalde udviklere og bagefter opfinde en evaluator, får ét samlet forslag i kø. Mennesket forsvinder ikke, men limarbejdet mindskes, og tiden fra opdagelse til ændring kan skrumpe.
Hvorfor problemet er reelt
VentureBeat peger på, at enterprise‑teams ofte opdager agentfejl for sent. Det genkender vi. Hos en nordisk detailkunde forvred en lille promptændring returpolitik‑svar i næsten to uger, fordi evaluator‑dækning manglede, og loggen var støjende. Ingen systemalarm, for svartiden var fin, og API‑fejl var nul. Kun utilfredse beskeder i fritekst, som ingen læste konsekvent. Det kostede tid i kundeservice og skabte gnidninger med compliance.
I en større bank gik en intern agent i ring, når et værktøj svarede med tomt payload. Intet crashede, så SRE holdt sig i ro. Fejlen blev opdaget tilfældigt en fredag kl. 16.30. Pointen: Fejlmønstre sniger sig ofte ind uden klassiske driftsalarmer. Systematisk clustering og målrettede evaluators kan gøre en forskel.
Hvad det kræver at få værdi
Engine kræver tracing på tværs af kæden. Hvert hop skal kunne følges: prompt, kontekst, værktøjskald og eksterne API‑svar. Ellers ser motoren kun halve spor. Det betyder instrumentering i jeres agent‑framework og klare valg om, hvad der logges, sløres og sendes ud af huset.
Dernæst kræves læseadgang til kodebasen for at diagnosticere og klargøre PR‑forslag. For nogle teams er det nyt, at et observability‑system ser direkte ind i repoet. CI\/CD skal også være modent, så automatiske PRs rammer tests, kvalitetstjek og sikkerhedsscans. Ellers bliver PR‑støjen større end hjælpen.
Workflowet ændrer sig
Når et værktøj foreslår fixes, påvirker det udviklerkulturen. Hvem ejer PR’en, hvilke kodeejere kan godkende, og hvornår må noget merges automatisk? Vi har set simple regler virke: PRs fra Engine merges først, når mindst én uafhængig reviewer har godkendt, og smoke‑tests samt eval‑suite er grønne. I monorepoer kan det kræve justerede CODEOWNERS‑mønstre og flere beskyttede branches.
Foreslåede evaluatorer skal ind i jeres testkatalog. Det påvirker change control, fordi både kode og eval‑regler ændres. En evaluator kan have større forretningsmæssig effekt end en enkelt promptlinje, fordi den bliver en permanent vagtpost. Governance skal følge med — ikke løse Notion‑noter, der ikke vedligeholdes.
Begrænsninger og faldgruber
Der er en reel lock‑in‑risiko. Ligger tracing, evaluators og PR‑forslag i samme økosystem, bliver flytning vanskelig. VentureBeat noterer, at store modeludbydere ruller observability ud i egne platforme. Praktisk på dag ét, men kører I GPT i ét flow og Claude i et andet, ender I let med to sandheder og ingen tværgående revision.
Falske positive og negative vil forekomme. Clustering kan overse sjældne, men dyre hændelser. Root‑cause mod kode bryder sammen, hvis fejlen sidder upstream: datakvalitet, tredjeparts‑API, eller et midlertidigt feature flag. Og i store monorepoer gør sideeffekter automatiske PRs mere skrøbelige.
Konkurrencebilledet strammer
Anthropic, OpenAI og Google lægger evaluators og observability ind i deres platforme, ifølge VentureBeat. Det øger presset på tredjepartsværktøjer, men mindsker ikke behovet for et neutralt lag. Når hver leverandør måler sig selv, bliver krydssammenligning svær. Flere compliance‑folk efterspørger ét samlet revisionsspor.
Baggrunden er velkendt fra MLOps. Automatisering accelererer i træning og drift, og jo mere løkken automatiseres, desto vigtigere er opsyn, klart ejerskab og tests, der måler reel forretningskvalitet — ikke kun latens og pris per 1K tokens.
Hvorfor et neutralt lag stadig er nødvendigt
Multi‑model er allerede normalen i enterprise. Et konsolideret observability‑ og eval‑lag er uundværligt for at rute, sammenligne og skifte uden friktion. Brug LangSmith Engine til hurtig triage og forslag, men fasthold et uafhængigt lag, der indsamler nøgletal, eval‑scores og auditlogs på tværs.
I praksis placerer vi LangSmith tæt på agent‑udførelsen, mens et neutralt lager — fx timeserier og et datalake‑spor — fungerer som governance‑sandhed. Evaluatorer registreres i et fælles katalog med ID’er, versioner og ejere. Routing‑logik måles med samme metrikker uanset modeludbyder, så beslutninger kan forklares i revisionssporet senere.
Sådan ville vi rulle det ud
Trin 1, instrumentation: fuld tracing af prompts, kontekst og værktøjskald med dataminimering, hvor indhold er følsomt. Trin 2, evaluator‑kortlægning: hvilke kvalitetsmål dækkes, og hvor er hullerne. Trin 3, sikker adgang: read‑only repo‑adgang til Engine via servicekonto, afgrænset til relevante mapper, og CODEOWNERS på plads.
Trin 4, CI\/CD: PRs rammer en pipeline med statisk analyse, tests og eval‑suites samt automatisk rollback ved røde signaler. Trin 5, governance: definer human‑in‑loop, review af nye evaluators og dokumentation af ændringer. Først derefter skaleres til mere følsomme flows.
Hurtig og sikker adoption
Vores korte tjekliste til en pilot: instrumentation på agent‑tier, evaluator‑map med ejere, læseadgang til kode, PR‑reviewpolitik og rollback‑playbook. Uden modent CI\/CD bliver automatiske PRs til støj, ikke hjælp.
Start i lav‑risiko domæner som en supportbot eller et internt automationsflow. Planlæg 90 dage med milepæle hver tredje uge: uge 3 tracing og første eval‑suite; uge 6 Engine kører og laver de første PRs; uge 9 fælles metrikker ind i et neutralt lager; uge 12 review af effekt — inkl. tid‑til‑opdagelse og tid‑til‑merge.
Tre mini‑cases fra virkeligheden
Supportbotten: En detailkunde så 12 procent af samtaler handle om annullering af abonnement uden tilfredsstillende svar. Med Engine forventer vi en sag på det mønster, en PR der opdaterer værktøjsvalg og promptsektion, og en evaluator der tester tre varianter af annulleringsspørgsmål. Det neutrale lag får samtidig en KPI: andel korrekte policy‑svar.
Internt automationsflow: Et sagsbehandlingsværktøj brugte både GPT og Claude. Når Claude‑svaret manglede et felt, gik agenten i stå uden at fejle. Engine kan klynge afvigende traces og foreslå en defensiv parser. Vores safeguard er en platformneutral eval, som måler udfyldte felter uanset model.
Compliance‑følsom beslutning
I en banklignende kontekst genererede en agent udkast til kundebreve med følsomme formuleringer. Her bruger vi Engine til at foreslå fixes, når en formulering misforstås, men lader aldrig PRs merges automatisk. Evaluatorer godkendes i change advisory board, og logs kopieres til et neutralt revisionsspor. Det er tungere, men nødvendigt.
Små detaljer, men de betyder noget i dagligdagen. Vi har stadig billedet af en post‑it på en skærm i Ringsted: “hvorfor svarede botten sådan i tirsdags”. Et godt værktøj kan fjerne mange af de post‑its.
Modargumenter og åbne spørgsmål
Skeptikere spørger, om en motor, der skriver PRs, ikke bare skaber flere ændringer end nødvendigt. Der er ingen offentlige tal på, hvor ofte PR‑forslag rammer rigtigt, eller hvor meget tid der spares i medianen. Vi vil gerne se accept‑rate, ændringsstørrelse og regression‑rate efter merge. Det bør LangChain svare på — og gerne en enterprise‑kunde i drift.
Et andet punkt er sikkerhed: Hvad betyder read‑adgang til kode for et tredjepartsværktøj i miljøer med stram compliance? Her mangler tekniske detaljer om, hvordan Engine læser, scanner og begrænser scope. Et arkitekturdiagram eller whitepaper om dataopbevaring og isolation ville hjælpe.
Konklusion uden sløjfe
LangSmith Engine er et tydeligt skub mod kortere fejlløkker og færre gentagelser i produktion. Det er mere en ny arbejdsform end et nyt dashboard. Multi‑model virksomheder bør dog planlægge et neutralt observability‑ og eval‑lag fra dag ét, ellers forsvinder overblikket, og lock‑in sniger sig ind.
Start småt, mål det der betyder noget, og sæt klare human‑in‑loop‑regler. Forskellen viser sig først, når man arbejder med det i praksis.
