Hopp til hovedinnhold
 AI-nyheter, ferdig filtrert for ledere
SISTE:

Ivanti-feil gir root før helgens patchfrist • USA tvinger Anthropic til å stenge Fable og Mythos • LangGraph-feil kan gi full kontroll over selvhostede AI-agenter • Agentjacking gjør feillogger til angrep mot kodeagenter • Google går til sak mot AI-drevet svindelnettverk

AWS viser agentisk hendelsestriage med New Relic
CIOCTOCISOCOOStyreAWSAmazon QuickNew RelicAsanaMCPAI AgentsAgentic AIAIOpsSREIncident ResponseObservabilityAI GovernanceAI SecurityRuntime SecurityEnterprise AIRisikostyringLeverandørstyring

AWS viser agentisk hendelsestriage med New Relic

JH
Joachim Høgby
10. juni 202610. juni 20264 min lesingKilde: AWS Machine Learning Blog

AWS flytter agentdiskusjonen fra demo til drift. I et nytt oppsett kobles Amazon Quick til New Relics MCP-server og Asana, slik at en vaktgående ingeniør kan starte hendelsestriage fra én prompt. Agenten henter observabilitetsdata, vurderer brukerimpact, analyserer logger og transaksjoner, skriver et første RCA-utkast og oppretter en oppgave for videre håndtering.

Det høres ut som enda en AI-assistent. Det er mer interessant enn som så. Hendelseshåndtering er en av de mest målbare prosessene i IT: tiden fra alarm til forstått årsak, tydelig impact og riktig eierskap avgjør både kundeopplevelse og risiko. Når agenten får tilgang til faktiske driftsverktøy gjennom MCP og ferdige integrasjoner, blir spørsmålet ikke om den kan skrive pent. Spørsmålet er om den kan redusere friksjonen mellom alarm, analyse og handoff uten å skape nye feil.

AWS beskriver et konkret mønster. Amazon Quick-agenten bruker New Relic-verktøy for å identifisere drivere bak en alarm, måle berørte brukere og tjenester, analysere logger, finne trege eller feilende transaksjoner og kjøre naturlig språk mot NRQL-spørringer. Deretter samles funnene i et RCA-brief med lenker til bevis. Asana-koblingen brukes til å opprette en sporbar oppgave.

For norske CIO-er og CTO-er er dette et tidlig bilde av hvordan agentisk drift vil se ut i praksis. Ikke som en autonom svart boks som «fikser produksjon». Mer sannsynlig som et koordineringslag som gjør de første 10–20 minuttene av en hendelse mer standardisert. Den leser på tvers av verktøy. Den lager førsteversjon av situasjonsbildet. Den tvinger frem dokumentasjon. Og den gir neste person i vaktløpet et bedre startpunkt.

Det er nettopp derfor styringen må på plass tidlig. En agent som jobber i hendelseshåndtering må ha klare grenser for hva den kan lese, hva den kan skrive, og hva den aldri skal endre. Lesetilgang til observabilitetsdata er én risikoklasse. Å opprette oppgaver og sende status videre er en annen. Å gjøre endringer i produksjon er noe helt annet. Bedrifter som blander disse nivåene, vil raskt få et sikkerhets- og revisjonsproblem.

MCP gjør saken ekstra viktig. Model Context Protocol er i ferd med å bli standardmåten agenter kobles til verktøy og data på. Når New Relic eksponerer egne reasoning-verktøy gjennom MCP, og Amazon Quick kan bruke dem som del av en agentflyt, blir driftssystemene del av agentens arbeidsflate. Det gir fart. Det gir også en ny angrepsflate, nye tilgangsspørsmål og nye krav til logging.

AWS skriver at intern testing på New Relics egne applikasjoner reduserte bevisinnsamlingsfasen i hendelsestriage. Det er et nyttig signal, men ikke en universell effektmåling. Verdien vil avhenge av datakvalitet, tjenestekart, varslingshygiene og hvor godt organisasjonen allerede dokumenterer hendelser. Dårlige alarmer blir ikke gode fordi en agent leser dem raskere. Rotete eierskap blir ikke ryddig fordi en agent lager en Asana-oppgave.

Likevel peker mønsteret riktig vei. Mange virksomheter har brukt AI i drift som et søke- eller oppsummeringsverktøy. Nå kommer flytene der agenten faktisk orkestrerer mellom observabilitet, oppgavestyring og kunnskapsbase. Da må ledergruppen vurdere AI i drift som en del av SRE- og sikkerhetsmodellen, ikke som et eksperiment i Slack.

Tre spørsmål bør stilles før slike agenter slippes inn i produksjonsnær drift. Først: hvilke systemer kan agenten lese fra, og hvordan skilles kunde-, person- og sikkerhetsdata? Deretter: hvilke handlinger kan agenten utføre uten menneskelig godkjenning? Til slutt: hvordan etterprøves agentens vurderinger når incident review gjennomføres?

Den praktiske gevinsten kan være betydelig. Vaktlag mister mindre kontekst mellom skift. Nye ingeniører får mer konsistente førsteanalyser. Ledere får bedre sporbarhet på hvorfor en hendelse ble prioritert som den ble. Men gevinsten kommer først når agenten behandles som produksjonsinfrastruktur. Den trenger rollebasert tilgang, testmiljø, audit-logg, evalueringer og klare fallback-regler.

Det er også et leverandørspørsmål. Amazon Quick, New Relic og Asana viser en attraktiv integrert flyt. Samtidig binder den hendelseshåndteringen tettere til valgte observabilitets- og arbeidsflytverktøy. CIO bør derfor vurdere hvor portabel agentlogikken er. Hvis RCA-format, handoff og tilgangsmodell bygges rundt én leverandørpakke, blir senere bytte dyrere.

Det viktigste signalet er ikke at AWS har laget enda en agentdemo. Det er at hendelsestriage nå blir en naturlig kandidat for agentisk arbeidsflyt. Når produksjonsdrift får AI-agenter, flytter modenhetskravet seg fra «kan modellen svare?» til «kan vi stole på prosessen, tilgangen og bevisene?». Der ligger den reelle lederoppgaven.

Kilder og medier

  • Primærkilde: AWS Machine Learning Blog, «Build an agentic incident triage assistant with Amazon Quick and New Relic», publisert 9. juni 2026. https://aws.amazon.com/blogs/machine-learning/build-an-agentic-incident-triage-assistant-with-amazon-quick-and-new-relic/
  • Kildekreditering: AWS Machine Learning Blog / Amazon Web Services.
  • Thumbnail: OpenAI Image 2 / hogby.ai

📬 Likte du denne?

AI-nyheter for ledere. Kuratert av en CIO som bygger det selv. Daglig i innboksen.