AWS Summit Bangkok 2026 Lenke til overskrift

I år fikk jeg holde et foredrag på AWS Summit Bangkok om bygging av multiagentsystemer på AWS.

Lysbildene er tilgjengelige på SlideShare: Building Scalable Multi-Agent AI Systems on AWS Cloud Platform.

Utgangspunktet mitt var enkelt: Nå er alle utviklere. AI-verktøy har gjort det enklere å lage prototyper, demonstrasjoner, interne verktøy, eksperimenter og merkelige helgeprosjekter. Hastigheten er reell, men produksjon er fortsatt vanskelig.

Mange AI-løsninger når fortsatt ikke produksjon fordi det første problemet ikke engang er koden. Det første problemet er å velge hvor man skal begynne. Det finnes for mange verktøy. Alle nye rammeverk ser gode ut, alle IDE-er virker smarte, og alle agentplattformer lover å gjøre jobben. GitHub er i ferd med å bli det nye Instagram: Alle viser skjermbilder, demonstrasjoner og imponerende commits, men det er ikke alltid tydelig hva som faktisk kjører i produksjon.

Derfor styrte jeg foredraget mot ett praktisk svar: Bygg på AWS.

Én løsning: AWS Lenke til overskrift

Historien om AI-utvikling på AWS blir stadig mer sammenhengende.

For agenter finnes Strands Agents. For modeller, orkestrering, kunnskap, rekkverk og administrerte AI-funksjoner finnes Amazon Bedrock. For utviklerarbeidsflyten finnes Kiro IDE. Sammen gir de utviklere en tydelig vei fra idé til et fungerende system.

Det viktige er ikke bare at verktøyene finnes, men at de passer sammen.

Du kan bygge raskere fordi delene henger sammen. Dataene kan bli i ditt eget miljø. Tilgang kan styres med AWS-kontrollene selskapet allerede forstår. Kostnadene er synlige på ett sted. For mange selskaper betyr dette mer enn å bruke forrige ukes nyeste rammeverk.

AI-utvikling har allerede nok usikkerhet. Plattformen bør fjerne noe av denne usikkerheten, ikke tilføre mer.

Multiagentsystemer Lenke til overskrift

Min første anbefaling var:

Et team av spesialister er bedre enn én generalist.

Én stor agent med én enorm prompt kan virke attraktiv i starten. Det føles enkelt. Når systemet vokser, blir det imidlertid vanskelig å forstå hvorfor agenten tok en beslutning, brukte et verktøy eller ignorerte en instruksjon.

Multiagentsystemer fungerer bedre når hver agent har en reell rolle:

  • ulike mål
  • ulike verktøy
  • ulik kontekst
  • ulike suksesskriterier

Det ligner et ekte team. Du vil ikke ha fem personer med samme ansvar. Du vil at én skal eie sikkerhet, én leveranser, én data, én kodegjennomgang og én koordinering.

Det samme gjelder AI-agenter.

En advarsel: AI er svært målorientert. Den kan være dårlig til å forstå forskjellen mellom systemets globale mål og det personlige målet til én agent.

Hvis det globale målet er «lever funksjonen sikkert», mens én agent bare har målet «få testene til å passere», kan den optimalisere for feil ting. Den kan fjerne en test, hoppe over et valideringstrinn eller gjøre den minste lokale endringen som skjuler det egentlige problemet.

Hver agent trenger derfor et smalt mål, samtidig som systemet må ha et tydelig globalt mål.

Verktøy slår regler i prompter Lenke til overskrift

Min andre anbefaling var:

API-, CLI- og MCP-verktøy er bedre enn instruksjoner som «vær så snill, ikke gjør dette» og «DU MÅ IKKE».

Agenter må kunne handle. Gir vi dem bare tekstinstruksjoner, forventer vi at modellen husker reglene og oppfører seg perfekt. Det er skjørt.

Gi agenten et leveranseverktøy hvis den skal levere. Gi den en skrivebeskyttet CLI-kommando hvis den skal inspisere infrastruktur. Eksponer et lite API eller en MCP-server hvis den skal arbeide med et internt system. Selv en CLI med en god --help-kommando og en kort ferdighetsfil kan være langt sterkere enn en lang prompt.

Promptjustering har verdi, men er ikke et kontrollplan.

Et bedre mønster er:

  • gi agenten tydelige verktøy
  • avgrens verktøyene
  • gjør verktøybruken observerbar
  • gjør farlige handlinger eksplisitte
  • la agenten lese hjelpetekst og lære arbeidsflyten

