Tre ord fylder i jobopslag og roadmap-møder lige nu: prompt, loop og graph. De bliver brugt i flæng. De er ikke det samme. Ifølge MarkTechPost (2650) er de tre stakkede “units of control” i et samlet paradigme, hvor hvert lag bygger oven på det forrige. Pointen er praktisk, ikke semantisk.
Denne artikel samler beskrivelserne fra MarkTechPost (2650), peger på det Buildrix-arXiv, som MarkTechPost opsummerer (juni 2026), og holder det op mod et AWS-eksempel på agentløsninger med flere datakilder (2652). Formålet: at give tekniske beslutningstagere klare kriterier for, hvornår man stopper ved prompt+context, hvornår man bygger harness og loop, og hvornår et graph-lag giver mening.
Hvorfor er det en nyhed nu
Tidslinjen er tydelig i MarkTechPost: prompt engineering var etableret; loop engineering dukkede op sent i 2025 og dominerede dev-debatten frem til juni 2026; graph engineering fulgte cirka seks uger senere (2650). Termerne ligner hinanden og ender i samme stillingsopslag. Det skaber forvirring om roller og arkitekturvalg.
Det centrale er, at de ikke konkurrerer. Ifølge MarkTechPost (2650) er det tre lag i samme stak. Hvert lag flytter, hvad der kontrolleres: en enkelt modelrespons, en agents adfærdscyklus, eller organiseringen af mange agenter. Den lagdeling har konsekvenser for design, drift og ansvar.
Tre lag på to minutter
Prompt engineering styrer én modelrespons. Ét kald, ét svar. Klart scope, hurtig iteration. Det fungerer, så længe et menneske evaluerer hvert output. Når volumen stiger, eller svar skal direkte videre til næste trin uden menneskelig gating, holder det ikke (2650).
Lagene bevarer hinanden
Lagene ophæver ikke de underliggende lag. En prompt forsvinder ikke, fordi den indlejres i en loop. Den får livscyklus, versionering og test (2650). Tilsvarende når et graph-lag orkestrerer flere loops – de består, med egne kontrakter.
MarkTechPost refererer også Anthropic’s råd om at segmentere systemprompter i mærkede afsnit – baggrund, instruktioner, værktøjsvejledning, outputformat – med XML-tags eller Markdown-overskrifter, og at levere det minimale, der fuldt specificerer forventet adfærd (2650). Minimal er ikke lig kort. Det er nøglen til at bevare styring, når lagene bliver flere.
Dyk i prompt og context
Prompt engineering er velbeskrevet. Det nye er context engineering. Ifølge MarkTechPost (med henvisning til Anthropic) flytter arbejdet sig fra at finpudse ord til at vælge, hvilke tokens overhovedet skal ind i kontekstvinduet, givet vinduets grænser (2650). Spørgsmålet er: hvilke bidder giver størst marginal nytte for den næste modelbeslutning.
Harness og loop i praksis
Harness engineering dækker miljøet, en enkelt agent kører i: filer, værktøjer, hukommelse og feedbackmekanismer (2650). Alt det omkring selve API-kaldet, der gør agenten i stand til at arbejde med projektets artefakter og korttidshukommelse.
Loop engineering ligger et trin over. Ifølge MarkTechPost og Buildrix-beskrivelsen i artiklen (2650) definerer loop-laget den gentagne observe-act-verify-recover-adfærd. Det bliver hurtigt drift: overvågning af loop-skridt, fejldetektion, rollback og afbrydelser ved policybrud. Teams bør have en plan for at teste loops deterministisk nok til at fange regressions, selvom svarene er probabilistiske.
Implementeringsspørgsmål ved loop
Hvad tester man konkret? Brug faste fixtures for input, syntetiske edge-cases, kontrakter for tools (MCP, API’er) og eksplicit verifikationslogik, der kan afvise og gentage. MarkTechPost peger på, at loop’et ikke kun er teknik, men også praksisdesign – hvornår må agenten selv prøve igen, hvornår skal et menneske gribe ind (2650).
Graph engineering og orkestrering
Graph-laget er det nyeste – og mest mudrede. MarkTechPost understreger, at proveniensen er uklar, og at ordet “graph” kolliderer med den klassiske knowledge-graph-betydning (2650). Her betyder det orkestrering: en styringsgraf, hvor noder er agenter\/loops, og kanter er overdragelser, afhængigheder eller beslutningsporte.
Praktisk betyder det konflikthåndtering og dataflow. Hvem ejer sandheden, hvis to agenter er uenige? Hvad må en specialiseret agent se af persondata, når den kun skal vurdere en teknisk log? Pointen hos MarkTechPost er, at grafen organiserer mange agenter; den opfinder ikke nye evner i dem (2650). Det er koordinering, ikke trylleri.
Arkitektur og data-infrastruktur
Fragmenteringen i roller afspejler arkitekturen. Ifølge briefet (2651) påvirker lagdelingen systemdesign, datalagre og governance. Et eksempel hos AWS viser, hvordan en operationsleder kobler IoT-telemetri, ERP-vedligehold og historiske driftslogs for at komme fra signal til årsag (2652). Én kilde rummer sjældent hele billedet.
Oversat til arkitektur: pålidelig ETL\/CDC ind i en kontekstpool, realtime-adgang for loops med lave latenstidskrav og batch for retrospektiv vurdering. For graph-lag kræves desuden et orkestreringslag, der kan eksekvere, logge og afbryde på tværs af mange agenter. AWS-eksemplet (2652) viser konsekvensen af siloer. Grafen kan koordinere – men den løser ikke dataintegration for dig.
Governance på tværs af lag
Hvad skal sikkerhed og datastyring spørge om? MarkTechPost’s ramme gør det muligt at lave en tjekliste per lag (2650). For prompts: versionering, ændringslog, ejerskab og segmentering efter Anthropic’s råd. For context: dokumentkilder, citat-politikker og max-token-regler pr. kilde.
For harness og loops: audit af værktøjsbrug, standardiserede retries, backoff-politikker og isolering af arbejdsmapper. For graphs: beslutningsporte, rollestruktur, dataadgang pr. agent og et samlet auditspor, der binder loop-logs sammen. Briefet (2651) peger i samme retning: Det handler om nye styringsmønstre, ikke bare nye titler.
Hvornår betaler højere lag sig
MarkTechPost beskriver indikatorer: høj volumen, multi-step flows, ingen tilgængelig menneskelig evaluator, eller behov for at output automatisk føder næste trin – så er prompt alene ikke nok (2650). Her bliver harness og loop relevante. Graph-laget giver først mening, når flere loops skal koordineres mod forskellige mål eller datasæt.
Der mangler kvantitative tærskler. Det er et hul i materialet. MarkTechPost gengiver Buildrix’ progression (2650), men uden tal for, hvornår effekten vender positiv. Et pragmatisk bud (udledt af 2650 og 2652): hvis et workflow kræver mere end 3–4 autonome skridt uden menneskelig kontrol, eller hvis datakilderne er tre eller flere med forskellige adgangsregler, er tiden moden til loop – måske også graph.
Tooling og terminologi
Markedet har værktøjer for hvert lag, men kilderne her giver ikke en fuld mapping. Typerne kan skitseres: prompt editors og prompt-versionering; context managers og retrieval-lag; harness\/agent-runtimes med værktøjsbroer; og orchestration-lag for grafer. MarkTechPost advarer implicit om terminologisk kollision mellem knowledge graphs og orchestration graphs (2650). Den skelnen bør produktteams gøre eksplicit i dokumentationen.
Konkrete skridt før investering
Start med proceskortlægning. Find flows, hvor output automatisk skal blive input til næste trin, og hvor menneskelig vurdering ikke kan følge med. Knyt krav til datatilgængelighed: hvilke kilder skal i kontekstvinduet, og med hvilken latenstid. MarkTechPost’s ramme (2650) gør klart, at lagvalget følger opgaven – ikke moden.
Kør et lille proof-of-value i 3–6 uger: byg først prompt+context, mål fejlrate og behov for menneskelig gating. Overskrides en intern tærskel, så prototyp loop\/harness med tydelig verifikation. Hvis beslutningslogik skal deles mellem flere agenter med forskellige kompetencer, så test en enkel orchestration graph. AWS-casen (2652) er en påmindelse om, at datavejen skal med fra dag ét.
Risici og huller i dokumentationen
Overfragmentering er en reel risiko. Flere lag giver flere grænseflader at vedligeholde. Vendor-lockin lurer i harness\/agent-runtimes. Terminologien er ikke afklaret – især på graph-niveau – og MarkTechPost noterer selv sammenstødet med knowledge-graph-brug (2650). Det kan skabe forvirring i teams og i arkitekturanmeldelser.
Buildrix-papiret omtales i MarkTechPost som et arXiv fra juni 2026 med progressionen prompt → context → harness → loop og loop som observe-act-verify-recover (2650). I de foreliggende kilder er det en sekundær reference; originalteksten er ikke gennemgået her. Det er et “reporting gap”, indtil originalen verificeres. Hovedrammen består – men forbeholdet bør med.
Hvad betyder det for næste kvartal
Det korte svar: afklar hvilket lag der faktisk skaber kontrol over jeres vigtigste flows. Hvis største smerte er uens svar på enkle forespørgsler, er prompt+context med god versionering ofte nok. Hvis smerten er ustabil autonom adfærd på tværs af skridt og værktøjer, er loop uomgængeligt. Hvis koordinering mellem specialiserede agenter er flaskehalsen, så kig på graph – men først når dataintegration og logging er på plads.
Forskellen mærkes først i drift – når noget fejler. Det er dér lagdelingen enten redder jer eller afslører hullerne.
Kilder og videre læsning
- MarkTechPost: “Prompt Engineering vs Loop Engineering vs Graph Engineering: What Changes at Each Layer” (2650)
- Buildrix arXiv-papir, juni 2026 – omtalt og opsummeret af MarkTechPost (sekundær reference i dette materiale) (2650)
- AWS Machine Learning Blog: “Generate Autonomous Business Insights with AI Agent and MCP Servers” – eksempel på agentarbejde med IoT, ERP og historian (2652)
- Analytiske noter om arkitektur og governance-mønstre relateret til lagdelingen (2651)
