Lad os være ærlige. Hvis du nogensinde har forsøgt at bygge en agentisk AI‑app, så ved du, at det ikke er modellen, der spiser tiden. Det er alt det udenom: orchestrering af API‑kald, samtalestyring og at få en agent til at ræsonnere uden at køre i ring. AWS’ seneste gennemgang af Strands Agents rammer netop den pointe og viser et eksempel på en fungerende research‑assistent skrevet på omkring 30 linjer kode. Det er ikke varm luft, men det er heller ikke en genvej uden sving.
Hvorfor betyder det noget for danske virksomheder lige nu? Fordi det flytter en stor del af kompleksiteten væk fra tung ML‑forskning og over i værktøjer, som softwareteams allerede kender. Prototyperne går stærkt — det mærker vi selv i projekter. Men der mangler en nøgtern snak om, hvad der skal til for at få sådan en assistent i produktion uden natsværmeri i pager‑duty.
Problemet som det faktisk ser ud i praksis
AWS beskriver præcist, at det tidskrævende arbejde er at orkestrere mange API‑kald, holde styr på samtalestatus og bygge agenter, der kan ræsonnere. Det matcher vores erfaring én til én: simple ideer vokser, når state skal bevares robust, og når værktøjer (tools) skal kaldes deterministisk med ordentlige timeouts. Timer ryger på fejl, retrier og idempotens i integrationer, som ellers lød helt enkle i mødelokalet. Det er ikke et problem ved “AI” — det er klassisk software med nye kanter.
De fleste smerter handler mindre om “intelligens” og mere om disciplin: logging, versionsstyring af prompts og policies, og en klar kontrakt for hvert tool. Vi havde for nylig en prototype, der kørte fint på testdata, men væltede i drift, fordi et eksternt API sporadisk svarede langsomt, og agenten eskalerede kald i stedet for at bakke ud. Fire ugers ekstra ingeniørarbejde — primært timeouts og strammere planlægning — før den var stabil nok. Det ligner ikke 30 linjer. Det er håndværk.
Hvad Strands Agents egentlig gør
Strands Agents er et open source‑framework i Python, der kombinerer LLM’er med brugerdefineret logik og API’er via en enkel @tool‑dekorator. Pointen er model‑drevet planlægning frem for hårdkodet styring: du beskriver mål og værktøjer, og modellen orkestrerer. AWS fremhæver, at Strands kan køre alt fra enkeltagenter til hierarkiske multi‑agentsystemer, og at det er modelagnostisk på tværs af Bedrock, Anthropic og OpenAI. Arkitekturen er fleksibel — og det betyder, at governance og test også skal være det.
I AWS‑miljøer passer Strands naturligt sammen med Bedrock og Lambda. Blogindlægget hævder også, at Strands allerede bruges i Amazon Q og AWS Glue, og at samme kode kører lokalt og i produktion. Vi noterer det som en stærk indikation, men uden tredjeparts‑cases er det stadig en leverandørpåstand. Giv den vægt — men bed også om dokumentation, hvis den skal bære et budget.
Kiro og Powers i udviklerens hverdag
Kiro er en AI‑drevet IDE, der forsøger at lægge ingeniørdisciplin ind i agentudvikling. Værktøjet oversætter naturlige prompts til strukturerede krav og acceptance‑kriterier og læner sig op ad spec‑drevet udvikling. “Powers” udvider IDE’en med genbrugelige enheder, der pakker MCP‑servers, steering‑filer og hooks, så man får on‑demand evner direkte i værktøjet. Mindre frihåndsprompting, mere bevidst styring.
Strands‑Power’en i Kiro bundler SDK‑dokumentation, getting‑started guides og korrekte API‑mønstre, så Kiro kan scaffolde agenter mere præcist. Ifølge AWS findes der over 50 kuraterede Powers fra AWS, partnere og community, der dækker design, deployment, sikkerhed og observability og kan installeres med ét klik. Det er en god startpakke, men vi mangler en uafhængig, opdateret liste og et kvalitetsstempel pr. Power. Hurtig installation er ikke nok — opdatering og afvikling skal også være sikre.
Hvor Bedrock og modelvalget passer ind
Amazon Bedrock leverer adgang til foundation‑modellerne, der driver agenternes planlægning og sprogforståelse. Bekvemmeligheden kan være afgørende i regulerede miljøer, hvor datalokation og audit betyder noget. Men “modelagnostisk” er ikke “modelløs”: valget mellem Bedrock, Anthropic og OpenAI påvirker latenstid, pris og efterlevelse. Vi har set det variere markant på tværs af kunder — forskelle i tokenpriser og svartider ændrer hele omkostningsprofilen, når en agent tager fem skridt i stedet for ét.
En driftrealitet: opdateringer af modelversioner kan skifte agentadfærd, fordi planlægningsstrategier og tool‑kald ændrer sig subtilt. Teststrategien bør ligne API‑kontrakter — blot med sprogmodeller som usikre partnere. Ikke romantisk, men effektivt.
30 linjer kode der virker — hvor langt rækker det
AWS’ eksempel med en research‑assistent på cirka 30 linjer kode er stærkt som scaffold. Det viser, at Strands’ abstraktion kan få idé til demo hurtigt og nogenlunde smertefrit. Men lad os kalde en skovl for en skovl: 30 linjer er ikke en produktionsapp med auth, observability, feature‑flags, rollbacks og cost‑kontrol. Vi har selv bygget noget lignende som intern øvelse — prototypen sad i skabet dag to. Derefter fulgte fire uger med fejlhåndtering, rate‑limits og datapolitikker, før vi ville lade det røre kundedata.
Det gør ikke demoen mindre værd. Tværtimod. Den korte vej til en kørende assistent ændrer samtalen i organisationen: man evaluerer use‑casen på rigtige interaktioner i stedet for slides. Pointen er blot, at tempoet i starten ikke må snyde. De langsomme uger kommer, hvis appen skal bære kritiske processer.
Tre konsekvenser for implementering
Arkitektur først. Når LLM’en planlægger, flytter vi kompleksitet fra hårdkodning til tool‑indramning: hver integration skal være idempotent, have skarpe timeouts og tydelig input‑/output‑validering. En lille fejl i et tool kan forplante sig til fem mislykkede kald, fordi agenten prøver igen i god tro. En circuit breaker for agentplanlægning lyder kedeligt, men sparer penge.
State og observability. Samtalelogik og agentplaner skal kunne forklares og revideres — for fejlfinding og governance. Gem mellemtrin, ikke kun slut‑svar. Log hvilke værktøjer der blev foreslået, hvilke der blev brugt, og hvorfor modellen skiftede spor. Vi var engang sikre på, at en underlig svarserie skyldtes modellen, indtil vi fandt en race condition i vores state‑lagring. Den tog en eftermiddag og et par meget sorte kaffe at lokalisere, fordi vores telemetri var for grovkornet.
Omkostninger i drift. En agent er sjældent ét prompt og ét svar, men en lille proces med flere iterationer og tool‑kald. Det fordobler eller tredobler hurtigt tokenforbruget. Læg observability, tracing og ekstra validering oveni — regningen vokser. Budgettér på “worst credible path” i stedet for “happy path”, ellers sprænger PnL’en, når trafikken bliver ægte.
Risici og begrænsninger man ikke bør undervurdere
Data‑governance. Når agenter får adgang til interne API’er og dokumenter, skal datamaskering, scopes og auditering være på plads fra dag ét. Det er fristende at køre fri adgang i et lukket POC‑miljø, men vaner sætter sig. En simpel regel virker: mindst mulige permissions pr. tool, og alle kald logges med formål og input‑hash. Det er ekstra arbejde — og det betaler sig.
Sikkerhed. Tool‑kald er i praksis eksterne handlinger udløst af modeltekst. Det kræver input‑sanitering, signering af kritiske kald og ofte menneskelig bekræftelse på destruktive handlinger. En kunde glemte i første iteration at sætte upper bounds på scripts, som agenten kunne afvikle via et dev‑værktøj. Det holdt, indtil det ikke gjorde. Ingen data gik tabt, men vi fik respekt for guardrails den dag.
Hvad vi gør i Snilld, når vi bygger sådan noget
Vi holder forløb korte og skarpt afgrænsede: to dages discovery til use‑case, en uges prototype med Strands og Kiro, og cirka fire ugers hardening og governance, hvis prototypen giver mening. Den rytme gør det nemmere at sige stop — eller gå videre med ro i maven. Uden pynt: 60–70 procent af tiden går på driftssikring, ikke på modelvalg.
Vi lægger også små regler ind. Eksempel: time‑boxed retries pr. tool, så agenten ikke blæser budgettet på gentagne kald. Og alle prompts og policies versioneres som kode, så audit og rollback er trivielle. Når en ny modelversion ændrer adfærd en mandag morgen, vil du kunne rulle tilbage før frokost.
En praktisk tjekliste for de første 90 dage
Start smalt med en research‑assistent og definér klare succeskriterier: hvilke kilder må den bruge, hvilke svarformater accepteres, og hvordan måles kvalitet. Sæt Strands op med 2–3 velafprøvede tools og hold resten ude, indtil de er tjekket for idempotens, timeouts og fejlscenarier. Kobl til Bedrock eller et andet modelvalg og mål latenstid og pris på rigtige flows — ikke kun én prompt. Og vigtigst: få observability på plads fra dag ét. Uden sporbarhed bliver fejlfinding gætværk.
Dernæst de kedelige ting, der gør en forskel i virkeligheden: rollebaseret adgang, maskering af potentielt følsomme felter og manuel godkendelse på handlinger med risiko. Afslut perioden med en kaosdag, hvor I tvinger API‑fejl, langsomme svar og timeouts for at se, om agenten holder kursen. Ikke elegant — men ærligt.
Modargumenter og konkurrence i værktøjsbunken
Nogle vil sige, at fuldt custom kode uden agent‑frameworks er mere kontrollerbart og billigere på sigt. Måske — hvis domænet er smalt og kravene stive. Vores erfaring er, at frameworks som Strands hurtigere finder en retning, der virker, og at du så kan stramme skruerne med tests og policies. Andre peger på alternative agent‑SDK’er, der også løser planlægning og tool‑kald. Fair nok — men uanset valg ender arbejdet i de samme grunddiscipliner: governance, observability og økonomi.
Man hører også, at 30‑linjers eksempler er marketing. Det er en skæv kritik. Eksemplerne er prototyper — og det er pointen. De bliver først til marketing, når man glemmer at fortælle, hvad der skal ovenpå for at komme i produktion. Her står AWS‑posten stærkt på hurtig værdi og svagt på driftsdetaljer — som vi adresserer ovenfor.
Kildekritik og de åbne spørgsmål
Vi har verificeret de centrale påstande i AWS’ indlæg: komplekse AI‑apps skyldes orchestrering, state og agentlogik; Strands + AWS blev brugt til en research‑assistent på cirka 30 linjer; Kiro‑Powers pakker MCP‑servers, steering‑filer og hooks; Strands‑Power’en løfter dokumentation og API‑mønstre ind i IDE’en; der findes over 50 kuraterede Powers. Det står eksplicit i blogindlægget og på Kiro’s site.
Tre områder kræver mere lys. For det første: definitionen af “30 linjer” — tæller imports og config, og kan vi se koden i et repo. For det andet: produktionsbrug i Amazon Q og Glue — vi mangler uafhængige cases med tal for oppetid, omkostninger og fejltyper. For det tredje: en klar cost‑model for agentiske workloads på Bedrock, når planlægning går i flere trin. Interviews med AWS‑teams eller offentlig dokumentation er næste skridt, før CFO’en får ja.
Vores konklusion efter at have bygget det i praksis
Strands Agents og Kiro gør idé til demo markant hurtigere. Det er rigtigt, praktisk og brugbart. I produktion er succesen dog stadig et spørgsmål om ingeniørarbejde: arkitektur, test, logging og disciplin omkring tools. Går du ind i det med de briller, er gevinsten reel — især for research‑ og analyseopgaver, hvor agenten må tage et par skridt selv. Forventer du, at 30 linjer er hele historien, bliver du skuffet, når første nat går skævt, og ingen kan forklare hvorfor.
Vi blev faktisk overrasket over, hvor hurtigt vi kunne få noget, der mindede om værdi, op at køre — og lige så hurtigt mindet om, at governance og observability ikke er tilkøb. Det er fundamentet. Her rammer AWS tonen: hurtig start, ingen tryllestav. Resten er håndværk.
Kilder og videre læsning
Primær kilde: AWS’ blogpost om at bygge en research‑assistent med Strands. Den dokumenterer de tekniske påstande og rummer både forudsætninger og IAM‑eksempler til Bedrock‑adgang. Supplerende kilde: Kiro’s hjemmeside, der forklarer spec‑drevet udvikling, Powers og hvordan IDE’en styrer fra krav til kode. Vores interne erfaring er brugt som baggrundsforståelse til at skærpe relevans for drift og governance, ikke som ekstern dokumentation. Der er åbne spørgsmål om cost‑modeller, uafhængige produktionscases og en opdateret, verificeret liste over Powers.
Kogt ned til én sætning: Brug Strands og Kiro til at komme hurtigt i gang — men planlæg fra dag nul for det upoetiske: timeouts, logging, test og penge. Ja, research‑assistenten kan faktisk bygges i nærheden af 30 linjer. Den kan bare ikke driftes der.
