Hvad er nyheden
Intuit fortæller i en teknisk gennemgang, at de har bygget EWOK Agent, en agentisk assistent til katastrofe-genopretning, oven på deres eksisterende orkestreringslag ved hjælp af Amazon Bedrock. Den har været brugt i produktion på tværs af teams i otte måneder (kilde: Intuit/AWS-blog). Formålet er at lukke hullet mellem automatiseret udførelse og den svære del af et nedbrud: at vælge den rigtige recovery-strategi, bekræfte aktiver og håndtere undtagelser.
Baggrunden er velkendt for SREs: DR i skala er hårdt. Når tusinder af microservices er spredt over flere AWS-regioner, bliver koordinerede failovers en kompleks opgave med for lidt tid (kilde: Intuit/AWS-blog og Snilld-manual).
Hvorfor det betyder noget
Intuit driver produkter som TurboTax, QuickBooks, Mailchimp og Credit Karma for millioner af brugere (kilde: Intuit/AWS-blog). Et udfald i skattesæsonen gør ondt. DR er ikke bare snapshots, men hurtige valg på tværs af compute, databaser, netværk, caches og asynkrone køer. Kæden skal virke end-to-end.
Forestil dig et on-call-billede klokken 03.17: stigende timeouts i betalingskæden, en region med høj latency, half-open forbindelser. Skal man promovere en read-replica til primary eller rute trafik til en anden region? Forkert valg kan flytte problemet i stedet for at løse det. Det er her beslutningsstøtten skal holde.
EWOK: hvad eksisterede og hvad virkede
Intuits eksisterende system, EWOK, er et centralt orkestreringslag for DR. Serviceejere erklærer recovery-intent i YAML, og EWOK omsætter det til konkrete infrastrukturtrin på tværs af compute, databaser, netværk, caches og asynkrone workloads. Ifølge Intuit sænkede det recovery-tider for understøttede workloads fra flere timer til omkring 20 minutter (kilde: Intuit/AWS-blog). Det standardiserer udførelsen og fjerner manuelle, fejlbare trin.
Kort sagt: definer hvad, systemet eksekverer hvordan. Indtil en person skal vælge selve playbooken. Her opstod hullet.
Beslutningsgabet
EWOK løste eksekvering, men ikke valget. At finde det rigtige workflow, bekræfte at et aktiv er klar, og styre undtagelser midt i en recovery, lå stadig på erfarne on-call ingeniørers stammeviden. Intuit nævner change-freeze i kritiske perioder som skattesæsonen: en failover-anmodning kan afvises, medmindre man følger en specifik emergency-override-procedure (kilde: Intuit/AWS-blog). Den viden står sjældent præcist i YAML.
I praksis betyder det, at nogen skal beslutte hurtigt, før metrics falder til ro.
EWOK Agent: arkitektur og valg
For at tætne hullet lagde Intuit et beslutningslag oven på EWOK: EWOK Agent. Arkitekturen er bevidst stram: “The model decides what to do, and the EWOK Agent deterministically executes how.” (kilde: Intuit/AWS-blog). Grænsen holdes skarp, så modellen ikke får direkte hånd på produktionskontakter.
Agenten leveres som plugin, der kan bruges fra Intuits ingeniørportal eller fra en IDE. Failover-viden kodes som skills, der binder til EWOKs handlinger. En anmodning som “failover payments-gateway i produktion” omsættes til en valideret, policy-tro recovery med tydelig sporbarhed (kilde: Intuit/AWS-blog).
Hvor Bedrock kommer ind
Ifølge Intuit/AWS giver Amazon Bedrock adgang til “hundreds of foundation models” fra flere udbydere via en enkelt API, så man kan evaluere og skifte model uden at bygge agenten om (per Intuit/AWS-blog). Bedrock er fuldt managed, så Intuit undgår at drifte modelinfrastruktur (per Intuit/AWS-blog). De fremhæver også Bedrock Guardrails samt sikkerhed/privatliv: data bruges ikke til modeltræning og er krypteret i transit og i hvile (per Intuit/AWS-blog). Det er leverandørudsagn i blogindlægget.
Teknisk ligger der et tyndt Bedrock-lag mellem modellen og skills-laget. Bedrocks Converse-API med tool use mappes til EWOKs deterministiske grænseflader (kilde: Intuit/AWS-blog). Her bør ledere samtidig notere det, kilden ikke dokumenterer: konkrete omkostningstal. En PoC bør derfor fra dag ét måle API-kald pr. failover, model-latens pr. region og logging-volumen, så økonomien ikke bliver en blind vinkel.
Operationelle konsekvenser
For on-call flytter fokus: mindre tid på at bladre i runbooks, mere på at overvåge, verificere og afbryde, når antagelser brydes. Der skal være en skarp emergency-override – både menneskelig og teknisk – der kan trumfe et agentforslag under change-freeze eller ved uklare symptomer. Og logningen skal være minutiøs: prompts, valgte skills, policy-tjek og EWOK-udførelser i rækkefølge.
Runbooks bør blive mere deklarative. Vedligeholdes som versionerede policies og skills, testet som kode. Revisioner skifter fokus fra wiki-sider til skill-definitioner, Guardrails-konfigurationer og IAM-handlinger, agenten må kalde. Snilld-manualen peger samme vej: automatiserede playbooks, forudsigende overvågning og kontinuerlig verifikation via chaos-tests (kilde: Snilld-manual).
Regulatoriske krav
Agentisk automatisering i DR rører ved governance. EU AI Act og tilsvarende rammer skaber reel friktion for autonome beslutninger i produktion. Kortlæg den juridiske risikoprofil tidligt i PoC-fasen, så krav til kontrol, auditabilitet og dokumentation ikke dukker op, når systemet allerede står i on-call-vagten. Det sparer jer for en kold dukkert senere.
Risici og ubesvarede spørgsmål
“Adgang til hundredvis af modeller via én API” er et leverandørudsagn (per Intuit/AWS-blog). Uden en modelliste pr. region og evalueringsdata er den operationelle værdi svær at validere. Sikkerhedsløfterne om ikke-træning og kryptering er tydelige, men ingen uafhængig audit nævnes i kilden. Der mangler også driftstal: fejlrate, tidsbesparelse pr. failover, antal automatiserede vs. eskalerede sager.
Omkostningerne er ubelyst i kilden. Inden opskalering bør man have tal for API-forbrug, modelvalg-latens og logging/overvågningsomkostninger. Ellers bliver budgettet den skjulte risikofaktor.
Sammenligning med agent-trends
Udviklingen lander i en bredere agentbevægelse: længere tråde, bedre værktøjskald og strammere stopklodser. Et eksempel fra et andet domæne er Muse Spark 1.3 fra Meta, målrettet langtrådet agentisk/coding-arbejde med færre værktøjskald og færre tokens end 1.2, udstillet via Meta Model API og ikke selvhostbar, med gated reasoning-mode (kilde: Marktechpost). Andet domæne, anden hosting, men samme overordnede motiv: mere kontrolleret værktøjsbrug og tydeligere “spørg om hjælp, før du gætter”.
Implementering i praksis
Et læringspunkt fra Intuit er at lægge et tyndt lag oven på en eksisterende orkestrator. Behold det deterministiske udførelseslag intakt. Lad agenten tage valg inden for snævre, reviderbare rammer. Skub viden ind i deklarative skills, der kan versioneres og testes – også negative tests. Og sæt klare policies for, hvornår agenten må gøre hvad (kilde: Intuit/AWS-blog).
Byg en tidlig målestrøm: log hvert agentkald, beslutningslatens, antal afvisninger under policies og cost per failover. Kræv også udmeldte tal fra leverandøren, før opskalering: fejlrate, median beslutningslatens, andel automatiserede vs. eskalerede sager og faktiske driftsomkostninger. Uden de tal bliver on-call ikke overbevist klokken 03.17.
Praktisk tjekliste for ledere
Hvis du overvejer agentisk beslutningsstøtte i DR, så start her:
- Adskil beslutning og eksekvering: hold udførelsen deterministisk i en EWOK-lignende orkestrator og test grænsen med kaostests (kilder: Intuit/AWS-blog; Snilld-manual).
- Verificer sikkerhed og databrug: ikke-træning og kryptering i transit/at rest, samt konfiguration af Bedrock Guardrails og IAM-grænser (per Intuit/AWS-blog).
- Versionér og test skills som kode, inkl. change-freeze/override-scenarier og delvise udfald (kilde: Intuit/AWS-blog).
- Mål agentens fejl/eskaleringer og beslutningslatens, og sæt tærskler for emergency-override (kilder: Intuit/AWS-blog; Snilld-manual).
- Lav en omkostningsmodel for Bedrock-forbrug, logging og overvågning før skalering, og mål API-kald pr. failover fra dag ét (manglende tal i kilden gør dette nødvendigt).
Hvad læseren bør gøre nu
Start med et afgrænset PoC-domæne. Definér 5–10 skills, kobl dem på jeres orkestrator og mål end-to-end. Simulér change-freeze, og tving agenten gennem jeres emergency-override, mens logs og audits kører. Involver compliance tidligt, især hvis finansielle flows er i spil. Planlæg kaostests, der skubber agenten ud i uklarheder og verificér, at den beder om hjælp i tide.
Kræv tal, før I skalerer: fejlrate, beslutningslatens, korrekte afvisninger under policy og cost per failover.
Afsluttende vurdering
Intuit viser et brugbart mønster for at lukke beslutningsgabet i DR med et agentlag oven på en eksisterende orkestrator. Arkitekturen er konservativ på den gode måde: skarp adskillelse mellem beslutning og deterministisk udførelse, plus klare hegnspæle.
Men uden uafhængige metrics, audits og omkostningstal bør andre organisationer træde varsomt. Løsningen er lovende som designmønster. Ikke en plug-and-play fritagelse for driftstilsyn.
