Amazon har gjort Web Search i Bedrock AgentCore generelt tilgængelig, ifølge AWS’ egen produktblog (ifølge AWS’ blog, kilde). Det er en forvaltet, MCP‑kompatibel web‑søgeconnector, som lader agenter hente opdateret webindhold uden at styre eksterne søge‑API’er, nøgler eller parsing (ifølge AWS’ blog, kilde). Bekvemt i opsætning. Den reelle værdi afgøres i drift.
Baggrunden er velkendt: agenter, der kun bygger på træningsdata, har frosset viden og svarer usikkert, når verden flytter sig (ifølge AWS’ blog, kilde). Et web‑ben, der kan levere friske kilder, er derfor tæt på et krav i produktion. Punktum — resten må måles.
Hvad er Web Search på AgentCore
Ifølge AWS er Web Search en fuldt forvaltet, MCP‑kompatibel kapacitet, eksponeret som managed target eller connector, som bindes på AgentCore Gateway. Agenter opdager værktøjet via et standard tools/list‑kald og invokerer det som andre MCP‑værktøjer (ifølge AWS’ blog og Gateway‑dokumentationen, kilder). Ingen tredjepartsnøgler. Ingen sær‑SDK. Ingen skrøbelig scraping.
Gateway‑laget fungerer som et samlet indgangspunkt og kan omforme eksisterende API’er, Lambda‑funktioner og tjenester til MCP‑værktøjer samt håndtere routing og styring (ifølge Gateway‑dokumentationen, kilde). Det er netop den centralisering, mange enterprise‑teams efterspørger, når der skal holdes styr på adgang og drift.
Under motorhjelmen
Kernen er et særbygget webindeks, som Amazon driver. Bloggen angiver “tens of billions” af dokumenter (vendor‑angivet, ifølge AWS’ blog, kilde). Dækningen bør testes op mod eget domæne, før man låser arkitekturen.
AWS skriver også, at indekset opdateres løbende, så nyt indhold kan dukke op inden for minutter (vendor‑angivet, ifølge AWS’ blog, kilde). Det er let at efterprøve: kør queries mod nypublicerede sider med kendte tidsstempler og mål time‑to‑first‑snippet.
Snippets, knowledge graph og modelkontekst
Retrieval kan kombinere et knowledge graph til højkonfidens‑fakta og semantisk snippet‑ekstraktion optimeret til modelkontekst (ifølge AWS’ blog, kilde). Ambitionen er færre tokens og mindre støj ind i modellen. I praksis tæller kun én ting: rammer snippets den sætning, der bærer svaret, ofte nok til at mindske fejl?
Det kan måles nøgternt i en pilot: tjek, om citationsleddet peger på præcis den sætning, der underbygger svaret, og hvor tit det sker. Ingen store ord her, bare tal.
Sikkerhed og gateway‑styring
AWS beskriver en privatlivsmodel, hvor forespørgsler bliver i AWS (ifølge AWS’ blog, kilde). Gatewayen står som frontdør med IAM eller JWT til indgående auth og håndterer også egress‑autentificering (ifølge Gateway‑dokumentationen, kilde). Det gør compliance‑historien pænere på papiret og enklere at dokumentere.
For drift giver gateway‑mønstret en rute at inspicere, logge og revidere. Dokumentationen beskriver værktøjsmodellen, targets og styringsregler (ifølge Gateway‑dokumentationen, kilde). Spørgsmålet er, hvor dyb og eksportérbar logningen er, og hvordan retention styres — det er typisk det, revisor spørger om først.
Når “private within AWS” kan have kanter
Dyk ned i undtagelserne, før produktion: cross‑account adgang, multi‑region topologier, VPC‑endpoints og værktøjskæder der rører eksterne HTTP‑targets via Gateway. Få skriftlige svar på:
- Konti og regioner: Hvilke konti og regioner behandler queries og resultater, og kan det låses til et sæt regioner?
- Egress‑kontrol: Hvordan dokumenteres og håndhæves egress, når et flow kalder både Web Search og eksterne targets?
- Audit og eksport: Hvilke felter findes i request/response‑spor pr. forespørgsel (tid, bruger, værktøj, kilde‑URL), og kan logs eksporteres uændret til eget SIEM?
- Retention: Hvilke retention‑perioder gælder som standard, og kan kunden styre sletning pr. gateway/projekt?
Fire konsekvenser for projekter
1) Lavere infrastrukturbyrde. Ingen nøgle‑rotation til tredjeparts søge‑API’er, ingen hjemmestrikket HTML‑parser, ingen vedligehold når resultatformater ændres (ifølge AWS’ blog, kilde). Praktisk: fjern en separat søgeservice, lad Gateway eksponere web‑værktøjet, men indsæt et mellemled til validering og caching.
2) Afhængighed af Amazons indeks. Dækning, crawl‑politik og rangering er ikke fuldt transparente. Man bytter kontrol for enkelhed. Praktisk: definér SLO’er for dækning og relevans i jeres domæne, mål dem løbende og supplér med egne kilder eller specialiserede API’er, når der opstår blinde vinkler.
Pris, throttling og kontrol
3) Økonomi og kvoter. Blogindlægget oplyser ikke en klar prisstruktur eller throttling‑grænser (ifølge AWS’ blog, kilde). Praktisk: få skriftlig pris‑ og kvoteafklaring, sæt alarmer på kald‑rate og latens, og byg fallback, hvis søgning begrænses eller fejler midlertidigt.
4) Behov for verifikation. Et stort indeks og smarte snippets erstatter ikke kildetjek. Praktisk: implementér citationslag med kilde‑URL’er og passager i svaret samt en let “er det rigtigt”‑feedback i UI. Gem feedback — det bliver jeres forbedringsmotor.
Spørgsmål der mangler klare svar
Ubesvarede punkter i offentlige kilder: ingen konkrete SLA’er for indeksopdatering eller worst‑case‑latens, ingen tydelig prisstruktur, samt begrænset transparens om indeks‑sammensætning og crawl‑politik (ifølge AWS’ blog og docs, kilder). Også uklart: detaljer for log‑eksport, audit‑trails og retention i kundens konto.
Derudover: enterprise‑filtre for PII, mulighed for private eller fokuserede indekser bundet til en konto, og tracing på tværs af værktøjskæder, så man kan dokumentere præcis hvilke snippets, der formede et svar. Få svar, før kritiske flows bindes til connectoren.
Hvordan det adskiller sig fra alternativer
At bygge en egen connector oven på Google, Bing eller en specialiseret leverandør giver mere kontrol, men kræver aftaler, nøglehåndtering, rate limits og robust snippet‑ekstraktion. Til gengæld ejer man styringen — og ansvaret for kvaliteten.
Den forvaltede AWS‑connector reducerer kompleksitet og holder trafikken i AWS (ifølge AWS’ blog, kilde). Kontrol over indeks og rangering overlades til Amazon. For mange er det en fair byttehandel for hurtigere time‑to‑market. For andre med nichekrav er en hybrid ofte bedre: brug Web Search som default, men tilfør egne værktøjer til de kilder, I ikke vil afgive.
Praktisk betydning for drift
Det kræver governance. Hvem må slå op på hvad og hvornår, og hvordan logges og opbevares spor. Skeln skarpt mellem test og produktion. Fejl sker, når nogen “lige” åbner for noget midt i en release.
- Adgang: rolle‑ og attributbaseret kontrol per værktøj/target
- Audit: fulde request/response‑spor med tidsstempel, værktøj, bruger og kilde‑URL
- Data: klar retention‑politik og sletningsrutiner, inkl. PII‑flows
- Fail‑safes: rate‑ og cost‑alarmer samt degraderet tilstand uden web‑opslag
En to‑måneders pilotplan
Uge 1‑2: afgræns PoC‑scenarier. Vælg tre‑fire forespørgselstyper: realtidsnyheder/prisændringer, niche‑long‑tail samt et par følsomme emner til at teste styring og logning. Mål på klare nøgletal:
- Citation recall: andel svar med korrekte, klikbare kilder
- Snippet precision@k: andel af top‑k snippets der indeholder beviset
- Freshness p50/p95: minutter fra publicering til fundet snippet
- Latens p50/p95: værktøjskald og end‑to‑end
- Cost per 1k queries og cost per succesfuldt besvaret query
Anden halvdel af piloten
Uge 3‑4: implementér via AgentCore Gateway. Tilføj verifikations‑ og citationslag. Test værktøjsopdagelse via tools/list, kør A/B mellem ren Web Search og Web Search kombineret med interne API’er. Dokumentér fejltyper — især hvor snippet er korrekt, men modellen misforstår konteksten.
Uge 5‑6: sæt overvågning og audit op. Tjek hvilke logs Gateway eksponerer, og hvordan de kan eksporteres til egne systemer (ifølge Gateway‑dokumentationen, kilde). Mål omkostninger og kvoter i praksis. Lav lasttests i rykkes‑mønstre, fx ved produktlanceringer.
Sidste sprint
Uge 7‑8: vurder dækning og blinde pletter. Kør kontrollerede søgninger mod kendte sandheder i domænet, og markér hvor Web Search fejler eller vender tomt tilbage. Beslut, om en hybridstrategi er nødvendig, og opdater arkitekturen. Afslut med en testrapport med målinger og en klar go/no‑go‑anbefaling.
Hold fast i, at forespørgsler ifølge AWS bliver i AWS (kilde) — men verificér, hvordan det gælder i jeres kontoopdeling, netværk og regioner. Afklar retention og sletningspolitikker, især for PII. Få dokumentation for egress‑kontrol, og tjek at der ikke sniger sig bagveje ind via tredjepartsværktøjer.
Hvorfor det kan være afgørende i praksis
For teams, der skal holde en agent opdateret på pressemeddelelser, driftstatus eller regulatoriske ændringer, er en forvaltet web‑connector en genvej — ikke til sandheden, men til materialet, der dokumenterer sandheden. Den forskel mærkes, når tiden er kort.
Beslutningen er både teknisk og strategisk: Hvor meget kontrol afgiver I for at vinde fart? Hvor meget gennemsigtighed kræver jeres domæne? Og hvor stor en del af fejlraten kommer fra leverandørens indeks kontra jeres egne kilder?
Samlet vurdering
Web Search på Bedrock AgentCore sænker barrieren for at give agenter frisk viden fra nettet. Forvaltet drift, MCP‑kompatibilitet og en privatlivsmodel inden for AWS er stærke kort (ifølge AWS’ blog og Gateway‑dokumentationen, kilder). Det, der mangler for et fuldt billede, er tal for opdateringsgaranti, tydelig pris og dybere indsigt i indeks og auditmuligheder. Indtil da bør produktteams holde fast i verifikations‑ og governance‑lag.
Konklusionen er jordnær: test grundigt. Mål præcision, friskhed og citationskvalitet. Bevar egne kontroller. Beslut ud fra data, ikke løfter. Man opdager først forskellen, når man sidder med det i hænderne.
