En grundig tutorial udgivet 15. maj 2026 viser, hvordan man bygger et MCP‑style routed agent‑system fra bunden. Ikke en pæn demo, men et fuldt flow med modulariserede tools, hybrid routing og kontekst‑injektion. Koden og eksemplerne er der. Og ja, den kører.
Hvorfor det er vigtigt nu: Virksomheder skal have agenter i drift, ikke bare på slides. En arkitektur der begrænser synligheden af capabilities, planlægger tool‑kald disciplineret og bærer konteksten rent hele vejen, er forskellen mellem et PoC der imponerer, og et system der også overlever næste kvartal.
Hvad tutorialen bygger
Tutorialen beskriver et sammenhængende system: en modulær tool‑server, en hybrid router og en agent, der planlægger, eksekverer og injicerer kontekst i svaret. Det er udtrykkeligt MCP‑inspireret: klienten opdager tools via schemas, og routeren eksponerer kun relevante værktøjer for en given opgave. Kilde og kodeuddrag står på MarkTechPost, som vi har læst igennem og krydstjekket med eksemplerne i materialet (kilde).
Tool‑serveren udstiller bl.a. web‑søgning, lokal retrieval, dataset‑indlæsning og Python‑eksekvering. Alt er defineret med strukturerede schemas (pydantic‑lignende modeller). Det gør to ting: 1) værktøjer bliver discoverable og kontrollerbare, 2) router og agent kan begrunde valg og planer i maskinlæsbare felter i stedet for fritekst. Der er sat globale parametre i koden, bl.a. MODEL=gpt‑4.1‑mini og MAX_TOOL_CALLS=3. At kende sin egen tolerance her er vigtigt for latens og stabilitet—og det fremgår tydeligt af tutorialen.
Hybrid‑routeren kombinerer heuristik (enkle regler, tags, nøgleord) med LLM‑reasoning for at beslutte, hvilke tools der overhovedet må bruges. Pointen er at minimere eksponeringen. Ikke alt er synligt altid. Routeren returnerer både valgte tools og en begrundelse, hvilket er guld til fejlsøgning. Det er MCP‑tanken i praksis: politik først, så frihed.
Plan, eksekvering og kontekst
Agenten lægger en plan: hvilke tools, hvilke argumenter, i hvilken rækkefølge. Planen kan også sige “direkte svar”, hvis der ikke er brug for værktøj. Under eksekvering indpakkes hvert tool‑kald og hver fejl i results, som agenten læser og syntetiserer videre på. Fokus er på sikker kørsel og fejlhåndtering—ikke bare optimistisk orkestrering.
Kontekst‑injektionen er eksplicit: output fra tools opsummeres og mappes ind i modelkonteksten i næste trin. Ingen magi, bare disciplineret datastrøm. Tutorialen viser flere hverdagsopgaver, hvor routing‑politikker, begrænset tool‑adgang og præcis kontekst gør systemet forklarligt og effektivt (kilde).
Bemærk også, at schema‑niveauet dokumenterer både input og forventede effekter. Tørt—men i drift er det netop det, der redder jer, når en tool‑server rulles ud i version 1.4, et felt skifter type, og alt ellers bryder sammen. Små ting. Store konsekvenser.
Hvorfor MCP‑principperne er vigtige i praksis
Uden kontrolplan og begrænset eksponering ender agenter hurtigt som ukontrollerede generalister. MCP‑tankegangen holder systemet stramt: routeren vælger få, relevante tools; agenten forklarer sin plan; og konteksten bæres gennem hele kæden. Det giver sporbarhed og gør det realistisk at debugge.
For virksomhedsbrug betyder det skalerbarhed og fortolkbarhed. Vi ser især tre gevinster: hurtigere prototyper (teams kan plugge nye tools på uden at røre kernen), enklere sikkerhed (færre nøgler og endpoints eksponeres per kald) og bedre driftsdisciplin (hvert trin er observérbart). Use cases er de sædvanlige—men med mere disciplin: AI‑assistenter der slår op i systemer, automatiserede dataflows og integration på tværs af interne API’er.
I forretningskritiske processer handler det om at kunne dokumentere, hvorfor modellen gjorde det. MCP‑stilen gør det målbart. Ikke perfekt, men noget man kan stå på, når revisionen kommer forbi med skarpe spørgsmål.
Hvad Snilld har erfaret
I et PoC for en nordisk virksomhed så vi en heuristisk regel overeksponere et Python‑tool ved tvetydige forespørgsler. Brugeren skrev “beregn tal for Q2” uden yderligere kontekst, og routeren lod Python slippe igennem for tidligt. Vores løsning var at kræve mindst to kontekstsignaler, før Python frigives, samt at sætte MAX_TOOL_CALLS til 2 i første hop og derefter tillade en tredje kun hvis routing‑rationalet inkluderede en eksplicit reference til datakilde. Det stoppede fejlen på stedet.
I en anden case gav LLM‑drevet routing en smule nondeterministisk adfærd ved enslydende forespørgsler. Vi byggede et fallback‑lag med deterministiske regler og streng logging. Når usikkerheden var over en tærskel (0,25 i vores simple skala), faldt routeren tilbage til en konservativ tool‑liste. Banalt, men det sænkede overraskelser i produktionstest markant. Anonymiseret Snilld‑erfaring, ja, men desværre genkendeligt.
Og en anekdote: Vi satte en tool‑server op en sen eftermiddag i Valby. En enkelt schema‑ændring på dataset‑loaderen—et felt der gik fra str til list[str]—brød tre flows. Vi brugte en time på at lede efter fejlen og endte med at versionere schemas ligeså stramt, som vi versionerer API’er. Det burde vi have gjort fra dag ét.
Implementerings‑ og driftspainpoints
Inden noget kaldes produktion, skal governance være på plads: adgangskontrol til tools og schemas, audit‑logning af alle routerbeslutninger og tool‑kald, og en klar ændringspolitik. Uden audit kan I ikke genskabe hændelser ved fejl—så er man allerede for sent på den.
Sikkerhed er den svære del. Python‑eksekvering skal i sandbox: ingen netværksadgang som udgangspunkt, begrænsede CPU‑ og tidsslots og ingen filsystem‑skriveadgang uden eksplicit whitelisting. Hemmelige nøgler må kun ind i tools, når routeren eksplicit godkender—helst via et midlertidigt token, ikke en rå miljøvariabel. Tutorialen nævner sikkerhedsovervejelser, men går ikke i dybden med sandbox‑implementering eller audit‑logning—her må virksomheder selv bygge det rigtigt.
Performance‑monitorering: mål latens per tool‑kald, samlet tid per forespørgsel, fejlrate per tool samt retry‑mønstre. MAX_TOOL_CALLS=3 er fint til læring, men kan være for højt i kaskadende fejlscenarier. Byg en backoff‑strategi og en per‑tool circuit breaker. Få jeres model‑ops i drift: versionering af prompts, test‑pulls på nye modelversioner og en enkel rollback‑mekanisme.
Tekniske valg og tradeoffs
Hvor meget routing skal være heuristisk kontra LLM‑drevet? Start 60\/40 til heuristik, skift til 50\/50 når I har god telemetri, og gå først 40\/60 hvis I kan dokumentere gevinst på præcision uden at miste stabilitet. Heuristikker dør sjældent uden varsel; LLM‑reasoning gør det indimellem—især på tvetydige prompts.
Hvor detaljerede skal tool‑schemas være? For detaljerede schemas øger vedligehold, for løse schemas øger runtime‑fejl. Valider schemas isoleret, giv felter semantiske beskrivelser og eksempelsæt, og brug version‑IDs som routeren kræver. Sæt en politik om, at major‑schemaændringer automatisk skifter routing‑politik til konservativ tilstand i 48 timer.
Hvor mange tool‑kald per forespørgsel? Tutorialens MAX_TOOL_CALLS=3 er et fornuftigt loft til PoC. I drift foreslår vi 2 i standardflow og 3 kun ved eksplicit planlægningsrationale, der refererer til tidligere tool‑output. Det skærer latens og begrænser tool‑pingpong. Sikkerhed kontra funktionalitet: de mest følsomme tools (skrivende adgang, kodeeksekvering) bør kræve to uafhængige signaler—enten en regel og en modelscore eller to regler.
Operations‑playbook
En kort to‑do for et mellemstort PoC på 2–4 uger. Vi plejer at gøre sådan her: Først arkitekturcheck (afgræns tools, definér schemas, sæt routerpolitikker og MAX_TOOL_CALLS). Derefter en testplan (syntetiske prompts, edge cases og replay af fejlscenarier med telemetri). Så sikkerhedscheck (sandboxing, hemmeligheder, adgangsroller). Til sidst overvågning og rollback (dashboards for latens\/fejl, alarmer og en enkel knap til at slukke “farlige” tools uden deploy).
- Ressourcer: 2–3 ingeniører, 1 sikkerhedsrevisor på deltid, 0,5 dataops. Det lyder beskedent, men rækker til et solidt PoC.
- SLA‑overvejelser: mål T95‑latens pr. tool og total. Sæt midlertidig SLA kun på read‑tools, ikke write.
- Rollback: hold sidste to router‑ og schema‑versioner varme. Én kommando for at låse til konservativ routing i 24 timer.
Hvad industrien gør
Skiftet fra demoer til drift foregår overalt. Towards AI’s LAI #127 beskriver, hvordan infrastruktur‑laget i AI er ved at blive produktet, og hvordan retries i agenter stille og roligt kan sabotere rigtige systemer, hvis man ikke gør det disciplineret (kilde). Det matcher det, vi ser i felten.
Trenden er klar: agenter skal have pålidelig eksekvering, klare kommunikationsmønstre og en arkitektur, der overlever produktionens krav. MCP‑princippet passer ind, fordi det tvinger os til at tænke i snævre, dokumenterede capabilities—ikke i “den kan alt”-fortællinger. Kedeligt er godt, når det kører kl. 03.12 natten til tirsdag.
Vi oplever tit, at teams undervurderer inter‑agent kommunikation. Det er ikke flere agenter, der redder noget, men bedre protokoller, tydelig state og mindre “magi”. LAI #127 fremhæver det samme. Det gør ikke tutorialen dårligere—den er stærk på byggeklodser—men det er et ekstra lag, man skal tænke med før drift.
Faktaboks om forskelle
Tutorialens modelvalg angiver MODEL=gpt‑4.1‑mini. I vores tests har vi set lavere latens, men også en anelse flakkende routing‑rationale på meget tekniske prompts. Vi hæver derfor modellen et trin på selve routerbeslutninger, hvis usikkerheden er høj, mens svarsyntesen kan ligge på en billigere variant. Kilde til opsætning: tutorialen. Vurdering: anonymiseret Snilld‑erfaring.
Sikkerhedsniveau i tutorialen omtales overordnet. I produktion kræver Python‑eksekvering fuld sandboxing med ressourcebegrænsning og netværkskontrol. Det ser vi som en hård forudsætning, ikke en opt‑in. Kilde: Snilld‑praksis.
Performance‑tal er ikke dokumenteret i tutorialen. Mål gennemsnitlig latens pr. tool‑kald og total ved 100 RPS mod tool‑serveren samt CPU\/memory‑profil. Indtil tallene findes, antag konservativ kapacitet i PoC.
Hvad der mangler før produktion
Der er nogle huller, der bør lukkes, før noget kaldes produktionsklart. For det første reproducérbare benchmarks: en simpel test‑suite med 50 faste prompts, kendte ruter og forventet latens. For det andet en klar retry‑politik pr. tool—hvor mange, hvor længe, med hvilken backoff. For det tredje en DR‑plan: hvordan fortsætter systemet, hvis tool‑serveren er nede, eller hvis routeren fejler åben.
Omkostninger bør også regnes ud. Tutorialen nævner et modelnavn, men ikke prisprofil eller alternativer. Praktisk tip: beregn omkostning pr. 1000 forespørgsler med jeres egen gennemsnitlige tokenbrug og latensbudget, og læg 20 procent oveni til retries og fejlsøgning. Det fjerner de værste overraskelser.
Og endelig governance over schemas. Der er ingen genveje her. Behandl schemas som kontrakter, ikke som kommentarer i koden. Læg dem i eget repo med review‑krav, changelogs og automatisk validering i CI. Vi blev selv klogere på den hårde måde.
Konklusion og anbefalinger
Byg selv, hvis I allerede har API‑ejerskab, devops‑disciplin og sikkerhed på holdet. Køb\/partner op, hvis I mangler sandbox‑kompetence, eller hvis forretningen kræver SLA’er fra dag ét. Det er dyrt at lære sikkerhed i produktion.
Holdet bør mindst bestå af en platformingeniør med orkestreringserfaring, en dataingeniør med schema‑sans, en sikkerhedsprofil der kan sandboxe Python ordentligt, og en product owner der tør sige nej til for mange tools i v1. Basalt—men det virker.
Næste skridt til et ansvarligt PoC: start med tutorialens byggesten, sæt konservative grænser (MAX_TOOL_CALLS=2 i første iteration), mål alt, og planlæg fra dag ét for rollback. Forskellen mærkes først, når man sidder med det i hænderne.