Dette er langt mer pålitelig enn å prøve å skrive den perfekte setningen i systemprompten og håpe at modellen følger den for alltid.

Kontekst er ikke valgfritt Lenke til overskrift

Min tredje anbefaling var:

Uten kunnskap og historikk starter AI fra bunnen hver gang.

Dette er et av de største hullene i dagens agentbaserte systemer.

En menneskelig ingeniør starter ikke på null hver morgen. Vedkommende husker hvorfor systemet er bygget slik, at autentiseringslaget ble endret i fjor, hvilken RDS-instans som tilhører hvilken arbeidslast, og produksjonshendelsen som førte til et merkelig rekkverk.

AI-agenter husker vanligvis ingenting av dette med mindre vi bygger et kontekstlag for dem.

Dette var hoveddemonstrasjonen i foredraget: en Slack-bot koblet til et kunnskapslag for AI-agenter, med kontekst fra AWS, GitHub og Slack.

Ideen er praktisk:

  • Er du lei av at AI må skanne hele AWS-miljøet bare for å finne riktig RDS-instans?
  • Er du en utvikler som har glemt hvordan autentisering ble implementert for ett år siden?
  • Er du sikkerhetsleder og vil vite om en ny CVE påvirker selskapet?

Her blir et kunnskapslag nyttig. Det gir agentene hukommelse, selskapskontekst og mulighet til å svare med miljøet i tankene.

Etter ett års utvikling har vi nå en testarena for ideen. Det er ikke magi, men fortsatt utviklingsarbeid. Den viser likevel hva som blir mulig når agenter har kontekst, ikke bare en prompt.

Bygg parallelt Lenke til overskrift

Et annet poeng var at AI endrer hvordan vi bygger.

Med nok struktur er det mulig å bygge flere systemer parallelt. Ikke perfekt og ikke uten gjennomgang, men raskere enn før.

Et av hobbyprosjektene mine er en Personal Private Notetaker.

Målet er enkelt: Jeg vil fange opp hva jeg lover andre, følge det opp bedre og delegere oppfølgingsarbeid til andre AI-agenter. Jeg liker heller ikke at jeg, selv med en Mac Pro på skrivebordet, ofte må sende stemmen til et datasenter et sted bare for å få en transkripsjon tilbake.

Lokalt orientert AI handler for meg ikke bare om personvern, men også om kontroll, forsinkelse og tillit. Noen arbeidsflyter bør forbli nær maskinen og personen.

Viktigste råd til AI-utviklere Lenke til overskrift

AI gir hastighet, men hastighet skaper distraksjoner.

Utviklere trenger derfor fokus. Avgrensning er viktigere enn noen gang. Når én ingeniør kan generere enorme mengder kode, tokens, infrastrukturendringer og pull requests, blir teknisk disiplin viktigere, ikke mindre.

Det grunnleggende vinner fortsatt:

  • kontrollerte leveranser
  • tydelig eierskap
  • rekkverk
  • kostnadsovervåking
  • observerbarhet
  • leveransedisiplin

Multiagentsystemer er kraftige, men kan også bli det nye mikrotjenesteproblemet. Ikke lag for mange agenter bare fordi det er mulig. Opprett en agent når rollen, verktøysettet og målet er tilstrekkelig forskjellige til å forsvare en egen spesialist.

Om konferansen Lenke til overskrift

AWS Summit Bangkok var bra, og det var fullt. Det var mange deltakere i år, noe som er et godt signal for det lokale sky- og AI-miljøet.

Developer Lounge var perfekt. I år hadde vi nytt utstyr, noe som ga en smidigere opplevelse for foredragsholderne og gjorde demonstrasjonene enklere å kjøre.

Jeg la også merke til mer spillifisering på konferansen. Mange stands var faktiske spill, og noen var bygget med Kiro. Deltakerne kunne legge til egne funksjoner under konferansen, noe som gjorde opplevelsen morsommere og mer praktisk.

Det er trolig riktig retning. AI-verktøy er lettere å forstå når folk kan bygge noe med dem, ikke bare se lysbilder om dem.

Jeg legger til bilder fra arrangementet senere når jeg mottar dem.

Hovedbudskapet er foreløpig dette:

AI-utviklere trenger mindre støy, bedre verktøy, mer kontekst og sterkere teknisk disiplin. AWS er et solid sted å samle disse delene.