En frisk tutorial går praktisk til værks og bygger en letvægts, nanobot‑inspireret AI‑agent fra bunden i Google Colab. Ikke endnu et framework, men få, klare byggeklodser man kan læse, ændre og køre med det samme. Der er en Provider‑abstraktion, dataklasser for LLMResponse og ToolCall, et enkelt agent‑loop, session‑memory, lifecycle‑hooks, skills og en MCP‑style tool‑server. Det hele kan køre uden API‑nøgler via en mock‑provider — eller via en OpenAI‑kompatibel adapter, når man vil teste rigtigt [kilde 2090].
Det lyder småt. Det er pointen. Colab som friplads til at eksperimentere med model‑ og tool‑interaktion uden at drukne i et stort rammeværk. Timingen er god, fordi mange teams balancerer mellem at lære og at levere.
Hurtigt overblik
Tutorialen starter med et skelet: en Provider base‑klasse, der definerer én kontrakt — complete tager meddelelser og tools og returnerer en LLMResponse [kilde 2090]. Der er dataklasser for ToolCall med id, name og arguments, og LLMResponse med content, tool_calls, finish_reason samt usage‑tællere. En OpenAICompatibleProvider implementerer kontrakten via AsyncOpenAI og støtter OpenAI‑lignende gateways som OpenRouter, Together eller lokale endepunkter, ifølge kildekoden. Vil man køre helt offline, ligger der en MockProvider, som deterministisk afgør, hvornår der udstedes et tool‑kald, og hvordan svaret samles i loopet.
Derudover vises tool‑registrering og et sæt lifecycle‑hooks (før/efter modelkald og tool), så man kan logge, tælle og afbryde. Session‑memory er simpelt og in‑memory i notebookens runtime, men holder kontekst gennem flere agent‑omdrejninger. Skills pakkes som funktioner med skemaer, så modellen kan kalde dem med strukturerede argumenter. Til sidst samles en MCP‑style tool‑server, der eksponerer værktøjer over et enkelt protokolformat, så agenten kan kalde dem konsistent.
Sådan kører det i Colab
Notebookken bruger et lille hjælpe‑script til pip‑installation direkte i runtime: et _pip_install, der kalder python ‑m pip install ‑q pakker [kilde 2090]. Den prøver at importere openai og nest_asyncio; fejler det, installeres de og aktiveres. OpenAICompatibleProvider oprettes med AsyncOpenAI(api_key=…, base_url=…), og complete kalder chat.completions.create med model, messages, tools og tool_choice=auto. ToolCall‑argumenter parses som JSON; fejler parsing, lægges rå‑feltet i arguments._raw — en praktisk faldskærm under debug.
Mock‑varianten kræver ingenting. Ingen netværk, ingen nøgler. Den efterligner det, der betyder noget i loopet: hvornår der skal udstedes et tool‑kald, og hvordan der samles op til et endeligt svar. Det gør agenten reproducerbar, også når kvoter eller netværk driller i Colab.
Hvorfor Colab giver mening
Notebookken er et værksted. Hurtig prototyping, team‑undervisning og forsøg med værktøjs‑API’er uden at sætte hele CI‑kæden i brand. Primærkilden understreger at gøre hele stakken kørbar i Colab for at lære byggeklodserne i ro og mag [kilde 2090].
Det matcher et udbredt råd: brug letvægts‑prototyper til at afklare værdi og grænser, men planlæg et rigtigt løft til produktion med styr på data, overvågning og governance. Manual‑briefen fremhæver krav til produktionalisering, sikker datahåndtering og integration, før man kan tale om forretningsværdi [kilde 2091].
Hvad man faktisk får ud af at køre koden
Efter en times leg i Colab står man med konkrete artefakter: et kørende agent‑loop, der kan beslutte tool‑kald og samle svar; en Provider‑abstraktion, der gør det let at skifte mellem mock og OpenAI‑kompatible endepunkter; eksempler på tool‑registrering med schema og simple skills; session‑memory, der binder samtaler sammen; og en simpel MCP‑style server til at eksponere værktøjer konsistent [kilde 2090].
Det er ikke en færdig app. Det er en vejviser. Man kan se, hvor kontrakterne går, og hvor man selv kan sætte ind med logging, caching, retries og drift.
Tre praktiske anvendelser, tre huller der skal lukkes
Kundeserviceautomation: en agent, der læser kundens besked, kalder et ordre‑ eller retur‑API og skriver et svar. Realistisk — men først når der er adgangskontrol på tools, latency‑mål pr. trin og cost‑tags pr. kald. Ellers stiger regningen, og svaret kommer for sent.
Vidensarbejde: en agent, der søger i dokumentlager, kalder en summarizer og foreslår handlinger. Kræver sikre dataveje, versioneret kontekst og audit‑logs. Og en fallback, når LLM’en svarer ufuldstændigt.
Interne workflows: små task‑agenter, der kan oprette sager, pinge Slack, opdatere en CRM‑post. Her bider adgangsstyring og sandboxing først — plus en enkel effektmåling: hvor mange manuelle klik er faktisk sparet. Manual‑briefen peger netop på sikkerhed, latency og cost som minimumskrav før forretningsværdi [kilde 2091].
Tekniske svagheder og risici i notebook‑formatet
State‑management i Colab forsvinder ved afbrydelse. Session‑memory ligger i RAM og ryger ved runtime‑reset, så persistens er et åbent spørgsmål. Der er heller ikke en standardiseret autentificering mod eksterne leverandører udover API‑nøgler i miljøvariabler, hvilket er sårbart i delte notebooks. Og tool‑sandboxing er kun skitseret — argument‑serialisering kan fejle på skævt JSON, og input‑sanitization er ikke fuldt dækket i koden [kilde 2090].
Det er ikke en kritik af formatet. Det er bare grænsen for en tutorial. Den viser strukturen, ikke en fuld threat model.
Vejen til skalering
Før produktion skal der på plads: overvågning af tokens, fejlrate og tool‑kald pr. session; tracing på tværs af model og værktøjer; logning med maskering af persondata. Dertil en driftbar MCP‑server uden for Colab med autentificering, rate‑limits og isolerede runtime‑miljøer. Failover mellem modeller og gateways ved timeouts, plus SLA‑mål, der måles og følges. Manual‑briefen er klar her: produktionalisering og sikker datahåndtering først [kilde 2091].
Når behovet bliver komplekst, er et orkestreringslag værd at overveje. LangGraph beskrives som en ramme til at gøre workflows tilstandsfaste, kontrollerbare og produktionsklare, med styring af “flow of intelligence” mellem værktøjer og beslutningspunkter [kilde 2092]. Ikke et must fra dag ét, men nyttigt, når man vil have rollback, genkørsel og tydelige noder/kanter i en proces, der vokser fra notebook til system.
Sikkerhed og compliance
Dataflow skal kortlægges: hvilke dele af prompt og tool‑resultater forlader miljøet, og hvor logges de. Notebook‑miljøer bør betragtes som udvikling; brug testdata eller syntetiske data i startfasen. Adgangskontrol på tools er nødvendig, også i prototyper, ellers kan enhver prompt udløse sideeffekter i systemer, der ikke er tiltænkt. Secrets hører hjemme i en secret‑manager, ikke i en delt Colab‑celle, og GDPR kræver sletning og dokumenteret hjemmel — også når det “bare” er en test [kilde 2091].
Spørg også lavpraktisk: Hvem kan køre notebookken, med hvilke rettigheder? Hvor ender uddata, og hvem må se dem? Små ting, der ofte vælter det første pilotforsøg.
Integration i den eksisterende stack
Provider‑abstraktionen gør det let at bytte model‑leverandør, men i en virksomhed bør det kobles til en gateway‑strategi: centraliserede udgange, fælles politikker, cost‑tagging og en fallback, når én udbyder strammer kvoter. Multi‑provider giver robusthed, men kræver klar rute ved fejl. Derudover bør tool‑laget tale virksomhedens standarder for auth — OIDC, service‑konti, short‑lived tokens — hvilket ikke er dækket i en Colab‑demo.
Orkestrering kan komme fra egne byggesten eller et framework. LangGraph tilbyder styring af state og flow, så komplekse sager kan tegnes og logges i trin [kilde 2092]. Ikke som erstatning for den lette prototype, men som supplement, når man vil måle, teste og rulle sikkert tilbage under drift.
En kort, konkret checkliste
- Persistens for session‑memory: vælg DB fremfor in‑memory; definér skema, retention og kryptering.
- Secrets management: brug KMS/Secret Manager; ingen nøgler i notebooks; roter nøgler automatisk.
- Test af tools: skriv fakes/mocks; property‑tests for argument‑serialisering; fuzz mod JSON‑kanter.
- Observability: metrics for tokens, latency pr. tool og model; tracing med korrelations‑id pr. session.
- Cost‑model: tags pr. provider og tool; budgetalarmer; sammenligningsmålinger mellem gateways.
- Latency‑mål: fastsæt SLO’er for samlet svar og pr. hop; indfør timeouts og retries med backoff.
- Adgangskontrol: ACL på hvert tool; mindst mulige rettigheder; audit‑log på alle sideeffekter.
Hvad skal løses først i en pilot
Start med adgangskontrol på tool‑kald. Uden det er alt andet pynt. Læg derefter cost‑tagging på alle kald og sæt simple budgetalarmer. Få basisovervågning og tracing i gang, så fejl kan reproduceres på tværs af model og tool.
Hvad kan vente lidt: finjusteret retraining, avanceret orkestrering, eksotiske caching‑lag. De er nice‑to‑have, men blokerer ikke for at lære, hvor værdien ligger. Små skridt, tæt feedback, hyppige målinger.
Det der overraskede og det der mangler
Det er bemærkelsesværdigt, hvor langt man kommer med få, klare klasser. Provider, LLMResponse, ToolCall — mere skal der ikke til for at se loopet spille. Også rart med fallback, når JSON‑parsing fejler i tool‑argumenter; det redder debugging. Men trådene om session‑persistens, autorisation af MCP‑kald og en egentlig trusselmodel er endnu løse [kilde 2090].
Der mangler også benchmarks. Hvad koster det pr. anmodning på en OpenAI‑kompatibel gateway i Colab kontra en styret produktionskørsel? Hvor går grænsen for, hvornår man bør løfte til en orkestreret arkitektur? De svar er ikke i tutorialen, og det er fair — det er næste trin.
Konklusion
Tutorialen leverer en gennemsigtig, kørbar miniature af en moderne agentarkitektur. Den er oplagt som læringsvej og basis for hurtige forsøg, især fordi den kan køre både med mock og med OpenAI‑kompatible udbydere [kilde 2090]. Værdien i en virksomhed kommer først med produktionalisering: sikkerhed, adgang, målinger, omkostningsstyring og en plan for skalering [kilde 2091]. Eksperimentér i Colab. Planlæg løftet, før nogen kalder det “i drift”.
