AWS viser en færdig opskrift på en multimodal WhatsApp-ordrestøtte, hvor Amazon Bedrock AgentCore og Nova 2 håndterer samtalen på tværs af tekst, voice notes og opkald. På overfladen ser det simpelt ud; under motorhjelmen er der en del mekanik. Arkitekturen er dog jordnær og peger på en reel migrationsvej for virksomheder, der i dag kæmper med separate systemer for app, web, telefon og skranke.
Hvad AWS faktisk viser
Demoen bruger Meta WhatsApp Business Platform som kundevendt indgang med Cloud API webhook samt Messages, Media og Calling API’er. AWS skriver eksplicit: “The customer front door is the Meta WhatsApp Business Platform. It exposes the Cloud API webhook, Messages API, Media API, and Calling API. Meta manages this service.” Med andre ord: Meta styrer platform-laget, mens AWS-arkitekturen tager over på serversiden.
På modelsiden deles ansvaret: “Amazon Nova 2 Lite handles text through the Amazon Bedrock Converse API, and Amazon Nova 2 Sonic handles real-time speech on voice notes and calls.” Agentlogikken hostes på Amazon Bedrock AgentCore: “Amazon Bedrock AgentCore hosts the agents.” Og forbindelsen til restaurantens backend løber via Model Context Protocol (MCP) gennem AgentCore Gateway.
En WhatsApp-tragt med tre agent-runtimes
Løsningen er skåret i tre lag, og det er ikke kun for pænhedens skyld. AWS beskriver designet sådan: “the design keeps three things apart: (1) the WhatsApp layer handles the conversation, (2) three agent runtimes run the conversations for their channels, and (3) the backend holds the menu, carts, orders, and locations.” De tre runtimes matcher kanalerne: tekst, voice note og real-time call.
Flowet er stramt: Indgående trafik lander på én HTTPS webhook og “is acknowledged with a 200 immediately, and then processed asynchronously so no request blocks the response.” Det er et klassisk mønster, fint operationaliseret til messaging. Det aflaster spidsbelastning, men kræver disciplin i køer, idempotens og retries.
Hvorfor det er relevant i praksis
WhatsApp er stor. AWS skriver, at “WhatsApp reaches more than two billion people.” Sådanne tal stammer typisk fra WhatsApp\/Metas egen kommunikation; de er verificerbare som størrelsesangivelse, men bør krydscheckes mod Metas seneste officielle rapporter ved endeligt faktatjek. Pointen er dog klar: kundernes samtaler foregår allerede i beskedtjenesterne, så det er strategisk klogt at flytte ordering dertil.
Teknisk snapshot af komponenterne
AWS lister de konkrete byggesten, som CDK provisionerer på serversiden: Amazon API Gateway (én offentlig regional HTTPS webhook + en IAM-beskyttet backend-API), AWS Lambda til ingest, worker, sender og forretningslogik, Amazon SQS til inbound-kø og dead-letter-kø, samt Bedrock AgentCore runtime til de tre agenter. Hver samtale kører i egen microVM for isolation.
På datalaget ligger Amazon DynamoDB til profiler, ordrer, menuer, kurve og lokationer; Amazon Location Service til geokodning og nærmeste lokation; Amazon Kinesis Video Streams til signalering i call-runtimen og adgang til den managed TURN-relay; og et Amazon VPC-setup med NAT gateway som udgående vej for call-runtimen. En konkret liste – ikke bare hype.
WhatsApp-laget og Meta som frontdør
Det er vigtigt at forstå ansvarsgrænserne. Meta styrer WhatsApp-platformen, API’erne og registreringen. AWS understreger, at opsætning hos Meta er en forudsætning: “You set it up and connect it as a prerequisite, not something this solution deploys.” AWS CDK leverer alt på AWS-siden, herunder selve webhook-URL’en, som man registrerer hos Meta.
Konsekvensen er praktisk: compliance, rate limits, webhook-registrering og eventuelle platformændringer dikteres af Meta. Det giver mindre kontrol over frontenden, men til gengæld adgang til brugernes foretrukne kanal. For drift kræver det tydelige playbooks for fejlhåndtering på tværs af to leverandører.
Asynkron webhook-design i praksis
Mønstret med at sende et øjeblikkeligt HTTP 200-svar og derefter skubbe payloaden ind i SQS før Lambda-processering er velafprøvet. Fordelen er, at indgangen ikke blokerer, og at backpressure kan håndteres ved at skalere workers eller styre concurrency. Ulempen er kompleksitet i observability og fejlsøgning, hvis man ikke investerer i korrelation, dead-letter-review og målrettede alarmer.
Den praktiske opskrift bør inkludere: strukturerede id’er på tværs af inbound\/outbound, idempotent business logic, traktmålinger for hver kanal og klare retry-politikker. Det lyder som driftsdetaljer, men det er forskellen på en pæn demo og noget, der kører kl. 18.07 en fredag.
Multimodal tale i to varianter
AWS adskiller rollerne: Nova 2 Lite via Bedrock Converse API til tekst, og Nova 2 Sonic til real-time speech for voice notes og opkald. Det rejser naturlige spørgsmål om latency, kvalitet over svage forbindelser og håndtering af baggrundsstøj i voice notes. Blogindlægget giver ikke tal på round-trip-tider eller samtalekapacitet per agent-runtime. Det bør testes før bred udrulning.
Real-time tale kræver særskilt overvågning: jitter, dropout, timeout-håndtering og en forståelig fallback, hvis samtalen mister strømmen. En lavpraktisk løsning er automatisk overgang til tekst, hvis kaldet ikke kan opretholdes. Ikke elegant, men bedre end stilhed.
Én backend, én cross-channel hukommelse
Arkitekturen lover, at tekst, voice notes og opkald deler hukommelse. AWS skriver: “All three channels share one backend and one cross-channel memory.” Og konkretiserer nøglingen: “AgentCore memory… is one shared, cross-channel record keyed by a hashed customer ID.” Plus sætningen, mange har ventet på: “A customer who texts today and calls tomorrow is recognized as the same person.”
Det efterlader åbne spørgsmål: Hvordan matches identiteten på tværs af kanaler i praksis? Er telefonnummeret den primære nøgle, eller ligger der et særskilt identitetslag med tokenisering og samtykke? Hvad med sessions kontra vedvarende profiler, dataretention pr. modalitet og GDPR-krav til voice? Det er arbejde, der skal præciseres.
Fejl, kanter og menneskelig fallback
Der vil være misforståelser i samtaler. Brugere, der skifter sprog, eller en halv ordre, der aldrig blev bekræftet. Og platformfejl hos Meta. Derfor bør der bygges eksplicit fallback til menneskelig betjening og klare stier for betalinger, der fejler på backend. En praktisk leveregel: enhver state skal kunne genoptages af en medarbejder med ét klik – og kunden skal kunne se, hvor langt ordren er.
Edge cases som dobbelte voice notes, race conditions mellem call og tekst fra samme bruger, eller en billedmenu der ikke matcher lagerstatus, er ikke teoretiske. De sker. God observability og solide testscenarier gør forskellen fra driftspanik til håndterbar støj.
Omkostninger og skalering
Blogindlægget giver ikke priseksempler. En fornuftig estimering bør inkludere: Bedrock-kald til Nova 2 Lite og Sonic, AgentCore runtime (inklusive microVM-isolation), Lambda-kørsel, SQS, API Gateway, eventuelle udgående medieomkostninger, KVS\/TURN for opkald og WhatsApp-omkostninger. Det afgørende målepunkt er cost per completed order. Dernæst latency fra første besked til bekræftelse samt error-rate pr. kanal.
Skalering er mere end flere Lambdas. Real-time opkald fordrer kapacitetsgrænser for Sonic og KVS\/TURN. Uden offentlige tal må man køre en målt pilot med kendt peak – f.eks. 17.30–19.30 – og bygge auto-skalering og køprioritering derefter.
Compliance og persondata
Der er en checkliste, som ikke kan springes over: dokumenteret behandlingsgrundlag, eksplicitte opt-ins hvor påkrævet, nem opt-out, dataminimering, kryptering i transit og hvile, datapolitik for voice (er optagelser gemt, hvor længe og til hvad), og auditlogs for MCP-kald, så man kan spore beslutninger. Husk også dataportabilitet: kan kunden få sin ordrehistorik ud i et læsbart format uden kamp.
WhatsApp-laget ejes og drives af Meta. Det betyder, at dataflow og leverandøraftaler skal vurderes særskilt, inkl. eventuelle overførsler uden for EU. Ikke glamourøst – men nødvendigt.
Åbne tekniske spørgsmål
Der er flere punkter, som kalder på opfølgende research eller direkte afklaring med AWS\/Meta:
- Latency og throughput for Nova 2 Sonic og AgentCore ved real-time opkald. Ingen officielle tal i blogindlægget.
- Identitetsmatch og sessionisering på tværs af kanaler: telefonnummer som nøgle, hashed ID eller dedikeret identitetslag – hvad er referenceimplementeringen?
- Dataretention, kryptering og håndtering af voice recordings i relation til GDPR og eventuel kundesamtykke pr. modalitet.
- Fejlscenarier på Meta-siden: rate limits, SLA’er, platformændringer og politik for massebeskeder.
- Omkostningsmodel for Bedrock\/AgentCore og real-time Sonic – herunder peak-kapacitet ved middagsspidser.
- Race-conditions mellem tekst og opkald fra samme bruger og design for konsistens i kurv og ordrehistorik.
Fra demo til drift
Vejen fra arkitekturskitse til PoC kan være kort, hvis man holder sig til standardkomponenterne. AWS skriver, at “You deploy the whole system with the AWS Cloud Development Kit (AWS CDK).” Det bør ses som verificerbart for AWS-delen. Men Meta-opsætningen – webhook-registrering m.m. – er uden for CDK og kræver manuel konfiguration hos Meta. Planlæg tid til det.
HyperPod\/Agent Ops får en kort note som sekundært perspektiv: AWS har beskrevet en åben styringsflade til hurtig igangsættelse af agentmiljøer oven på EKS og SageMaker HyperPod. Det kan være relevant som orchestration-lag for større driftsmiljøer, men er ikke en del af WhatsApp-demoens kernearkitektur og bør vurderes separat på modenhed og timing.
Hvad virksomheder bør gøre nu
En pragmatisk PoC-plan kan være tre trin. Først en fokuseret workshop, hvor brugerrejser, POS\/ERP-integration, samtykker og mål for succes fastlægges. Dernæst en prototype med én by, ét menukort, et begrænset tidsvindue – og en lille testgruppe. Til sidst et målingsregime, der følger latency, fuldførte ordrer, fejltyper og cost per order, samt en klar fallback til mennesker.
Rollen for samtaledesign må ikke undervurderes. Små vendinger kan afgøre, om ordrer bliver komplette. To-tre varianter af bekræftelsesprompter og tydelige afbrydelser ved misforståelser gør forskellen. Ikke tusind varianter – de rigtige.
Eksempel på rollout og ansvar
En typisk quick-service-udrulning kan se sådan ud: 6–8 ugers PoC. Uge 1–2 krav og arkitektur, uge 3–4 backend-integration og testdata, uge 5–6 samtaledesign og voice tuning, uge 7 pilotdrift med overvågning, uge 8 evaluering og go\/no-go. Ansvar fordeles sådan: platformteam på AWS-ressourcer og observability, integrationsfolk på POS\/ERP, produktteam på samtaledesign og KPI’er, legal på databehandleraftaler og politikker.
Milepæle, der betyder noget: webhook-verifikation hos Meta, første end-to-end-ordre med kvittering, første voice note med korrekte intents, første real-time-call uden dropout, første menneskelig overtagelse fra en svær samtale. Små skridt, stor organisatorisk effekt.
Konklusion
AWS har lagt et detaljeret blueprint frem for, hvordan en multimodal WhatsApp-ordrestøtte kan samles med Bedrock AgentCore og Nova 2 – ned til webhook, SQS, Lambda og MCP. Bevisbyrden på latency, pris og identitetsmatch står tilbage, men arkitekturen er anvendelig, hvis man ved, hvor hullerne er.
Checkliste før pilot
- Webhook og Meta-opsætning verificeret, inkl. Cloud API, Messages\/Media\/Calling.
- Identity mapping og cross-channel memory-design dokumenteret og testet.
- SQS-baseret async-design med idempotens, DLQ og alarmer på plads.
- Observability: korrelations-id’er, tracing, særskilt voice\/RTT-metrik.
- Fallback til mennesker, inkl. genoptagelse af ordrestate og klare procedurer.
- Cost-model og budget for Nova 2 Lite\/Sonic, AgentCore, KVS\/TURN og WhatsApp.
- Compliance: samtykker, retention pr. modalitet, kryptering og databehandleraftaler.
- Aftalt driftsmodel og kontaktpunkter for fejl hos Meta og hos AWS.
