Marktechpost har udgivet en tutorial, der bygger et agentisk AI-system oven på OpenAI API. Ikke “én stor agent”, men en pipeline i tre roller: planner, en tool-using executor og en critic, der dobbelttjekker. Koden går hele vejen ned i værktøjslaget: sikker kalkulator, mini-knowledge base, JSON-udtræk og filskrivning. API-nøglen hentes med getpass, så den ikke drysser ud i notebook-output. Små valg, stor forskel i hverdagen.
Hos os i Snilld har netop den modulære opdeling vist sig nyttig. Strategi for sig. Handling for sig. Kvalitetssikring for sig. Det gør fejlretning og opgraderinger nemmere og mere rolige. Vi har brugt samme mønster i projekter – ikke perfekt, men tættere på noget, man tør sætte i drift.
Hvad tutorialen faktisk viser
Tutorialen installerer OpenAI SDK, initialiserer en klient og sætter en modelstreng én gang i en variabel: MODEL = “gpt-5.2”. Det er et eksempel fra tutorialen; modeltilgængelighed kan variere på tværs af konti og tid. API-nøglen hentes via getpass(), så den ikke ender i klartekst i kode eller output. Arkitekturen er tredelt: planner bryder opgaven ned, executor kalder værktøjer, og critic vurderer kvalitet.
De konkrete værktøjer er dokumenteret i koden: en sikker kalkulator via _safe_calc, en keyword-baseret mini-KB med bl.a. en execution protocol og en output-quality policy, en JSON-udtrækker (_extract_json) og en filskriver (_write_file), der også returnerer sha16 og byte-længde. Alt returnerer strukturerede ordbøger, så programmet kan reagere deterministisk på succes og fejl. Kilden er Marktechpost-tutorialen.
Hvorfor modularitet rammer rigtigt i virksomheder
Én monolitisk agent bliver hurtigt uigennemsigtig. Med en pipeline kan teams pege på det svage led og forbedre netop dét. Manual-briefen læser arkitekturen sådan – mere robusthed, enklere debugging, målrettede forbedringer – og det matcher vores erfaring. I et kundeprojekt gik en fejlsporingssløjfe fra dage til timer, fordi vi kunne aflæse præcist, hvor kæden hoppede af. Det er vores praksis, ikke en kontrolleret studie.
Og en lille ting med stor effekt: korte mellemnoter fra executor. De gør logs nyttige. Vi byggede efterfølgende et lille internt toolkit til trace-ids og mellemresultater. Vores anekdotiske måling, baseret på interne fejlsøgningslogs i et tidligt projekt, pegede på cirka 30 procent hurtigere debugging. Tag det som erfaring, ikke som evidens.
Den tekniske kerne kort og ærligt
Tutorialen bruger velkendte Python-greb: getpass til skjult nøgle, miljøvariabel til API-key, enkel OpenAI-klient og en samlet MODEL-variabel (eksempel: “gpt-5.2”). _safe_calc whitelister tegn, forbyder variable og evaluerer uden builtins. Den returnerer strukturerede succes-/fejlresultater, som både executor og critic kan håndtere.
Begrænsningerne er tydelige: eval, selv pakket ind, er sårbar for kanttilfælde. Hvis domænet er penge, compliance eller sundhed, bør man bruge numeriske biblioteker eller en sandbox med hårdere inputvalidering. Tutorialen dokumenterer ikke en fuld trusselmodel for _safe_calc – det kræver ekstra arbejde i produktion.
Værktøjer og KB i praksis
Kalkulatoren dækker hurtig tal-logik. KB-søgningen er enkel, men nyttig som politisk kompas: execution-protocol, output-krav, små playbooks. JSON-udtrækket prøver at finde en krølparentes-blok og parse. Når det fejler, får man fejldetaljer og et råudsnit. Filskriveren opretter mapper, gemmer indhold og leverer sha16 og byte-længde til sporbarhed.
I praksis kan agenten så regne, slå retningslinjer op, validere at output faktisk er JSON og gemme en leverance. Fejl, vi ofte ser: JSON uden topniveau-objekt, encoding-problemer ved filskrivning og KB-opsalg, der ikke rammer relevante tokens. De tre står oftere i vejen end selve modelgættet.
Sikkerhed og drift
getpass er fint i notebooks. I produktion skal nøglehåndtering flyttes til et secret store med rotation og rollebaseret adgang. For at undgå gentagelser samler vi de vigtigste driftsgreb her som en tjekliste:
- Hemmeligholdelse: secret store (fx Vault/AWS Secrets Manager), rotation, mindst mulige rettigheder.
- Isolation: kør agenten i miljøer uden vilkårlig shell- eller netadgang. Begræns udgående forbindelser.
- Audit: log alle værktøjskald med input, nøglemetrikker og output-hash. Gem trace-id på tværs af moduler.
- Observabilitet: mål critic-fail-rate, tool-failure-rate, gennemsnitlig plan-længde og andel af outputs med menneskelig overtagelse.
Tutorialen definerer ikke SLAs. Anbefalingerne her er operationelle praksisser, ikke citater fra kilden.
Governance og operativ praksis
Critic-modulet bør tjekke tre ting som minimum: formkrav (schema), numerisk sanity og policy-efterlevelse fra KB. Marktechpost viser KB-politikkerne, som er et fornuftigt udgangspunkt. Supplér med et letvægtsflag for ukendte værktøjer og usædvanligt lange beslutningskæder fra planner.
Og så ansvarskæden. Hvem må ændre KB? Hvem godkender nye værktøjer? Hvem må skifte model eller temperatur? Manual-briefen peger på governance som værdidriver, og vi genkender det: uden en tydelig ejer af critic og faste release-ritualer for KB glider kvaliteten stille. Et lavpraktisk råd: changelog for KB og månedlige retros på critic-fejl.
Tre implementeringsspørgsmål, der bider først
Latency og pris. En planner, en executor og en critic betyder mindst tre modelkald per forespørgsel – flere hvis der eksperimenteres med værktøjer. Overvej batching af simple planner-opgaver eller en lettere model til critic. Det er vores erfaring, ikke tutorialens anvisning.
Fejltilstande og rollback. Hvad hvis filskrivning lykkes, men JSON-parse fejler bagefter? Brug idempotency-nøgler til artefakter, sagelogning bundet til et fælles trace-id og kompensationshandlinger, der kan markere delvise leverancer som forældreløse. _write_file’s sha16 er en god base for sporbarhed. Læg versionslagring og immutability ovenpå.
Testdata og QA for værktøjer
Værktøjslaget knækker oftest. Planer er sjældent synderen. Lav kontrakttests til _safe_calc, _kb_search, _extract_json og _write_file – både glade og slemme cases. Tilføj fuzz-tests for JSON og for kalkulatorens input. Tutorialen leverer ikke sådan en testpakke; vi anbefaler at få den på plads før piloter.
En observation fra praksis: Vi satte en critic til at fange formateringsfejl. Anekdotisk målte vi, via stikprøver af outputs og simple tjekskripter, at den fangede cirka 60 procent af de små formfejl, men missede en del semantiske brister i domæner med mange forkortelser. Vores løsning var kombinationen af automatisk critic og menneskelig stikprøvekontrol i de første uger.
Hvor arkitekturen ikke løser alt
_safe_calc kan stadig presses af snedige inputs. Whitelists hjælper, men uden formel trusselmodel og isoleret runtime er man ikke i mål. KB-opdateringer kræver proces: hvem ændrer hvad, hvordan ruller man tilbage, og hvornår testes for regressioner? Og når agenten kan skrive filer, kan den også lække data. Sæt allow-lister for stier og hold miljøet væk fra følsomme mount-points.
Selv med critic er kontekst let at tabe. KB-politikker hjælper, men de forældes hurtigt. Det står ikke i tutorialen; det er vores læsning fra drift: planlæg løbende opdatering og oprydning, ellers glider kvaliteten.
AI som helt normal teknologi
En supporting-tekst argumenterer for at betragte AI som “normal” teknologi. Det er nyttigt her: en agentisk pipeline minder om et lille, distribueret system – tre services, et par værktøjer, en mini-KB. Samme grunddisciplin som altid: hemmeligheder, logging, tests, rollout. Mindre mystik gør arbejdet nemmere.
Praktisk tommelfingerregel hos os: behandl agenten som en almindelig service med change management. Så sover man bedre. Også om mandagen.
Benchmarks I selv kan køre
Tutorialen leverer ikke tal på latency, pris pr. forespørgsel eller criticens fangstrate. Fint – men så må I selv måle. Vi anbefaler en letvægtsplan:
- Datasæt: 100–200 opgaver fra jeres domæne fordelt på fx 50% rene Q&A, 30% værktøjsopgaver (calc/KB), 20% filleverancer.
- Metrikker: kald pr. opgave, tid pr. modul, tool-failure-rate, critic-pass-rate, cost pr. opgave.
- Procedure: kør ved hver model- eller KB-ændring og gem resultater i et simpelt dashboard.
Det er anbefalede næste skridt – ikke noget, tutorialen dækker.
Konkrete næste skridt
Start med et afgrænset PoC, der bruger præcis de værktøjer, der er vist i tutorialen. Behold getpass i udvikling, men migrér til et secret store i staging, før første pilot. Indfør rollebaseret adgang for modelkald og filskrivning. Definér et critic-SLA, fx at 95 procent af outputs passerer schema- og talchecks under en given tærskel.
Mål det, der betyder noget: tool-failure-rate, gennemsnitligt antal værktøjskald pr. opgave, cost pr. ticket, andel med menneskelig korrektion og tiden fra plan til leveret fil. Notér, når planner-steps ændrer sig. Den slags gør forbedringer synlige.
Hvis vi stod med budgettet i hånden
Helt konkret, og ærligt: 1) klon tutorialens pipeline og få PoC’en op i et isoleret miljø, 2) instrumentér modulgrænser med trace-ids og korte mellemnoter, 3) stram værktøjsadgangen og få critic til at håndhæve schema- og talchecks. Først derefter: åbne for filskrivning til et versioneret objektlager og lægge en billigere model på critic for at holde pris nede.
Vi starter typisk med værktøjslaget før KB. Fordi det er dér, vi oftest finder de første brud. KB kan man udbygge løbende, når skelettet står. Man opdager forskellen, når man sidder med det i hænderne.
