Mobileye har rullet en AI‑supportagent i produktion på Amazon Bedrock AgentCore. Ifølge AWS faldt svartiderne med 90 procent, og målet om over 95 procents præcision blev passeret. Løsningen beskrives som uden ekstra infrastruktur overhead og nu udbredt som intern selvbetjeningsplatform, så flere teams kan bygge egne agenter. Tallene og arkitekturen er konkrete – og værd at skille ad.
Kontexten er massiv. Mobileye har mere end 230 millioner EyeQ‑chips i biler globalt fordelt på cirka 1.200 modeller. Bag kulissen kører en dataindsamlings‑ og behandlingspipeline, der dagligt sluger tusindvis af køre‑sessions. Når sådan en maskine vokser, eksploderer interne statusforespørgsler. Ifølge AWS var 66 procent af tickets rutineprægede statusspørgsmål, som krævede omkring 15 klik på tværs af backend‑systemer. Det er spildt ingeniørtid.
Problemets kerne
Supporten handlede sjældent om de svære fejl i første hug. Det meste var “hvor er den her session henne”, “er den kørt færdig”, “hvorfor fejler den”. Svaret fandtes, men var spredt. Identificér sessionen, tjek visualiseringsværktøjet, verificér outputs, læs logs, skriv svar. Gentag. Den type opgave kvæler flow i udvikling og drift, når den skalerer.
Traditionelle automationsgreb løste det ikke. Scripts og statiske workflows er hurtige, når spørgsmålet er forudsigeligt. Men reelle supportforespørgsler er fulde af kontekst og små variationer. Regeltræer bliver hurtigt tunge at vedligeholde og reagerer dårligt på halvvejs input eller kombinationer på tværs af systemer.
Valget af byggesten
Løsningen blev en agent bygget på Amazon Bedrock AgentCore, som taler med Mobileyes backend via Model Context Protocol (MCP). Kernen i agenten kører på Anthropic Claude, tilgået gennem en intern LLM Gateway, der styrer kvoter og adgang til modeller via Bedrock. Gateway‑grebet er ikke bare pæn governance; det sætter loft, skaber sporbarhed og holder styr på forbruget.
MCP‑laget giver realtidsadgang til platformens API’er under inferens. Agenten spørger direkte til sessionstatus, henter behandlingslogs, trækker diagnostik. Ikke kun klassifikation eller tekstsammenfatning, men aktiv fejlsøgning på tværs af systemer. Det er agentadfærd i praksis, fordi værktøjerne er åbne for agenten frem for at gemme sig bag manuelle trin.
Arkitekturen i praksis
AWS beskriver en hybrid arkitektur, hvor on‑prem systemer kobles til cloud‑tjenester i AWS. AgentCore fungerer som managed lim imellem, med indbygget enterprise observability. Ifølge casen kunne teams fokusere på agentens opgaver og værktøjer frem for at holde styr på servere, orkestrering eller metrics‑opsamling.
“Zero infrastructure overhead” er formuleringen. Læs den nøgternt: Der blev ikke rullet særskilt agent‑infrastruktur ud, fordi AgentCore leverer hosting, orkestrering og overvågning som service. Det udelukker ikke arbejde med netværk, sikkerhed, adgangsstyring og integration. Men besparelsen er reel, hvis platformen dækker driftsbehov ud af boksen.
Fra POC til tal på tavlen
Før produktion satte Mobileye konkrete mål for POC’en: 95 procents accuracy i ticket‑klassifikation og svartider under to minutter. Ifølge AWS klarede agenten begge dele og blev derefter udvidet fra klassifikation til fulde svar med loglinks, fejludtræk og step‑for‑step‑guides – stadig uden menneskelig håndtering. Det er forskellen på en chatbot og en operativ agent, der slår op i de rigtige systemer.
Her er der dog åbne spørgsmål. Blogindlægget forklarer ikke fuldt, hvordan accuracy blev målt, hvilken baseline der blev brugt, og hvor længe testen kørte. Var det en uge, en måned, et kvartal – og hvor stor en andel af produktionen var med? Det er nødvendigt for at vurdere, om resultaterne holder i længere drift.
Konsekvenser for drift
Indbygget observabilitet er nøglen. Når metrics, tracing og fejlhåndtering følger med platformen, kan supportledere monitorere svarhastighed, succesrater og fejltyper uden at stable et ekstra telemetry‑setup. Det gør SLA‑opfølgning og incident‑håndtering mere kedelig på den gode måde: repetitiv og målbar fra dag ét.
LLM Gatewayen spiller også en stille hovedrolle. Kvoter og styret adgang til modeller giver forudsigeligt forbrug og nem revurdering, når modeller skiftes eller versionsopdateres. Samtidig skaber det et audit‑spor for forespørgsler og outputs, der kan revideres, når et svar skal granskes eller en fejl spores.
Governance i en hybrid verden
MCP åbner for liveopslag i on‑prem API’er. Det rejser straks krav til autentificering, autorisation og netværk: token‑levetid, mTLS, IP‑områder, rate‑limits. Det beskriver AWS ikke i dybden, men netop her bliver hybridintegration ofte vanskelig. Fordelen er, at data forbliver i de kilder, der allerede er beskyttet og versioneret. Agenten flytter ikke data unødigt – den spørger på stedet.
For governance betyder det flere praktiske ting: Logging skal dække både agentens beslutningsspor og de kald, den laver ud i systemerne. Der skal være klare regler for, hvornår agenten svarer automatisk, og hvornår den eskalerer. Og der skal være tydeligt ejerskab af incidents, når en model svarer forkert, eller et underliggende API leverer dårlig data.
Tradeoffs og blinde vinkler
Casen er stærk, men der er kendte faldgruber. Datasikkerhed og latens kommer først. Når en agent går fra on‑prem til skyen og tilbage igen, kan netværket være den reelle flaskehals. Modelopdateringer er næste: Skifter man modelversion, ændrer adfærd sig typisk subtilt, og regressionstests bliver nødvendige for at undgå driftsoverraskelser.
Fejltilstande bør være gennemarbejdede. Hvad sker der ved timeouts, når MCP‑værktøjet ikke svarer, eller når en logfil er for stor til at parse? Bloggen nævner ikke fallbacks, human‑in‑the‑loop eller genforsøgspolitik. Det betyder ikke, at de ikke findes – men organisationer bør have klare procedurer, fordi de her fejl sker oftere, end man tror.
Organisatorisk effekt
AgentCore blev efterfølgende gjort til en intern selvbetjeningsplatform. Det er en tung beslutning, for så begynder mange teams at bygge egne varianter. Uden stram governance ender det let med parallelle agenter, duplikerede værktøjer og inkonsistente standarder. Gevinsten er hastighed: Domæneteams kan eksperimentere hurtigere og få deres egne FAQs, workflows og værktøjskæder operationaliseret.
Det kræver et katalog og et register: Hvilke agenter findes, hvem ejer dem, hvad må de, og hvordan rulles de tilbage. Derudover testmiljøer, der ligner produktion, så værktøjer kan prøves uden risiko. Og en enkel måde at dele policies på tværs, så alle ikke skal opfinde adgangsstyring og kvoter fra bunden.
Hvad betyder det i praksis for danske it‑teams
Nogle erfaringer går igen, uanset branche. Start med observability fra dag nul. Vælg værktøj eller platform, hvor logs, tracing og metrikker følger med, så der ikke opstår et ekstra driftsspor for instrumentation. Sæt klare mål for svartid og præcision før POC, og beslut hvordan de måles. Det gør evalueringen konkret.
Planlæg hybridforbindelser tidligt. Tjek latens, mTLS, tokenudløb og databegrænsning på API‑kald, før der bygges flows. Og vælg en gateway‑model for LLM‑adgang, så forbrug kan kvoteres, logges og auditeres. Når først teams får selvbetjening, er det for sent at bagmontere styring.
Konkurrencevinklen
Der er mange cases om AI‑assistenter, der svarer hurtigere på tickets. Det særlige her er vægten på hybridintegration og påstanden om nul infrastruktur overhead. Hvis det holder, flyttes tyngdepunktet fra at bygge platforme til at bygge brugbare værktøjer ovenpå. Det skalerer bedre i store organisationer, fordi drift ikke fordobles per agent.
Det oplagte journalistspørgsmål bliver derfor, hvor meget “nul” dækker over. Ingen ekstra servere – men hvad med netværksregler, IAM‑opsætning, on‑call‑beredskab, dataklassifikation? Og hvordan spiller AgentCore sammen med en eksisterende observability‑stak, hvis virksomheden i forvejen har egne dashboards og alarmer?
To korte scenarier
Industri. Et produktionsanlæg har hundredvis af batches i gang. 60 procent af supportforespørgslerne handler om status og fejlkoder i MES og historik i SCADA. En agent med MCP‑adgang til begge API’er kan svare på minutter, pege på nøjagtig batch, fejltype og næste handling – med loglinks til audit.
Transport. Et logistikcenter får løbende tickets om forsinkelser i scanning, tolddokumenter og ruteoptimering. Agenten kender systemernes API’er, kan slå op på forsendelse, tjekke eventlogs og give et svar med kilde og sandsynlig årsag. Det handler om systemadgang, en standardiseret værktøjskasse og faste mål for svartid.
Afsluttende vurdering
Mobileyes case peger på, at AI‑agenter kan flytte nålen i den driftsnære virkelighed, når de får de rigtige værktøjer og realtidsadgang. Gevinsterne er tid, ensartede svar og mindre træk på specialister. Risikoen ligger i målemetoder, integration og governance. Uden præcise KPI’er, tydelige netværksgrænser og ejerskab på incidents bliver agenten en dyr omvej.
Bundlinjen er jordnær: Hvis AgentCore leverer drift, observability og hygiejne i praksis, er det en genvej ind i produktion. Hvis ikke, står man med endnu en platform at passe. Forskellen ses først, når metrics og hændelser følges over uger – ikke på dag ét.
Faktaboks
- 230+ mio. EyeQ‑SoC i biler globalt, ca. 1.200 modeller – kilde: AWS
- Tusindvis af køre‑sessions indlæses dagligt – kilde: AWS
- 66 procent af tickets var rutinesager med ca. 15 klik på tværs af systemer – kilde: AWS
- 90 procent hurtigere svartider med AI‑agent på AgentCore – kilde: AWS
- Over 95 procents accuracy‑mål overgået – kilde: AWS
- Hybrid on‑prem og AWS‑arkitektur, MCP og LLM Gateway – kilde: AWS
Kilder og næste skridt
Primær kilde er AWS’ tekniske blog om Mobileye og AgentCore. For at verificere effekterne i praksis bør der anmodes om dokumentation fra Mobileye og AWS: POC‑protokoller, målemetode for accuracy og svartider, tidsserier over flere uger og præcise definitioner af tickets og succes. Derudover daglige eller ugentlige metrics for andel af auto‑løste sager versus eskalerede, samt fejltyper og latens fra MCP‑kald.
Bed også om konkretisering af “zero infrastructure overhead”: Hvilke netværksændringer, IAM‑rettigheder og driftsopgaver var faktisk nødvendige? Hvordan er fallback organiseret ved modelsvigt eller API‑timeouts, og hvor ligger ansvaret ved incident? Afslut med en sikkerhedsgennemgang af dataflow: hvor data berøres, kryptering i transit og i hvile, og hvordan adgangslogning håndteres på tværs af on‑prem og cloud.
