Lead: Hvad AWS netop annoncerede og hvorfor det betyder noget nu
AWS har annonceret, at Amazon OpenSearch Service nu understøtter MCP Apps, så AI‑assistenter kan levere både tekst og interaktive visualiseringer direkte i chatten. AWS skriver: “Observability agents are fast. They query alerts, correlate logs with traces, and produce a root cause hypothesis in minutes.” Og de peger straks på problemet: “The part that still takes time is verification.” Her forsvinder tiden i dag, når man under en hændelse forlader agenten, åbner et dashboard og hopper tilbage. MCP Apps forsøger at klippe den sløjfe over.
I blogindlægget beskriver AWS et udvidet MCP‑mønster, hvor værktøjskald returnerer et dobbelt svar: tekstforklaring plus en interaktiv widget i samme tråd. Formuleringen lyder: “MCP Apps extend the Model Context Protocol so that each tool call responds with an interactive visualization … rendered directly in your AI assistant’s chat window alongside the text response.” Det er ikke bare et klik mindre, men et andet arbejdsflow.
Hvad er problemerne i dagens observability‑workflow
I dag er loopen typisk den samme. Agenten fremsætter en kvalificeret hypotese, og ingeniøren åbner derefter observability‑værktøjer, finder trace‑waterfallet, kigger på servicekortet og forsøger at reproducere det, agenten påstår. AWS beskriver det næsten ordret: “You read the agent’s text summary, open your observability tools in a browser, navigate to the trace waterfall, check the service map … The agent saved you the query time. It did not save you the tab-switching, context-carrying, manual-verification time.” Det er den manuelle verifikation, der bremser tempoet.
Konsekvensen er tab af kontekst: man forlader samtalen for at klikke rundt i et UI, mister tråden, vender tilbage og skal genskabe tankegangen. Små fejl sniger sig ind — forkert tidsrange, forkert filter — og minutterne løber.
Hvad MCP Apps gør teknisk
MCP Apps introducerer et dual‑response‑mønster, hvor et tool‑kald både returnerer en forklaring i tekst og en interaktiv visualisering fra OpenSearch UI. Ifølge AWS: “You ask the agent to investigate. The agent queries Amazon OpenSearch Service. The response arrives with both a text explanation and the relevant dashboard widget.” Visualiseringen skabes ved at køre kode mod de samme datakilder, der driver dashboards. Blogindlægget siger: “Because of this, the results are deterministic. You’re not trusting the AI’s interpretation. You’re seeing the actual query result …”
Pointen er ikke kun, at der renderes i chatten, men at verifikationen sker i samme tråd uden at åbne en ny fane eller genkøre queries. AWS siger: “You verify in the same thread where you asked the question, without opening a separate browser tab or re-running a query.” Der er dog en blind vinkel her: blogindlægget demonstrerer arkitektur og flow, men dokumenterer ikke detaljerede API‑kontrakter eller præcise dataformater for visualiseringerne. Det sætter en naturlig grænse for, hvor meget man kan konkludere om udvidelsesmulighederne nu.
Hvordan det ændrer den daglige incident‑håndtering
Når verifikation ligger i samme chattråd, reduceres konteksttab. Man kan bede om et trace‑waterfall og samtidig få en kort, struktureret forklaring uden at forlade skrivefeltet. Det ændrer dynamikken: man verificerer inline, beder om en snævrere tidsrange og ser resultatet på stedet — uden rundtur i flere systemer.
Men det skærper også kravene. Adgangsstyring er ikke kun et dashboard‑anliggende længere: hvem må trigge hvilke visualiseringer gennem agenten og på hvilke scopes. Audit bliver tilsvarende vigtigere: hvem bad agenten vise en bestemt logpattern‑widget kl. 02.13, og hvilke parametre blev brugt. Uden sporbarhed bliver læring og efterrationalisering svær.
Sikkerhed og compliance: de åbne spørgsmål
Autorisation pr. forespørgsel er uklart i den offentlige dokumentation. Blogindlægget viser UI‑flow og arkitektur på højt niveau, men ikke hvordan fine‑grained rettigheder håndhæves, når en visualisering materialiseres i en chat. Skal agenten have et service‑token med bred læseadgang, eller proxes brugerens identitet gennem MCP‑serveren? De præcise beskrivelser mangler.
Datamaskering er den næste ubekendte. Hvis logudsnit eller dashboards indeholder PII, interne tokens eller andre følsomme felter, hvordan sikres masking, når visualiseringen lander i en chat, der måske gemmes og deles bredere? Der bør være en klar politik for, hvilke felter en MCP App må gengive, samt hvordan audit‑logning kobles til compliance‑krav. Indtil det er tydeligt, er udrulning i regulerede miljøer vanskelig.
Hvor meget tid kan man spare, og hvad skal måles
Blogindlægget argumenterer overbevisende for færre kontekstskift, men der findes endnu ingen uafhængige benchmarks for MTTR. En nøgtern PoC bør minimum måle: tid til første verificerede observation, samlet MTTR og falsk‑positiv‑rate i agentens hypoteser. Gerne også antal kontekstskift pr. hændelse.
Snillds professionsvurdering, baseret på manual brief‑materiale, er, at generativ AI kan automatisere dele af verifikationen og på sigt reducere MTTR. Det kræver praksisvalidering. I en PoC bør det fremgå eksplicit, om verificeringstiden falder, om antallet af fejlagtige bekræftelser ændrer sig, og om nye risici opstår, fx oversete edge‑cases. Uden de tal bliver gevinsterne slogans.
Implementeringskrav og afhængigheder
Der er nogle konkrete krav: en MCP‑kompatibel agent i IDE eller chat‑UI, en lokal MCP‑server (som AWS beskriver) der forbinder agenten og OpenSearch UI‑endpointet, en OpenSearch‑klynge med relevante data fra logs, metrics og traces samt et identitetslag med least‑privilege for servicekonti. Intet af det er eksotisk, men det skal hænge sammen, før en demo ligner virkelighed.
På datasiden er OpenTelemetry i praksis limen for spor og metrics, mens logs typisk lever via OpenSearch eller tilsvarende. Nogle teams kører Jaeger for traces, Grafana for dashboards og supplerer med OpenSearch til logs. MCP Apps retter sig mod OpenSearch UI som visualiseringsmotor. Det rejser integrationsspørgsmål: hvilke datasæt bør centraliseres i OpenSearch for størst effekt, og hvor meget duplikerer man i praksis?
Begrænsninger og risici ved automation af verifikation
Automatisering kan skabe overafhængighed. Hvis en agent bekræfter en hypotese med en visualisering med forkert tidsvindue eller filtrering, ligner det sandhed — og man forfølger et forkert spor. Der bør derfor være en klar praksis for at vise parametrene bag hver visualisering.
Fejlhåndtering er et andet punkt. Hvad sker der, hvis visualiseringskald fejler, eller hvis data kommer med forsinkelse? Får man en ærlig fejl, en markeret usikkerhed, eller falder det hele tilbage til tekst uden forklaring? Blogindlægget beskriver arkitektur og det lykkelige flow; robusthed under tryk er ubeskrevet. Driftsteams vil kræve tydelige tilstande og rollbacks.
Konkrete anbefalinger til et lavrisiko PoC
Start smalt. Vælg én veldefineret alarmtype med høj frekvens og lav risiko, fx spike i 5xx på et kendt edge‑endpoint. Etabler en read‑only servicekonto med begrænsede scopes til OpenSearch. Aktivér MCP App for kun de nødvendige visualiseringer som trace‑waterfall og et simpelt logpattern‑view. Og mål fra dag ét.
Log al agent‑ og MCP‑interaktion i en separat audit‑strøm. Mål baseline i to uger, rul PoC i to uger, sammenlign. Kig ikke kun på MTTR, men også på verificeringstid og antal manuelle kontekstskift. Tag en retrospektiv efter første incident, hvor agenten var central: hvad gik hurtigt, hvad var skævt, hvad skal låses ned.
Hvad leverandører og konkurrenter vil fokusere på
Andre observability‑aktører vil sandsynligvis svare med egne agent‑plus‑UI‑bundter eller MCP‑kompatible integrationer. Proprietære flows kan friste med strammere coupling og mere poleret UX, mens åbne miljøer vil pege på fleksibilitet via OpenTelemetry og valgfrie værktøjer.
Får MCP Apps fodfæste, vil presset stige for at dokumentere API‑kontrakter, governance og sikkerhedsmodeller. Store kunder spørger først om roller og logs, ikke om farven på widgetten.
Rapporteringshuller og hvad der stadig mangler
Der mangler uafhængige målinger af fulde incident‑forløb, ikke kun hurtige queries. Ingen tredjeparts‑benchmarks viser endnu, hvor meget MCP Apps reducerer MTTR. Autorisation pr. visualisering og detaljer om audit‑trails er ikke beskrevet offentligt i dybden. Det samme gælder datapolitikker for PII‑maskering i chatloggede visualiseringer.
Teknisk savnes også konkrete API‑specifikationer og begrænsninger for query‑kompleksitet, retention og sample‑rates, når visualiseringer genereres. Robusthed under fejl og forsinket data er et åbent spørgsmål. Ekstern dokumentation for MCP‑protokollen, OpenSearch API’er og eventuelle tredjeparts‑eksperimenter bør indgå i en samlet vurdering før større udrulning.
Hvad AWS faktisk dokumenterer
AWS‑bloggen beskriver problemet, løsningen og arkitekturen og lover en trinvis gennemgang: “In this post, we explain how MCP Apps change your observability workflow and walk through setup step by step.” De dækker opsætning på et højt niveau, herunder arkitektur med lokal MCP‑server, koblingen til IDE og OpenSearch UI, og hvordan tool‑kald flyder gennem komponenterne. Det er et solidt startpunkt for en PoC.
Men der er begrænsninger i detaljegraden. Blogindlægget går ikke ned i formelle API‑kontrakter, detaljeret sikkerhedsmodel eller edge‑case‑håndtering. Fint til udviklere, der vil prøve konceptet; for platform‑ eller sikkerhedsansvarlige er der flere spørgsmål end svar — som ofte på lanceringsdagen.
Hvorfor det alligevel er et skridt frem
Kombineret med streng adgangsstyring, tydelig audit og simple, pålidelige widgets kan man forvente målbar effekt i de banale sager. Nogle gange er det nok, at den rigtige visualisering lander på det rigtige tidspunkt.
Konklusion og praktiske næste skridt
Det virker lovende, men beviset ligger i PoC’en. Start med et snævert use case, mål MTTR og verificeringstid, og involver sikkerhedsteamet fra første dag. Hold øje med falsk‑positiv‑rate på agenthypoteser, og kræv sporbarhed på hver visualisering. Ingen brede udrulninger før der ligger tal på bordet.
Agentisk observability flytter sig hurtigt. MCP Apps i OpenSearch adresserer den mest undervurderede hæmsko i incident‑håndtering: verifikationsflaskehalsen. Prøv det — og mål det.
