Mange agent‑projekter brænder tid og penge af uden at nå stabil drift. En ny, praktisk guide på Towards AI (2501) skærer agent‑arkitekturen i tre lag — harness engineering, loop engineering og graph engineering — og insisterer på, at de bør designes og ejes separat. VentureBeats dækning fra VB Transform 2026 (2503) peger i samme retning: Zillows ingeniørledelse fremhæver behovet for et vedvarende kontekstlag på tværs af lange kunderejser, og at kontekst ofte er sværere end data. Det matcher, hvor enterprise‑systemer oftest knækker i virkeligheden.
De fleste har blandet lagene. Ikke af ond vilje, men fordi en prototype virker i en notebook, hvorefter der hældes flere værktøjer og et par retries på — og pludselig er grafen rodet, og driften skrøbelig. Ifølge Towards AI (2501, høj tillid) er det her kilden til de dyreste fejl.
Tre lag, tre ansvarsområder
Essensen er praktisk. Harness engineering gør modellen operationel: kontekst, værktøjer, tilladelser, persistens, kontrol, sikkerhed og observability. Loop engineering gør handlinger iterative og kontrollerbare: observe/act/verify‑cyklusser, tydelige triggere, evidensbaserede stopkriterier. Graph engineering gør komplekst kontrolflow gennemskueligt: eksplicit topologi med noder/kanter, branching, samtidighed, state transitions og recovery paths. Kilden (2501) definerer forskellene klart.
Huskeremsen fra 2501: harness får modellen til at køre, loops gør den ansvarlig og genoptagelig, graphs gør den inspicerbar og styrbar. Små ord, stor forskel i drift.
Harness engineering uden skyklapper
Harness‑laget bærer mere vægt end mange tror. Ifølge 2501 (høj tillid) omfatter det ikke bare “prompt og tools”, men også de kedelige — og vitale — dele: permissions, persistens, kontroller, sikkerhed, logging, målepunkter. Overbrede tilladelser ser elegante ud i en demo, men i drift kan modellen skrive forbi sit mandat, kalde for mange eksterne APIs eller røre PII uden korrekt sporbarhed. Dyrt — ofte først opdaget ved audit kl. 16 en fredag.
Et andet klassisk harness‑svigt er for meget værktøj i hænderne på modellen. 2501 advarer om det samme: mange tools virker hjælpsomme, men udvider fejlrummet og gør årsagsanalyse uklar. Når et kald fejler, skyldes det så tool‑konfiguration, tilladelser, latency eller modellen? Uden skarp afgrænsning i harness bliver svaret “måske”. Det kan drift ikke bruge.
Loop engineering der kan stå for en revision
Loop‑laget handler om rytme og bevis. 2501 beskriver observe/act/verify med eksplicitte triggere og evidensbaserede stopregler (høj tillid). Undgå ubegrænsede retries: “prøv igen” uden loft eller evidenskrav bliver en pengebasker. Tokenforbrug stiger, latency kryber, succesraten står stille.
Loop‑design har tekniske implikationer. Idempotens er ikke valgfri, når en handling kan forsøges igen — manuelt eller automatisk. Transaktioner, især hvor tool‑kald skriver til databaser eller systemer med sideeffekter, skal kunne rulles tilbage eller bekræftes deterministisk. 2501 peger på behovet, men leverer ikke metrikdefinitioner for fx evidensscore eller retry‑politikker. Det er et rapporteringshul.
Graph engineering for kontrol og indsigt
Graph‑laget lægger skinnerne. Ifølge 2501 (høj tillid) bør workflowtopologi modelleres eksplicit som noder og kanter, så næste trin, forgreninger, samtidighed, state transitions og recovery paths er styret — ikke overladt til modelens “mavefornemmelse”. Det begrænser fejlveje og gør inspektion mulig, når noget går galt.
Gode grafer har tydelige recovery‑stier. Et trin fejler — hvad så? Hop tilbage til forrige bevispunkt, kør en verificeret kompensationshandling, og fortsæt. Uden det ender man i blindgyder. Eller værre: implicitte loops, der ikke er synlige i observability, fordi de er gemt i prompts.
Hvordan lagene går i stykker, når de blandes
Fire fejl går igen i 2501 (høj tillid). Én: at tegne en stor, flot graf før der er forståelse for modeladfærd. Resultat: forkerte antagelser i kanter og for mange implicitte kontekstskift. To: at lade samme model self‑grade uden værn. Uden uafhængig verifikation bliver fejl stemplet “ok”, og kvalitetsdrift siver ind i produktion.
Tre: uendelige retry‑loops. Det ligner robusthed, men er bare dyr stædighed forklædt som fejltolerance. Fire: undermineret ansvar. Når harness tillader alt, loops prøver “lidt af hvert”, og grafen ikke håndhæver transitions, ender alt som “modelproblemer”. Ofte bor fejlen i det forkerte lag.
Vedvarende kontekst er ikke en luksus
VB Transform‑dækningen af Zillow (2503, høj tillid) er klar: et persistent context‑lag er nødvendigt, og kontekst — ikke rå data — er den svære del. Zillows kunderejser strækker sig over måneder med skift i flader, medarbejdere og kanaler. Samtalen skal hænge sammen. Et enkelt chatvindue rækker ikke.
Det peger på harness‑laget: persistens af kontekst, versionsstyring af sessionstilstand, entitets‑ og identitetsbinding og ejerskab af, hvem der må læse/skrive i tråden. VentureBeat noterer også, at Zillows produkter rører ved omtrent 80 procent af amerikanske bolighandler, og at virksomheden brugte AI før ChatGPT (2503, høj tillid). Pointen er praktisk: kollapser konteksten, falder oplevelsen — uanset model.
To uger til bedre drift
Hvad kan forbedres på to uger med lav risiko? Towards AI (2501) giver en tjekliste, der kan oversættes til konkrete skridt. Én: auditér permissions i harness. Fjern brede skriveadgange. Indfør mindstebehov og eksplicit tool‑mapping per use case. To: definér stopregler i loops. Brug evidensscore eller eksterne verifikatorer og sæt hårde lofter for retries. Det alene fjerner meget spild.
Tre: instrumentér graph‑state transitions. Log hvert hop — inkl. årsag (trigger) og tid. Fire: indfør verificerbare checkpoints i kritiske trin. Gem input, output og verifikationsresultat, så fejlsøgning ikke sker på fornemmelser. Zillow‑pointerne om persistent kontekst (2503) understøtter behovet for sådanne checkpoints over tid, også når dialogen flytter kanal.
Tradeoffs der skal vælges bevidst
Der er en pris for adskillelse. Udviklingshastighed vs. sikkerhed: hårdere harness‑kontroller og graf‑regler gør iteration langsommere i starten, men mindsker brandudrykninger i drift. Konservative permissions vs. funktionalitet: smallere tool‑adgange kan begrænse kapacitet i begyndelsen, men reducerer hændelser og forkorter MTTR.
Grafkompleksitet vs. fleksibilitet: en rig graf er kontrollerbar, men kræver disciplin i change management. En løs graf er hurtig at udvide, men skjuler gæld. Mål succes på tre ting: fald i ubegrundede retries pr. session, kortere tid til fejlårsag ved incidents og andelen af fejl, der kan tilskrives ét lag entydigt. 2501 understøtter rationalet, men leverer ikke faste metrikdefinitioner; her må teams selv sætte snittet.
Hvad der skal måles, og hvor
Hvert lag fortjener egne SLO’er. Harness: track ændringer i permissions over tid, tool‑invocations pr. session og andelen af kald, der rammer autorisationsfejl. Loops: retry‑tællinger, aktivering af stopregler, gennemsnitlig evidensscore for godkendte trin. Graphs: latenstid i state transitions, andel mislykkede recovery‑forsøg og procent flow, der forlader “happy path”.
VB Transform‑historien (2503) bekræfter vigtigheden af vedvarende kontekst på tværs af kanaler, så suppler med en kontekst‑kohærensmetrik: andel interaktioner hvor brugerens seneste intention og entiteter genkendes korrekt. Det er dér, oplevelsen først knækker.
Hvem skal eje hvad
Organisatorisk ejerskab bør spejle lagene. Platform/infra ejer harness: identity, secrets, tool‑registry, policy enforcement og observability. Runtime/applikation ejer loops: triggers, verifikation, stopregler og idempotens. Orkestrering/workflow ejer grafen: topologi, state‑maskiner, versionsstyring og change control.
Eskaleringsvejen skal være tydelig. For brede permissions? Harness‑ejer. Ubegrænset retry? Loop‑ejer. Dødt flow uden recovery? Graf‑ejer. Simpelt — men kun hvis rollerne er skrevet ned før lancering.
Governance der rammer rigtigt
Governance bør ikke kun fokusere på modelvalidering. 2501 advarer mod self‑grading uden værn (høj tillid). Læg derfor krav om uafhængig verificering ind i loop‑designet og revision af tool‑tilladelser ind i harness. Red teaming giver mest værdi, når hele kæden testes: må modellen noget, den ikke burde (harness), kan den køre sig selv i ring (loop), og kan den forlade en fejltilstand sikkert (graf)?
Auditlogning skal lægge “fingeraftryk” pr. lag: hvem tildelte hvilken tilladelse, hvilken stopregel bremsede en handling, hvilken node skiftede til hvilken state — og hvorfor. Uden lagdelte logs drukner hændelser i tekst og tokens.
Værktøjspipelinen skal passe til lagene
Match værktøjer og leverandører til lagene. Orchestrators og workflow‑motorer til grafen skal understøtte eksplicitte state machines, versionsstyring og transaktionelle recovery‑stier. Loop‑laget har brug for policy engines, verifikatorer og idempotente connectorer. Harness kræver et persistent context store, stærk policy enforcement og fuld observability ned på tool‑kald.
Kræv af leverandører: kontekstpersistens med TTL og versionsspor i harness; første‑klasses støtte til idempotens og stopregler i loops; transaktionel konsistens og målbar state‑latenstid i grafen. 2501 giver principperne, 2503 motiverer kontekstens nødvendighed. Koblingen til konkrete produkter er kundens opgave — helst før kontrakten underskrives.
Hvor kilderne er enige, og hvor der mangler data
Der er solid enighed mellem 2501 og 2503 om behovet for struktur og vedvarende kontekst. 2501 formaliserer lagene og peger på fejlscenarierne (høj tillid). 2503 bekræfter enterprise‑problemet i praksis: kontekstlag på tværs af lange rejser er hårdt og ikke kun et dataproblem (høj tillid). Hvad mangler? Metrikker og tal for effekten af adskillelsen i produktion. Hvor meget falder fejlratens hale, når permissions strammes? Hvor meget hurtigere bliver årsagsanalyse med lagdelte logs?
Dermed et arbejdsområde til teams: definér lokale SLO’er pr. lag, test dem i en pilot, og mål forskellen. Kilderne peger retningen; metrikrammen skal færdiggøres lokalt. Fair nok — det svære er sjældent tegningen, men de første to uger i sand drift.
Bundlinjen nu
Hvis agent‑arkitekturen skal holde, så opdel ansvar og byg sikkerhed ind i hvert lag. Harness styrer kontekst, værktøjer og tilladelser — uden blændværk. Loops styrer rytmen med bevis og klare stop. Grafer styrer ruten, også når toget skal bakke. Zillow‑citatet fra VB Transform (2503) føjer vægt: uden vedvarende kontekst går tråden tabt, og værdien forsvinder i hop mellem kanaler.
Meget er ikke dækket her: dybe kodeeksempler til evidensscoring, fulde metrikrammer og en offentlig case med før/efter‑tal. Pointen er at komme i gang med to skridt: auditér permissions og håndhæv stopregler. Forskellen mærkes først, når man har det i hænderne.
