Vedvarende kontekst over lange forløb

Langløbende SAP‑projekter kræver kontekst, der overlever uger og måneder: tidligere beslutninger, kendte undtagelser, lokale tilpasninger. At hælde det hele i konteksten er fristende, men øger latenstid, omkostning og risiko for hallucinationer. AWS skriver det direkte: målet er den rigtige kontekst, ikke al kontekst. I praksis betyder det selektiv lagring, skarpe token‑grænser og klare politikker for, hvad der må genbruges hvor.

Konsekvensen for design er håndgribelig: definér kontekstskemaer, retention og opdateringsregler. Beslut, om man gemmer i en relationel database med revisionsspor, en vektorbase til semantisk opslag – eller begge dele. Valget påvirker pris, ydeevne og auditbarhed. Her mangler kilderne detaljer: KTern.AI oplyser ikke offentligt, hvilken lagringsstrategi de bruger. Det er ikke en fejl, men et punkt til due diligence.

Sikkerhed, governance og multi‑tenancy

Kravet i enterprise er enkelt formuleret og svært i praksis: hvert agentkald mod SAP‑API’er skal være autentificeret, autoriseret og auditeret. KTern.AI beskriver behovet for isolerede tenants og konfigurerbare regler pr. kunde. Det harmonerer med SAP‑praksis for rollebetinget adgang og revisionslogning. Ingen kilder beskriver dog præcist, hvordan tokens udstedes, roteres og tilbagekaldes, eller hvordan cross‑tenant isolation håndhæves i dybden. Det bør være afklaret før produktion.

Hvad med de store tal

Tre praktiske skridt før en POC

Det afgørende er ikke, om man kan bygge en demo, men om man kan eje driften. Start med en stram POC med få, tydelige use cases. Et oplagt valg er undtagelsesmining i Finance, hvor input og output kan afgrænses. Sæt en klar SLO for beslutningslatenstid og en målbar fejl\/false‑positive‑rate. Én uge til setup, tre uger til læring – nok til at vise retning.

Næste skridt er en teststrategi, der måler agentbeslutninger – ikke kun modelkvalitet. Brug hooks til at indføre pre‑flight checks: valider SQL‑filtre, rettigheder, datokontekst og transaktionsstørrelse, før noget kører. Registrér hver afvisning som en særskilt metrik. Det er tørt, men her skabes driftssikkerhed. Tredje skridt er versionering og change‑control af agentlogik: styr prompts, værktøjsregistrering og sikkerhedspolitikker som kode – med review og rollback. Alternativet er drift via ad hoc‑beskeder. Det holder ikke.

Drift og observability i hverdagen

Når man måler en agent, måler man loopet – ikke kun modellen. Relevante metrikker: beslutningslatenstid per trin, andel af afviste værktøjskald i pre‑flight, succesrate per værktøj, gennemsnitlig kontekststørrelse over tid samt genkørsler pr. sag. Læg dertil hændelseslogs, der kan kædes til SAP’s auditspor. Det muliggør incident response: hvad udløste fejlen, hvilken kontekst var indlæst, og hvem godkendte sidste regelændring.

Her defineres også SLO\/SLA. Forretningen kigger på lead time og nøjagtighed; driften på stabilitet og ressourceforbrug. Et praktisk kompromis er et “error budget” for agentiske beslutninger – som for mikrotjenester. Når budgettet er brugt, skalerer man ned på autonomi og op på menneske‑i‑loopen. Ikke elegant, men effektivt.

Risici, der ikke må overses

Hallucinationer er et slidt begreb, men stadig relevant: for meget eller forkert prioriteret kontekst øger risikoen. Datadrift – ændrede SAP‑felter, nye undtagelser – kan gøre en ellers god prompt dårlig i morgen. Planlæg regelmæssig validering, og brug change‑feeds fra SAP hvor muligt. Sikkerhedsbrud er den hårde ende: vær særligt opmærksom på tværkald, hvor en agent kan kæde to værktøjer sammen og utilsigtet omgå kontroller.

Organisatorisk handler adoption ikke kun om træning. Roller flytter sig: en proceskonsulent bliver kurator af værktøjer og regler. Det kræver mandat og tid. Juridisk skal man afklare, hvilke ERP‑data der må bruges i kontekstlagre, hvor længe, og hvordan retten til at blive glemt håndteres, hvis der ligger persondata i logfiler. I finans kan selv testdata være reguleret.

Konkurrencen og leverandørlandskabet

Andre aktører tilbyder lignende orkestrering via proprietære frameworks. Valget er klassisk: vil man eje mekanikken og kunne skifte model\/cloud, eller vil man have en låst, men poleret pakke? Strands’ løfte om “any model, any cloud” er attraktivt – men bør testes i praksis. Når prissætning og throughput presser, bliver små forskelle store.

Kilder, troværdighed og huller

De centrale kilder er AWS’ blogpost om KTern.AI’s implementering og Strands Agents SDK’s hjemmeside og dokumentation. Begge er leverandørnære og dermed ikke uafhængige. Påstandene om arkitektur og funktioner er konsistente på tværs af kilderne, især hvad angår agenttyper, vedvarende kontekst, sikre værktøjs‑hooks og observability. Der mangler uafhængig dokumentation for effektmålingerne (7x, 24 procent), detaljer om implementeringen af kontekstlagring og konkrete driftsmetrikker fra produktion.

En oplagt opfølgning er kundecases med gennemsigtige før\/efter‑målinger samt tekniske whitepapers om multi‑tenancy‑isolation og audit‑trail‑arkitektur. En AWS‑drevet referencearkitektur for AgentCore‑observability ville også give købere et fælles sprog til RFP’er. Lige nu må man samle det selv.

Hvad bør ledere gøre nu

Start småt, men mål rigtigt. Vælg 1‑2 processer, hvor output kan verificeres automatisk, og byg en POC på AgentCore eller tilsvarende. Sæt governance op fra dag 1: versionsstyring af prompts og værktøjer, adskilte roller for udvikling og drift, og en simpel change‑advisory, der mødes ugentligt. Og det jordnære: afklar licenser, datalagring og eksport af logs, før første agent får adgang til produktionsdata.

Bagom note