Den halvt åbne laptop i sportshallen er desværre blevet normalen. Business Insider beskriver en forælder ved skøjtehallen, der holder låget på klem for ikke at dræbe sin agent-session. Det ser komisk ud. Men det er en reel vane.
Vi har set det hos kunder. En tech lead bar rundt på sin Mac mellem møder for at undgå at miste konteksten: “Hvis jeg lukker, ryger halvdelen af refaktoren.” Praktisk er det ikke. Sikkerhedsmæssigt heller ikke.
Hvorfor låget ender som kill switch
AWS peger på fem faste behov for en lokal agent: et shell, et filesystem, projektet lokalt, installerede dependencies og de rigtige credentials. Laptopen har alt det fra start, så den vinder værdskabet på nærhed, ikke kvalitet. Kilde: AWS’ blog om AgentCore.
Konsekvensen er deling af alt: shell, VPN, SSH‑nøgler, localhost‑databaser og porte. Tre agenter i tre branches bliver til tre processer på én maskine. Luk låget, og du suspenderer builds, halvinstallerede dependencies og refaktorer. Skrøbeligt — og ja, vi har set det ske midt i en demo.
Hvad AgentCore faktisk leverer
AgentCore på Amazon Bedrock giver hver session en isoleret Linux microVM, et persistent workspace, et rigtigt shell og deterministisk kommandoeksekvering. Det sidste fjerner tilfældige PATH‑afvigelser og globale toolchain‑spøgelser.
Rundt om det ligger et identity‑lag, en gateway der samler værktøjer via Model Context Protocol med tokens uden for agenten, og observability der sender hændelser til Amazon CloudWatch. Det er produktdokumentation fra AWS. Arkitekturen er fornuftig, men tredjeparters driftstal mangler stadig.
Hvorfor isolering betyder noget i hverdagen
Isolerede miljøer gør parallelkørsel nem. I stedet for at jonglere porte og worktrees på én laptop, starter du to microVMs — hver med egne processer og midlertidige nøgler. Med eksterne credentials bliver “least privilege” lettere at håndhæve end på en personlig maskine.
Vi har set kollisioner: én agent ændrer package.json for at få tests grønne; en anden sletter node_modules for at bygge en ny binary — og begge fejler. Isolerede workspaces gør den type fejl sjældnere. Ikke væk, men sjældnere.
Identitet, gateway og logging
Identitetslaget betyder, at kald til fx GitHub sker i korrekt rolle. Gatewayen centraliserer adgang via MCP og holder tokens uden for agentens proces, så et injiceret build‑script ikke kan læse ~/.aws/credentials.
CloudWatch samler kommandoer, fejl og hændelser i den stak, drift allerede bruger. Det gør søgning, alarmer og historik til en del af standarden i stedet for skærmbilleder fra en terminal.
Tre konsekvenser for sikkerhed og drift
Først: mindre lateral adgang. Separate filsystemer og eksterne tokens reducerer chancen for, at en agent ramler ind i hemmeligheder, den ikke burde se.
Andet: enklere parallelkørsel uden port‑ og proceskollisioner. Mindre koordinering, færre stopklodser.
Tredje: audit og logging fra start. I kan bygge runbooks, alarmer og replay af forløb ud fra de samme logs som resten af jeres systemer.
Til gengæld opstår nye opgaver: netværkspermisser mellem microVM og interne services, stram adgangsstyring i gatewayen og cost‑kontrol, fordi det bliver let at spinne mange sessions op. Quotas, budgets og regler for lange jobs er ikke valgfrie.
Omkostninger og alternativer
Pris handler ikke kun om compute. Towards AI beskriver en open source‑terminalagent fra Moonshot, Kimi Code CLI (MIT‑licens), koblet til en model prissat omkring 0,60 USD pr. million output‑tokens. Samme artikel angiver Claude Codes standardmodel Opus 4.8 omkring 25 USD pr. million. Kilde og tidsstempel: Towards AI, opdateret 8. juni 2026. Det er et øjebliksbillede — priser og modelnavne flytter sig.
I praksis: Hvis en agent spytter meget kode og tests ud, kan modelregningen dominere. MicroVM‑hosting ændrer ikke tokenpriserne, men giver frihed til at blande: dyrt til svært, billigt til batch. Kvalitet vs. pris måles bedst på egen kode. Uafhængige benchmarks på tværs af modeller og realistiske opgaver er ikke bredt publiceret endnu.
Implementering der virker i virkeligheden
Flyt agenter væk fra laptops med et snævert scope og en klar governance‑plan. Tjekliste før første run:
- Governance: roller, mindst mulige privilegier, kortlivede tokens og rotation som praksis
- Tokenstyring: central udstedelse, afgrænsning per værktøj, audit i MCP‑gateway
- CI/CD: bind persistente workspaces til repos og artefaktlager, definér clean‑up
- Netværk: egress‑regler, VPC‑endpoints, DNS‑politikker for builds og dependency‑hentning
- Backup/retention: opbevaring af logs og workspaces for compliance — hvor og hvor længe
- Observability: CloudWatch‑dashboards, alarmer og søgeprofiler på agent‑hændelser
Små disciplinpunkter gør en forskel: navngiv runs, standardisér miljøvariabler, og lad lange jobs køre på servicekonti, ikke personlige profiler.
Det læserne bør teste selv
Feltmålinger slår mavefornemmelser. Kør en kort benchmarkpakke, og log tallene:
- Latency: tid fra prompt til første token, og til tests passerer
- End‑to‑end tokenforbrug: input/output pr. opgave
- Kompatibilitet: build af jeres top 5 toolchains inkl. native extensions
- Stabilitet: fejlrate over N gentagelser af samme opgave
- Omkostning: samlet pris pr. grøn PR (compute + tokens + storage)
Hold baseline lokalt på en laptop og sammenlign med AgentCore‑sessions. Samme opgaver, samme repos, samme tests. Så er forskellen målbar.
Data‑egress og adgangsgrænser
Definér tydeligt, hvad der må forlade microVM’erne: kundedata i kildetræet, build‑artefakter, logs, og kald til tredjeparts‑API’er. Sæt allow‑lister på domæner, og blokér skriveadgang uden for projektmappen. Lad gatewayen stå for alle eksterne tokens, og log alle scopes.
Adskil miljøer for udvikling, staging og produktion med hver sin netværksprofil. Det lyder banalt, men det forhindrer den klassiske fejl, hvor en test‑agent rammer et produktions‑endpoint.
Kompatibilitet og en lille testmatrix
Et “rigtigt shell” betyder ikke, at alle native værktøjer virker. Test tidligt:
- Build‑værktøjer og native extensions (fx Python wheels, Node‑addons, Rust/CGO)
- Systempakker og headers (compiler‑versioner, libc, OpenSSL)
- Langkørende jobs og session‑genoptagelse
- Eventuelt GPU‑krav i jeres toolchain — eller fraværet af samme
Planlæg fallback for det, der ikke bygger første gang: justér build‑image, pin toolchain‑versioner og dokumentér undtagelser.
Support og incident response
Med logging i CloudWatch kan support spole tilbage: hvilke filer blev redigeret, hvilke tests kørt, i hvilken rækkefølge. Reproduktion går hurtigere, og MTTR falder.
Byg runbooks til tre hyppige scenarier: permission‑denied, uventede netværkskald til eksterne domæner, og hængende builds. Stop run, tag snapshot, læs logs, genkør med tracing. Enkelt — og effektivt.
Tradeoffs og det vi ikke ved endnu
MicroVM’er løser meget, men ikke alt. Data‑egress skal styres. Model‑latency kan stige ved tunge kald. Drift koster i tokens, compute‑tid, storage og log‑retention. Nogle udviklere vil stadig foretrække korte feedback‑loops lokalt. Fair nok.
Der mangler uafhængige benchmarks for driftsomkostninger, end‑to‑end‑latency og stabilitet i produktion. AWS’ beskrivelser er produktnære, ikke tredjepartsrevisioner. Kompatibilitetsdetaljer for særlige build‑kæder og eventuel GPU‑adgang er heller ikke komplet dokumenteret offentligt. Derfor: pilotér først.
En lille case fra gulvet
Vi kørte en snæver pilot hos en mellemstor SaaS‑kunde: to workflows (et bugfix med tests og en mindre migrationsopgave). Hver AgentCore‑session fik eget workspace; gateway gav GitHub og Jira. Vi målte tid til grøn test, antal menneskelige indgreb og miljøkonflikter. Resultatet: hurtigere til grøn test i 1 af 2 sager, færre konflikter og markant mindre laptop‑babysitting. Ét nedbrud skyldtes en native extension, der ikke byggede i microVM’en — løst med en justering af build‑image.
Det mest mærkbare var adfærden: ingen gik rundt med halvåbne maskiner. Der blev faktisk roligere i rummet.
Hvad vi anbefaler nu
Hold piloter små (1–2 workflows). Sæt governance og observability op før første run. Vælg modeller bevidst pr. job. Mål latency, tokens, fejlrate og menneskelige indgreb — ellers lærer I for lidt.
Den halvt åbne laptop er et symptom på manglende centralisering og automatisering. Få mødeopsummeringer og task‑ekstraktion på skinner. Lad agenter åbne tickets automatisk. Når grundstrukturen er på plads, forsvinder behovet for lokal kontekstpleje. Det er vores erfaring.
Hvornår kan låget lukkes
Hvis jeres agenter i dag lever på udviklernes laptops, kan I lukke låget for godt på udvalgte opgaver inden for 2–6 uger — når netværk, identitet og logging er på plads. Tungere toolchains ender ofte i en hybrid. Det er fint. Flyt de lange, skrøbelige jobs væk fra personlige maskiner først.
Business Insider gav billedet fra skøjtehallen. AgentCore giver infrastrukturen, der gør billedet overflødigt. Resten er grundarbejde i adgang, drift og vaner. Man mærker forskellen, når man sidder med det i hænderne.
Kilder og noter
Teknisk beskrivelse af microVM, identity, MCP‑gateway og CloudWatch‑logging: AWS’ officielle blog. Anekdoter om halvåbne laptops: Business Insider. Pris og open source‑alternativ: Towards AI om Moonshot/Kimi Code CLI, opdateret 8. juni 2026. Vi markerer bevidst huller: ingen uafhængige benchmarks for totalomkostning/latency, uklare priseksempler for microVM‑drift og ufuldstændige kompatibilitetsdetaljer. Valider i piloter.
