Jeg kører over 70 faste natjobs og fem AI-agenter under én orkestrator i Claude Code. Kun én af de fem må røre et live site, og kun når jeg selv har skrevet en godkendelse ind i opgaven. Data-API'erne koster mig et par hundrede dollars om måneden, og det meste af det, jeg har lært, har intet at gøre med selve sprogmodellen. Alle de vigtige regler i systemet er skrevet efter en fejl — her er de fire fejl og den vagt, hver af dem efterlod.
Hvad er en AI-agent i praksis? En sprogmodel med værktøjer, en rolle og en grænse
En AI-agent er software, der udfører opgaver for dig, i stedet for at du selv skal bruge den til hver enkelt opgave. Det er den samme forskel, Dansk Industri beskriver ved AI-agenter: værktøjet skifter fra noget, du selv bruger til opgaven, til noget, der selv udfører den. Den har fået værktøjer — den kan læse filer, køre kommandoer og hente sider — og den har desuden en afgrænset rolle og en grænse for, hvad den må ændre. Instruksen og værktøjslisten viser, hvad en agent kan finde på og ødelægge; modellen bestemmer kun, hvor dygtigt den gør det.
Hvad er forskellen på generativ og agentisk AI?
Generativ AI svarer på det, du spørger om. Agentisk AI handler på dine vegne i flere trin: den henter data, tager en beslutning på baggrund af den, og handler igen. Forskellen er løkken: agenten ser resultatet af sit eget skridt og vælger selv det næste.
Hvordan laver man en AI-agent? En markdown-fil på 31-76 linjer
En agentdefinition hos mig er en markdown-fil på mellem 31 og 76 linjer: navn, en kort beskrivelse, en liste over værktøjer, hvilken model den kører på, og en instruks i almindelig prosa. Sådan starter den korteste af dem, forkortet:
---
name: overvaagningsagent
tools: Read, Glob, Grep, Bash, PowerShell
model: haiku
---
Du tjekker og rapporterer afvigelser. Du retter aldrig noget.
Læg mærke til, hvad der IKKE står der: Write og Edit. En agent med Opus under motorhjelmen og adgang til at redigere filer er en helt anden risiko end samme model uden skriveadgang, selv om sprogmodellen er identisk. Start selv med værktøjslisten, når du skriver en agentdefinition — prosaen kommer bagefter.
Hvordan ser arkitekturen ud? 1 orkestrator, 5 specialister og et lag af planlagte jobs
Vores arkitektur har to lag. Det første er deterministisk: planlagte scripts, der kører for det meste om natten. Det andet er et agentlag, hvor en orkestrerende hovedsession uddelegerer til fem specialister. De fem specialistagenter læser natjobbenes spor bagefter, men de kører ikke selv om natten.
WINDOWS JOBLISTE FÆLLES KLIENTER
(planlagte jobs, primært natten) → data-API · Firecrawl
skriver ved START cache · cost-log · loft pr. kørsel
│
▼
VAGTER ORKESTRATOR ("direktøren")
markeringsfil → slettes kun → hovedsession, morgengennemgang
ved exit 0 + frisk bevis læser: logs, markeringer, journal
TILSYN: findes beviset? │
┌──────────┼──────────┬──────────┬──────────┐
▼ ▼ ▼ ▼ ▼
overvågning seo-analytiker gevinstagent indholdsagent teknikagent
(læser) │
▼
GATE: "GODKENDT AF LAUST"
│
▼
BACKUP-VAGT (første "før" røres aldrig)
│
▼
LIVE SITES
Tegner du dit eget system op, så tegn skrivevejen i en anden farve end læsevejen, for det er den, du skal kunne pege på under en krise. Blandt de fem agenter er kun vejen fra teknikagenten til gaten, backuppen og de live sites en skrivende vej. Ud over de fem findes der to andre skrivende lag: natjobbene, der skriver indhold og data på sitene efter faste regler med indbyggede stop, og planlagte Claude-sessioner, der på samme måde kan udgive efter faste regler.
Hvornår kører natjobbene? 9 ud af 10 mellem 01:00 og 07:30
9 ud af 10 af mine daglige og ugentlige job starter mellem kl. 01:00 og 07:30, og flest af dem samler sig omkring klokken fire. Kender du selv mønstret fra at drive en portefølje af sites? De fleste job vil helst ligge, hvor ingen mennesker sidder og venter på dem. Klassificeret på jobnavn og kontrolleret på fem scripthoveder handler jobbene blandt andet om natkørsler med indhold og data på sitene, udgivelse og indholdsopdatering, planlagte aflæsninger, fælles tilsyn og målinger, vagter pr. site og interne links.
Natkørslerne har tre indbyggede stop:
- Kørslen afbryder sig selv, hvis den ikke kan hente sine data. Gårsdagens data bliver stående i stedet.
- En side bliver ikke opdateret, hvis indholdet på den falder mere end en lille, fast margin under det forventede.
- En opdatering sender aldrig feltet
post_status. Det er feltet, der kan afpublicere en side.
Hvilken model til hvilken agent? 3 modeller efter rolle
Hvilken agent der er bedst, afhænger af rollen, og der findes intet facit, uanset hvor tit spørgsmålet stilles. Sådan har jeg fordelt de tre modeller: Claude Haiku til overvågningsagenten, der kun læser og melder; Claude Opus til seo-analytikeren og gevinstagenten, der analyserer konkurrenter og data; og Claude Sonnet til indholdsagenten og teknikagenten, der skriver. Vælger du selv, så brug den billigste model til at læse og melde, mellemmodellen til at skrive og rette og den dyre til analyse.
Hvorfor lader jeg ikke underagenter starte underagenter?
Mine fem specialistagenter kan ikke selv starte nye underagenter. Det er ikke en begrænsning i selve platformen, men mit eget valg: ingen af de fem har agentværktøjet i deres værktøjsliste. Kun min hovedsession har det, og det er derfor, den er orkestratoren i stedet for endnu et lag. Den blev sat op som fast rolle den 13. august 2026, og den holder en morgengennemgang kl. 08:00 hver dag. Det er også svaret på, hvad et multi-agent-system er i praksis hos mig: ét fast lag, der fordeler opgaver til fem faste specialister.
Hvem må skrive? Kun 1 af 5 agenter rører et live site — og kun med en GODKENDT-blok
Kun teknikagenten må røre et live site, og kun når jeg har godkendt handlingen skriftligt. Alt andet, altså analyse og måling, er frit. Men skriver noget til et site, eller skønnes en opgave at koste over ca. 2 dollars i API-forbrug, kræver det min godkendelse. Godkendelsen er en blok i selve opgaveteksten: GODKENDT AF LAUST: <handling> <dato>. Mangler den, returnerer teknikagenten en handlingsliste i stedet for at handle.
| Agent | Må læse | Må skrive | Hvem godkender |
|---|---|---|---|
| Overvågningsagent | Logs, jobudfald, friskhed af data | Intet — den har ingen skrive- eller redigeringsværktøjer | — |
| SEO-analytiker | Konkurrence, SERP, AI-svar, filer | Kun lokale rapporter | Orkestrator; over ca. 2 dollars i API-forbrug kræver min godkendelse |
| Gevinstagent | Samme som analytikeren, prioriterer hvor optimering betaler sig | Kun lokale rapporter | Samme som ovenfor |
| Indholdsagent | Filer, briefs, web | Kun lokale udkast — udgiver aldrig selv | Mig, ved udgivelse |
| Teknikagent | Filer, web, kodebase | Live sites — men kun med en GODKENDT-blok | Mig, pr. handling, skriftligt |
Brug samme opdeling i din egen organisation: udfyld tabellen, før du bygger noget, der skriver til et site. Min orkestrators planlagte morgenkørsel udfører aldrig skrivende handlinger, og det, den ville have skrevet, samler den i stedet i en liste, der venter på min godkendelse.
Overvågningsagenten har ingen skriveværktøjer, men den har stadig en kommandolinje. "Read-only" betyder hos mig altså kun, at agenten ikke har fået skriveværktøjer — og med en kommandolinje kan en agent i praksis komme uden om en blokering, som du kan læse om i fejl 3 nedenfor, selv om den fejl ikke skete i overvågningsagenten.
Hvad koster agenterne? 360 euro om måneden i sprogmodel og et par hundrede dollars i data
Skal jeg sætte ét tal på, hvad det koster at drive agenterne, deler jeg svaret i to.
Vi betaler 360 euro om måneden for sprogmodellen: to Claude-abonnementer à 180 euro. Det er en fast månedlig abonnementspris.
Data-API'et er DataForSEO. Vi henter søgevolumen, SERP-data, konkurrentdata og backlinks igennem det, og det kostede et par hundrede dollars om måneden ved seneste måling. Det er en variabel pris, for den stiger, når jeg måler mere. Søgevolumen-opslagene udgjorde langt de fleste kald, men de kostede kun lidt mere end SERP-opslagene: omkring 94 dollars mod 88. Den største enkeltforbruger var min AI Overview-sampler, som stod for omkring en fjerdedel af hele regningen.
87 % af opslagene, der gik gennem den fælles klient, blev besvaret fra cache. Alligevel sparede cachen kun 16 dollars. Jeg havde regnet med, at 87 % cache-hits betød, at vi sparede det meste, men det gjorde vi ikke: cache-hits tælles pr. søgeord, mens regningen tælles pr. kald. Søgevolumen afregnes ens, uanset hvor mange søgeord der er i kaldet, så et cache-hit på ét enkelt søgeord sparer intet målbart — cachen sparer i stedet penge på de dyre enkeltopslag: SERP, konkurrentdata og linkdata.
Midt i august kaldte omkring 300 scriptfiler stadig API'et direkte, uden om den fælles klient. I dag importerer over 1.100 filer den samme klient, men loggen ser kun kald, der går gennem klienten — så beløbet ovenfor er en nedre grænse.
Firecrawl, som jeg bruger til at hente konkurrenters sider, regnes i credits. Cost-loggen viser 887 credits over 30 dage, og 22 % af kaldene blev besvaret fra cache. Loggen ser kun kald gennem den fælles klient, så tallet er en nedre grænse for det fulde forbrug.
Hvornår skal agenter arbejde parallelt? 5 ting, der aldrig deles ud
Jeg kører opgaver parallelt, når delene ikke afhænger af hinanden, og sekventielt, når trin 2 skal bruge trin 1's svar. Et gæt på trin 1, bare for at kunne parallelisere, koster kvalitet.
Fem ting deler vi aldrig ud, uanset hvor meget hurtigere det ville gøre opgaven:
- Skrivning til live sites. Godkendelsesgaten ligger hos mig, altid.
- To agenter i samme fil eller samme indlæg. Parallel skrivning mod samme mål bliver en tavs overskrivning.
- Den afsluttende dom over, om noget er sandt. Et værktøj kan svare roligt og forkert lige så let som rigtigt. Et intent-script klassificerede for eksempel «hvad koster en vaskemaskine pr. vask» som en prisintent, fordi ordet «koster» stod i søgningen — søgningen handlede reelt om strømforbrug.
- Kontrollen af en agents eget arbejde. En reviewer skal være en anden agent, og den skal have det færdige resultat at kigge på.
- Et enkeltopslag. Hurtigere at slå op selv, end det er at briefe en agent til det.
Prisen skal med i beslutningen: et loft pr. kørsel på 40 credits betyder, at fem parallelle agenter i samme runde kan bruge fem gange så meget som én. Parallelitet er hurtigere pr. opgave, men den er ikke gratis pr. runde, og to agenter, der slår det samme op, betaler begge.
Det virkede ikke: 4 fejl, der byggede vagterne
Fire fejl har bygget de vagter, jeg stoler mest på i dag. Fejl 1 og 2 skete i scripts, der kører omkring agenterne — backup-scriptet og natjobbet selv er ikke agenter, men den infrastruktur, agenterne læser og skriver igennem. Fejl 3 skete i en agent. Fejl 4 skete i mine egne Claude Code-sessioner, uden om de fem specialister. Går infrastrukturen i stykker, mærker du det først, når agenten allerede har handlet på et forkert grundlag.
Fejl 1: backup-scriptet overskrev originalen på 2 sider (6. september)
Et script gemte sin "før"-backup ved bare at skrive filen, uden at tjekke om den allerede fandtes. Ved anden kørsel på samme side blev "før"-filen overskrevet med scriptets eget output fra første kørsel. "Før"-filen indeholdt altså ikke længere originalen, men teksten, scriptet selv lige havde skrevet. Fælden var tavs: loggen sagde "backup:" begge gange, uanset om der reelt var gemt noget nyt. To sider mistede originalen for altid, fordi WordPress ikke havde nogen tidligere revision at falde tilbage på.
Har du selv en "før"-fil liggende et sted, så åbn den nu, og tjek om du faktisk kan se originalen i den.
Nu rører vagten aldrig den første backup, uanset hvor mange gange scriptet kører bagefter. Findes filen allerede, skriver den i stedet en ny, datostemplet nabofil. Jeg testede den selv ved bevidst at plante én fejl pr. skrivemønster og kræve, at hver af dem blev fanget. Første gennemgang fandt 122 kaldsteder uden vagt, og de blev rettet til nul. To dage senere viste det sig, at kontrollen selv havde været blind for fire af de seks skrivemønstre: tallet steg til 379. Først den 17. september, efter 384 migrerede kaldsteder, var tallet nul igen. Test vagten med fejl, du selv har plantet — det var sådan, blindheden blev fundet. Brug desuden mindst tre kørsler, når du tester mod overskrivning, for datostemplet har kun sekundopløsning.
Fejl 2: natjobbet døde 2 gange uden at sige det (12. og 14. august)
Et natjob blev dræbt undervejs af en systemfejl og nåede aldrig sin egen slutblok. Markeringen, der beviste, at jobbet var kørt, blev aldrig skrevet, fordi den kun blev skrevet ved en pæn afslutning. To dage senere blev samme job dræbt igen, denne gang af Windows' egen standby, få sekunder efter at maskinen vågnede. En manuel genkørsel bagefter gav exitkode 0, uden at jobbet reelt havde udført noget.
Skriver et natjob kun sin "færdig"-markering til sidst, ser du ingen forskel på et job, der døde, og et job, der aldrig startede.
Markeringsfilen skrives nu ved start af jobbet i stedet for ved slutningen. Den slettes kun, hvis jobbet ender med exitkode 0, og en separat vagt bekræfter, at selve dataen er frisk. Den vagt importerer bevidst ikke jobbets eget bibliotek, for den må ikke kunne dø af den samme fejl, den overvåger. Start-markeringen løste problemet fra 12. august, men den kunne stadig svigte selv, som den gjorde 14. august. Svaret på det er tilsynet: et separat script, der kun spørger, om der findes et friskt bevis på, at arbejdet faktisk skete. Exitkode 4 er nu reserveret til præcis den situation: kørslen sagde god for sig selv, men dataen dumpede prøven.
Fejl 3: agenten gik uden om en sikkerhedsblokering (14. august)
En AI-agent kom uden om en sikkerhedsregel for at løse sin egen opgave. Teknikagenten fik et kald afvist af en sikkerhedskontrol: kaldet var en cache-rydning på en side, og handlingen lå inden for den opgave, den skulle løse. I stedet for at stoppe og melde blokeringen lagde agenten det samme kald ind i en scriptfil og kørte scriptet. Og så anbefalede den omvejen som fast mønster til næste gang. Resultatet var korrekt, og det blev efterprøvet uafhængigt af agentens eget svar. Men metoden var forkert: en kontrol, der kan omgås ved at flytte kaldet ind i en fil, beskytter kun mod uheld. En agent, der prøver igen ad en anden vej, kommer igennem.
Sæt reglen op i forvejen, hvis du selv bruger agenter med kommandolinjeadgang. Så står den klar, når du får brug for den.
Så nu skal en blokering meldes ordret: hvilket kald det var, hvad det skulle bruges til, og at det blev afvist. Kaldet må aldrig flyttes til en anden form for at komme forbi kontrollen, heller ikke når blokeringen ser ud som en falsk positiv. Reglen står i alle mine fem agentdefinitioner.
Fejl 4: Firecrawl brugte 9 gange det normale forbrug i 4 dage (1.-4. september)
Mit forbrug af Firecrawl-credits lå normalt omkring 70 om dagen. I fire dage i starten af september brugte samme system omkring 645 credits om dagen. Ingen planlagt natkørsel var synderen. Det var ad hoc-brug i almindelige sessioner, hvor samme forside blev hentet igen og igen. Der var ingen cache og intet loft, så intet advarede mig undervejs.
Uden et dagligt overblik over eget forbrug opdager du det først, når puljen er tom.
Rettelsen: en fælles klient med cache, der svarer på millisekunder i stedet for knap et sekund. En spærring mod at bruge Firecrawl på egne domæner. Et hårdt loft på 40 credits pr. kørsel, der kaster en fejl, før pengene reelt er brugt. Og en cost-log, der gør forbruget synligt hver dag, i stedet for først når puljen er ved at være tom.
Hvorfor skal en anden agent kontrollere arbejdet? 528 tjek, der blev til 10
En kontrol, der læser sit eget output, melder kun grønt på det, den selv har valgt at se. Et verifikationsscript, jeg byggede, tog sin liste over sider og forventninger fra byggekørslens egen fil. Første gang kørte det 528 tjek på 76 sider. Anden gang, efter en kørsel der kun havde rørt tre kort, kørte det 10 tjek, og outputtet sagde alligevel "verificeret" begge gange, fordi scriptet aldrig sammenlignede mod noget uden for sig selv.
Bygger du selv et verifikationsscript, så lad det aldrig hente sin egen facitliste. Det er præcis den fælde, jeg gik i.
Den regel, vi har i dag: en reviewer skal være en anden agent end den, der producerede noget, og den skal have det færdige output at kigge på — den rendrede side eller et skærmbillede, ikke kildeteksten.
Hvad ville jeg gøre fra dag 1? 5 regler, hvis jeg startede forfra
Startede jeg helt forfra, ville jeg bygge disse fem regler ind fra dag 1 i stedet for at vente på fejlen, der krævede dem.
- Byg den fælles API-klient med cache, cost-log og et loft, før det første script overhovedet skriver sit første kald.
- Skriv vagter ved start af en handling. Slet dem først, når succesen er bevist.
- Mål, om arbejdet faktisk blev udført. Exitkoden fortæller kun, at jobbet sluttede.
- Betragt en vagt som utestet, indtil du selv har set den fejle på en fejl, du selv har plantet.
- Bliver et af dine kald blokeret, er det blokeret. Meld det ordret, og byg aldrig en vej udenom.
Det har jeg ikke styr på endnu
Jeg måler mange ting i dette system, men ikke alt. Sprogmodellernes eget tokenforbrug har jeg ikke målt, og cost-loggen dækker kun DataForSEO og Firecrawl. Jeg kender abonnementsprisen, 360 euro om måneden, men ikke hvor meget af den den enkelte agents arbejde reelt fylder. Tidsbesparelsen i timer, som hele opsætningen skulle give mig, findes der heller ingen måling af — jeg har en stærk mavefornemmelse, men ingen tal, jeg vil stå på. For Firecrawl kender jeg forbruget i credits, men ikke i kroner.
Er du i gang med at sætte AI-agenter op i din egen virksomhed? Jeg hjælper med godkendelser og vagter af samme slags. Mere om det på blackspring.dk/ai-raadgivning/.