Nyheden kort
AWS demonstrerer, at når “three agents [are] collaborating on a creative workflow that spans several days,” er kortlivede, serverløse sessioner ikke altid nok (kilde: AWS-blogindlægget “Build a multi-agent music production pipeline on Amazon Bedrock AgentCore Runtime Instances”). Pointen er jordnær: tæt agent-samarbejde kræver vedvarende sessions, delt lager og kontrolleret orkestrering—og det ændrer både teknik og økonomi.
Hvad AWS siger — de faktuelle ændringer
Amazon Bedrock AgentCore tilbyder to hostingspor (kilde: AWS-bloggen): MicroVMs og Runtime Instances. MicroVMs er serverløse, én agent pr. microVM, forbrugstakserede og med sessioner op til 8 timer. Runtime Instances kører på AWS-managed EC2, kan være vært for flere agenter på samme instans (1:N), understøtter GPU’er, giver persistent storage via Amazon EBS og tillader sessioner op til 14 dage. Begge bruger de samme AgentCore-runtime-API’er og arbejder med frameworks som CrewAI, LangGraph, LlamaIndex og Strands Agents samt MCP og A2A (kilde: AWS-bloggen).
Konsekvensen er praktisk: MicroVMs er 1:1 mellem runtime og agent, mens Runtime Instances er 1:N, så flere agenter kan co-lokere og dele filsystem. AWS fremhæver, at agenter, der bruger samme capacity provider, kan lande på samme instans via det samme runtimeSessionId (kilde: AWS-bloggen). Det er mekanikken, der gør musikcasen mulig.
Den konkrete pipeline — hvad sker der teknisk
Blogindlægget beskriver en tre-agent workflow (Composition, Delivery, Compliance). Citat: “One agent runs a generative audio model on the instance’s own GPU. The other two open the .wav file it wrote, off a shared volume. By the end, you will have a track you can play.” (kilde: AWS-bloggen). To byggesten er afgørende her: adgang til GPU på selve instansen og et delt, vedvarende EBS-volume.
Agenterne samles på samme Runtime Instance via runtimeSessionId, så de deler filsystem og undgår unødig kopiering. Artefakter pakkes som container images i ECR eller som zip fra S3, præcis som gennemgået i blogindlægget, og deles via EBS. Orkestreringen skal holde styr på rækkefølge, retries og godkendelser—småting som fil-locks og sti-konventioner bliver operative beslutninger, ikke eftertanker.
Hvorfor det betyder noget for arkitekter
Skiftet fra single-agent til multi-agent med delt state flytter arkitekturens tyngdepunkt: stateful sessions, persistent storage, tydelige filhierarkier og versionerede container-artefakter bliver grundregler. Oprydning ved fejl, idempotens og deterministiske builds skal tænkes ind tidligt.
Snilld-manualen (Snillds perspektiv) peger på de samme praktiske konsekvenser: behov for persistent state, orkestrering, lav latenstid, fejltolerance, skærpet sikkerhed og stærkere observabilitet i multi-agent-miljøer (kilde: Snilld-manualen). Det matcher de tekniske valg, som AWS beskriver i blogindlægget.
Drift og omkostninger — konkrete overvejelser
Prislogikken ændres: MicroVMs er forbrugstakserede, mens Runtime Instances kører som EC2 i kundens konto, hvor Savings Plans og On-Demand Capacity Reservations kan bruges (kilde: AWS-bloggen). Det fordrer kapacitetsplanlægning, GPU-udnyttelsesmonitorering og livscyklusstyring af sessions, der kan leve i op til 14 dage. Sæt alarmer mod glemte sessions.
Blogindlægget giver ingen priseksempler og nævner ikke specifikke EC2-familier eller GPU-typer. Tjek derfor AWS’ dokumentation og prissider for instancer, EBS-typer og IOPS, før I regner TCO. En robust metode er at måle wall-clock pr. trin, GPU-udnyttelse og EBS I/O, og sammenligne med en MicroVM-opsætning med gentagne korte sessioner. Tail-latens og genstartsomkostninger bør med i regnestykket.
Sikkerhed, datastyring og observabilitet
En delt instans øger blast radius. Adskil IAM-roller for agenter, selv når de deler filsystem. Krypter EBS med KMS og stram POSIX-tilladelser, så agenter ikke overskriver hinandens artefakter. Log filadgang og inter-agent-kald, så ændringer kan spores.
Knyt logs, metrics og traces til runtimeSessionId, så hele forløb kan følges og revideres. Snilld-manualen understreger netop de højere krav til observabilitet ved multi-agent-samarbejde. Overvåg også GPU-tilgængelighed, diskplads og fil-locks, og håndter agentfejl med backoff, circuit breakers og idempotente writes.
Performance- og skalerbarhedsspørgsmål
Blogindlægget viser funktionalitet, men ikke I/O- eller latenstal for flere agenter på samme EBS-volume. Det efterlader åbne spørgsmål om p95/p99, især hvis CPU-tunge analyser overlapper GPU-intensive skridt. Perplexity-casen om Photon bruges her kun som illustration af branchens fokus på p99-latenser; den er ikke teknisk relateret til Bedrock Runtime Instances.
GPU-deling er også et punkt at teste selv. Bloggen siger, at Runtime Instances “support GPUs,” men beskriver ikke fordeling mellem flere agenter. Mål scheduling og udnyttelse; overvej at serie-køre GPU-trin og parallellisere CPU-trin. Husk EBS-profilering og evt. provisionerede IOPS, hvis mastering-trin læser/skriver store filer.
Implementeringsguide — tjekliste for teams
Start småt: én Runtime Instance, én GPU, ét EBS-volume. Mål I/O, GPU, CPU og RAM pr. trin, og lad målinger forme designet. Indfør tidligt en simpel orkestrator, der binder alt på runtimeSessionId og kvitterer for artefakter et revisionssikkert sted. Det virker omstændeligt i uge ét, men betaler sig i uge tre.
Artefakter: byg container images deterministisk, pin afhængigheder, og læg store model-/plugin-filer i S3 med versionskontrol. Implementér retry/backoff pr. agenttrin og idempotent skrivning af .wav og metadata, så et retry ikke laver duplikater. Aftal navngivning af mellemprodukter tidligt.
Begrænsninger og risici
Der mangler stadig detaljer i det offentlige materiale: ingen nævnte EC2-familier, GPU-varianter eller priseksempler i blogindlægget; ingen benchmarks for delt EBS under belastning; ingen dyb IAM-guidance for agenter i samme session. Det betyder, at I må teste jeres egen lastprofil grundigt.
Sessions kan leve i op til 14 dage—det er stærkt, men kræver disciplin. Etabler life-cycle policies, auto-stop og notifikationer. Hav en recovery-plan til at flytte en session til en ny instans ved fejl i underlaget og remounte EBS uden datatab.
Hvad læseren bør gøre nu
Vælg et workflow, hvor flere agenter naturligt deler artefakter og kontekst over tid, og byg en fokuseret PoC på Runtime Instances. Brug musikcasen fra AWS som skabelon, men mål alt og læg tallene ind i jeres kapacitets- og TCO-model. Valider, om persistent sessions giver gevinst, eller om MicroVM-bursts stadig er billigst og enklest. Tjek AWS-dokumentationen for aktuelle instancetyper, GPU-tilgængelighed og priser, før I låser arkitekturen.
Planlæg observabiliteten først: log per runtimeSessionId, eksponer GPU-, disk- og latenstids-metrics, og aftal på forhånd, hvem der må læse, skrive og slette på det delte volume.
Kilder og transparens
Primær kilde: AWS-blogindlægget “Build a multi-agent music production pipeline on Amazon Bedrock AgentCore Runtime Instances”, som dækker MicroVMs vs Runtime Instances, sessionvarigheder, GPU-support, persistent EBS, 1:1 vs 1:N hosting, prisrammer og den tre-agent pipeline inkl. citaterne om GPU-brug og delte .wav-filer. Snilld-manualen bruges som perspektiv på praktiske konsekvenser (persistent state, orkestrering, latenstid, sikkerhed og observabilitet). Perplexity/Photon nævnes kun som eksempel på branchens p99-fokus og er ikke direkte relateret til Bedrock Runtime Instances. Hvor blogindlægget ikke angiver instancetyper, GPU-varianter eller priseksempler, er usikkerheder markeret, og læseren henvises til AWS’ dokumentation og prissider.
Bundlinjen: infrastrukturen handler her lige så meget om samarbejde og vedholdenhed som om ren compute. Det mærkes først rigtigt, når flere agenter arbejder på den samme fil over dage.
