Amazon gør AgentCore-harness i Bedrock generelt tilgængelig og udgiver et open source community‑node til n8n. Pakken @aws/n8n-nodes-agentcore lader dig bygge og køre agenter direkte i n8n’s visuelle editor uden at kode det omgivende agent‑lag. For teams der allerede arbejder i n8n, er det relevant, fordi forskellen mellem et modelkald og en driftbar agent er markant.
AgentCore-harness leverer persistent memory, værktøjsadgang, orchestration‑loop, kontekststyring, state på tværs af turns, fejlgendannelse og sessions‑isolation. n8n‑noden understøtter Amazon Bedrock, OpenAI, Google Gemini og udbydere bag LiteLLM — med mulighed for at skifte provider mellem turns i samme samtale. Det er en reel udvidelse af, hvad man kan bygge i editoren, men efterlader stadig nogle valg og faldgruber, der bør belyses.
Hvad AWS faktisk meldte ud
AgentCore-harness er generelt tilgængelig, og n8n‑noden @aws/n8n-nodes-agentcore er open source under MIT‑licens. Ifølge AWS‑gennemgangen vises et trin‑for‑trin‑flow i n8n. Integrationen udvider n8n’s simple AI Agent‑node ved at eksponere hele harness‑laget, så agenter kan konfigureres, gemmes og genbruges uden at skrive limkode omkring modellerne.
Hvordan n8n‑noden virker i praksis
Noden bruger en enkelt operation styret af feltet Harness ARN. Lader du feltet være tomt, oprettes en agent ved første kørsel, som genbruges og opdateres ved konfigurationsændringer. Indtaster du et eksisterende Harness ARN, peger n8n på en allerede defineret agent, også hvis den er skabt uden for n8n. Det sænker friktionen mellem kode‑ og editor‑arbejde.
Credential‑mønstret ligner det, n8n‑brugere kender fra AWS‑noder: en kaldende identitet i n8n‑credentialen med de nødvendige rettigheder, plus en separat IAM execution‑rolle, som harness’et påtager ved kørsel. AWS fremhæver least‑privilege i AgentCore‑sikkerhedsdokumentationen. Derudover kan agenten køre privat i en VPC, som guiden beskriver. Det kræver dog planlagte netværksstier og styring af egress.
En agent er mere end et modelkald
Et enkelt modelkald uden kontekst, vedvarende hukommelse og værktøjer løser sjældent produktionsopgaver. AgentCore adresserer netop lagene, der ofte mangler i proofs of concept: orchestration‑loop, robust kontekststyring, memory på tværs af samtaler, værktøjs‑adaptere (fx code interpreter eller browser) og fejlgendannelse. AWS viser bl.a., hvordan scoped memory kan bindes til individuelle brugere, og hvordan en code interpreter tilføjes i editoren.
Konsekvensen er, at fokus flyttes fra at bygge motoren til at vælge gearingen: hvilke værktøjer, hvilke instruktioner og hvilken memory‑politik. Små valg med stor effekt i drift.
Multi‑provider og skift mellem turns
At kunne skifte modeludbyder mellem turns åbner for differentieret brug: en hurtig, billig model til simple skridt og en dyrere til svære. I praksis rammer tre ting først: latens (ekstra auth/netværk), konsistens (modeller har forskellig implicit stil) og regnskab (sværere cost‑prognoser, når hvert turn kan have forskellig pris).
Der opstår også et QA‑spørgsmål: Hvordan validerer man kvalitet, når agenten ikke er bundet til én model? En tilgang er at beskrive agentens “skills” som bærbare artefakter, der kan testes og genbruges på tværs af modeller. Det er ikke en garanti for ensartethed, men det hjælper med at holde kompetencer i et lag, der kan måles og versioneres.
Sikkerhed, netværk og data‑privatliv
VPC‑kørsel er et plus, når data skal blive i et kontrolleret miljø, men kræver klare netværksregler, NAT‑strategi for egress og stram styring af, hvilke værktøjer agenten må kalde. Splittet mellem kaldende identitet og execution‑rolle er fornuftigt, forudsat at politikkerne holdes snævre og revideres løbende.
Den åbne dokumentation har huller: graden af granular adgangskontrol for værktøjs‑adaptere, format og omfang af audit‑logs samt standarder for dataretention i session‑filsystem og memory er ikke detaljeret beskrevet. Indtil det er afklaret, bør man antage mindst mulig retention og eksplicit rense eller rotere sessions‑data mellem miljøer.
Observability og drift
Drift kræver end‑to‑end synlighed: fra n8n‑workflow over harness‑loop til værktøjskald og modelsvar. AWS beskriver fejlgendannelse og state på tværs af turns, men går ikke i dybden med logstruktur, idempotence‑nøgler eller metrics‑eksponering til CloudWatch, Prometheus eller Datadog. Det bør adresseres før bredere udrulning.
I mellemtiden: indfør egne korrelations‑id’er i n8n‑workflows, standardisér retrypolitik og sørg for, at værktøjskald kan gentages uden bivirkninger. Test afbrudte kørsler og netværkstidouts, og dokumentér recovery. En agent, der ikke kan genoptage et langt forløb efter små fejl, bliver dyr i support.
Omkostninger og governance
Væsentlige cost‑drivere er modelkald, værktøjskald (især eksterne API’er) samt varighed og størrelse af session‑memory. Provider‑skift kan tilføje overhead. Hvis file‑ og process‑state isoleres per session, kan lange, uafsluttede samtaler give skjulte omkostninger. Hold styr på session‑livscyklus.
Governance kræver performance‑budgetter og revisionsspor fra dag ét. Når agenten kan vælge værktøjer, skifte model og gemme memory, skal grænserne være eksplicitte. Læg simple guardrails i n8n‑flowet: tidsgrænser, maksimum for værktøjskald og en kontrolleret “kill switch”.
Implementeringsvej før pilot
Fristelsen til at installere og køre er stor. Start i stedet med 2–3 workflows, hvor effekten kan måles, og hvor inputdata er kontrollerbare. Vælg opgaver, der faktisk udnytter agent‑funktionerne — ikke bare en chat‑FAQ, hvis problemet er systemkoordinering.
Lav et kort sikkerhedsreview af IAM‑roller, netværk og dataretention. Vælg en observability‑stack. Beslut, hvordan provider‑skift testes og måles. Definér værktøjsadgang: browser, code sandbox, dokumentlager, interne API’er — færre, veldefinerede værktøjer er bedre end for mange halvåbne døre.
- Udpeg 2–3 kandidatarbejdsopgaver med tydelige succeskriterier.
- Kortlæg data og tilladelser. Minimer privilegier i execution‑rollen.
- Opsæt logs, korrelations‑id og basis‑metrics. Beslut retry og timeouts.
- Planlæg tests for provider‑skift og sammenlign output‑kvalitet og pris.
- Definér værktøjer først: browser, code interpreter, API‑plugins. Skær fra.
Hvor POC ofte forveksles med produktion
En demo med et godt svar på en tricky prompt er ikke det samme som drift. Uden vedvarende memory, sikker værktøjsadgang, logging, idempotence og klar fejlhåndtering falder værdien, når opgaven bliver sekventiel og tilstandsfuld. AWS’ gennemgang peger netop på, at harness‑laget er forskellen mellem chat og agent.
Byg derfor CI/CD for prompts og agent‑konfiguration, versionér skills og værktøjer, og gør governance til en del af udviklingscyklussen. Små, faste processer vinder over store, sjældent fulgte processer.
To scenarier hvor Agent
Core i n8n giver mening
Kundesupport med session‑memory: Et n8n‑flow modtager henvendelser, og en AgentCore‑agent holder korttids‑memory pr. kunde over flere interaktioner, slår ordrer op via et API‑værktøj og genererer et løsningsforslag, som en medarbejder godkender. Forbehold: kræv granular audit‑log og klare sletningspolitikker for memory pr. kunde. Test svarskabeloner på tværs af providers ved skift.
Intern dev‑assistent med code interpreter: Agenten kører i en sandboxet interpreter, læser små kodeuddrag fra et repository via et API‑værktøj og foreslår patches, som et separat step kører i CI. Forbehold: hold sandbox stram, undgå adgang til produktionshemmeligheder, og sikr idempotence i patch‑processen for let rollback.
Huller i den offentlige dokumentation
Der mangler uafhængige benchmarks af latens, gennemløb og omkostning for AgentCore‑agenter i n8n versus simple modelkald eller hjemmebyggede agenter. Uden dem er et præcist TCO‑regneark svært. Mål selv i pilot og sammenlign med en baseline uden harness.
Detaljer om adgangskontrol for værktøjs‑adaptere, audit‑logstruktur, rollebaseret adgang og kryptering af session‑filsystem og memory er også sparsomme. Det samme gælder, hvordan logs, metrics og traces lander i CloudWatch, Prometheus eller Datadog, samt VPC‑effekter på egress/ingress og latens. Planlæg konservativt og dokumentér egne kontroller, indtil der foreligger mere.
Hvorfor skills kan blive nyttige i en multi‑provider verden
Når agenter skal fungere på tværs af modeller, bliver placeringen af viden og procedurer central. En pragmatisk vej er at beskrive opgaver som bærbare, testbare skills, der kan flyttes mellem modeller med acceptabelt tab. Det understøtter standardisering af agentkompetencer uden at låse sig til én provider.
Praktisk: skriv skills som versionerede tekstartefakter, test dem og mål kvalitet før og efter provider‑skift. Tørt — men effektivt.
Det betyder noget i hverdagen
For softwarearkitekter flytter AgentCore fokus fra at bygge grundmotor til at vælge konfiguration, værktøjs‑adaptere og governance. For DevOps og drift er n8n‑integrationen en genvej til pilot, men observability, idempotence og fejlhåndtering skal med fra start. For produktejere bliver forskellen mellem POC og produktion tydeligere: uden persistens og værktøjer udebliver gevinster ved komplekse opgaver.
Compliance‑ og sikkerhedsteams vil bemærke MIT‑licensen på n8n‑noden (fri brug) og samtidig, at governance af bagvedliggende tjenester er afgørende. Kræv reviderbare logs og klare retention‑regler, før kundedata rammer agent‑memory. Beslutningstagere får fleksibilitet med multi‑provider, men må håndtere større kompleksitet i cost‑forecasting og QA. Mål både kvalitet og pris.
Konklusion og næste skridt
AgentCore i n8n er et skridt mod produktionsklare agenter uden at sidde fast i limkode. Persistent memory, værktøjer og session‑isolation er grundlæggende, ikke tilvalg. Der er dog åbne spørgsmål om sikkerhed, observability og omkostninger, som bør håndteres i en kontrolleret pilot frem for et big‑bang. Start småt, mål, luk hullerne og skalér derfra.
Lavpraktisk: vælg et workflow, der har brug for tilstand og værktøjer. Sæt stramme IAM‑roller og en enkel observability‑pipeline. Test provider‑skift med samme skill‑sæt og sammenlign kvalitet og pris. Sæt makser for tid og værktøjskald. Erfaringerne lander først, når man kører det i praksis.
