Hvad er en connector? Sådan forbinder du virksomhedens systemer

En connector er en kurateret integration mellem Agent360 og ét bestemt eksternt system — for eksempel jeres CRM, kalender eller mailkonto — der giver AI-agenten sikker, afgrænset adgang til at hente og opdatere data i det system. Agent360 er et internalOS til virksomhedens AI-arbejde, og connectors her er ikke en åben markedsplads: de kommer fra et kurateret registry (35+ connectors), som platformen selv har gennemgået og vedligeholder.

En connector er et stykke færdigbygget software, der forbinder to systemer, så de kan udveksle data automatisk — uden at et menneske skal kopiere oplysninger frem og tilbage. Når jeres CRM automatisk kender den seneste faktura fra økonomisystemet, eller når en aftale i kalenderen automatisk lander som aktivitet på den rigtige kunde, er det en connector, der gør arbejdet. Connectoren håndterer det tekniske — adgang, oversættelse af dataformater og sikkerhed — så I slipper for at bygge forbindelsen selv fra bunden.

Det korte svar er altså: en connector er broen mellem to systemer. Resten af denne artikel forklarer, hvorfor den bro er blevet så vigtig, hvordan den rent faktisk virker (API’er, OAuth og tokens — forklaret så en ikke-teknisk direktør kan følge med), hvad forskellen er på en connector, en integration og et API, og hvad I bør kræve af sikkerhed og GDPR, før I forbinder noget som helst.

Hvad er en connector? Definitionen — kort og præcist

Lad os slå definitionen fast, så den kan stå alene:

En connector er en genanvendelig softwarekomponent, der oversætter mellem ét bestemt system (fx et CRM, et økonomisystem eller en mailkonto) og resten af jeres it-landskab. Den kender systemets sprog — dets API, dets login-metode og dets dataformater — og stiller en ensartet, sikker forbindelse til rådighed, som andre værktøjer kan bruge.

Tænk på en rejseadapter. Jeres franske oplader passer ikke i en engelsk stikkontakt, men adapteren oversætter mellem de to standarder, så strømmen flyder. En connector gør det samme for data: Economic taler ét sprog, HubSpot et andet, Outlook et tredje — og connectoren oversætter, så data kan flyde imellem dem.

De tre ting en connector altid håndterer

En seriøs connector løser tre opgaver, som ellers ville lande på jeres eget bord:

• Adgang: Den logger sikkert ind i systemet på jeres vegne — typisk via OAuth (mere om det senere) — og holder adgangen ved lige, uden at nogen skal gemme kodeord i et regneark.
• Oversættelse: Den kender systemets datamodel. Den ved, at det, ét system kalder en “kontakt”, hedder en “person” i et andet, og at datoformater, valuta og felter skal mappes korrekt.
• Robusthed: Den håndterer det kedelige: hvad sker der, når systemet er nede, når der kommer for mange forespørgsler, eller når adgangen udløber? En god connector fejler pænt og prøver igen — i stedet for at tabe data på gulvet.

Hvorfor ordet “connector” dukker op overalt lige nu

Begrebet er ikke nyt — integrationsplatforme har brugt det i årevis. Men det har fået et markant comeback, fordi AI-agenter har brug for adgang til virksomhedens systemer for at kunne udføre rigtigt arbejde. En AI-assistent, der ikke kan se jeres kalender, CRM eller økonomidata, kan kun snakke. En AI-agent med connectors kan handle: slå kunden op, finde den ubetalte faktura, skrive udkastet til opfølgningsmailen og lægge mødet i kalenderen. Connectoren er dermed blevet forudsætningen for, at AI bevæger sig fra “chatbot” til “kollega”. Hvis du vil have baggrunden for, hvad den slags automatisering betyder i praksis, har vi skrevet en grundig introduktion i hvad er CRM-automatisering.

Problemet: virksomhedens data bor i siloer

Før vi går dybere ned i teknikken, er det værd at forstå, hvorfor connectors overhovedet er nødvendige. Svaret er datasiloer — og stort set alle virksomheder har dem.

Sådan opstår siloerne

Ingen beslutter sig en morgen for at bygge datasiloer. De opstår gradvist og af helt fornuftige grunde:

• Salg vælger et CRM, fordi det er godt til pipeline og kundedialog.
• Bogholderiet vælger et økonomisystem, fordi det er godt til fakturaer og moms.
• Alle bruger mail og kalender, fordi det er der, hverdagen foregår.
• Lager eller drift kører måske i et ældre fagsystem eller et regneark, fordi “det virker jo”.

Hvert valg er rigtigt isoleret set. Problemet er, at systemerne aldrig blev bedt om at tale sammen. Kundens navn findes nu fire steder, i fire staveformer, med fire forskellige opdateringsdatoer — og ingen af systemerne ved, hvad de andre ved.

Hvad siloerne koster i hverdagen

Omkostningen viser sig sjældent som ét stort tal på bundlinjen. Den viser sig som friktion, der æder tid og skaber fejl:

• Dobbeltindtastning: Den samme ordre tastes i CRM’et, i økonomisystemet og måske i et regneark. Hver indtastning er en chance for en fejl.
• Forældede oplysninger: Sælgeren ringer til en kunde, der har en ubetalt rykker liggende — men det står kun i økonomisystemet, som sælgeren ikke kigger i.
• Ingen samlet kundehistorik: Hvad har kunden købt, spurgt om, klaget over og betalt? Svaret er fordelt over indbakker, systemer og hukommelser.
• Beslutninger på mavefornemmelse: Når data ikke kan samles, bliver ledelsesrapportering til håndarbejde — eller til gæt.

Siloproblemet forstærkes af dårlig datadisciplin: dubletter, forældede kontakter og halvtomme felter gør enhver integration sværere. Derfor hænger connectors og datakvalitet tæt sammen — vi har samlet de praktiske råd i vores guide til CRM-datahygiejne. Rens gerne op, før I forbinder systemerne; ellers synkroniserer I bare rodet hurtigere rundt.

Hvordan en connector virker — API’er, OAuth og tokens forklaret folkeligt

Nu til maskinrummet. Du behøver ikke kunne programmere for at forstå, hvordan en connector virker — tre begreber rækker: API, OAuth og tokens.

API’et: systemets betjente indgang

Et API (Application Programming Interface) er den officielle, betjente indgang til et system — bygget til maskiner i stedet for mennesker. Hvor du selv logger ind i økonomisystemet via en hjemmeside og klikker rundt, kan et andet program bruge API’et til at stille præcise spørgsmål og få præcise svar: “Giv mig alle fakturaer for kunde X” eller “Opret denne kontakt”.

En god måde at tænke på det: hjemmesiden er butikkens indgang for kunder; API’et er varemodtagelsen bagved, hvor leverandører afleverer og henter varer efter faste regler. Alle moderne forretningssystemer — CRM, økonomi, mail, kalender, lager — har i dag et API. Connectoren er det program, der kender netop dét API ud og ind.

OAuth: nøglekortet i stedet for hovednøglen

Når en connector skal have adgang til jeres systemer, er det afgørende hvordan den får adgang. Den gammeldags metode var at give programmet et brugernavn og et kodeord — altså hovednøglen til hele huset. Det er en dårlig idé af tre grunde: kodeordet giver adgang til alt, det udløber ikke af sig selv, og hvis det lækkes, skal det skiftes alle steder.

OAuth er den moderne løsning, og du har brugt den mange gange uden at tænke over det — hver gang du har klikket “Log ind med Google” eller godkendt, at en app må se din kalender. OAuth virker som et nøglekort på et hotel:

• Du (ejeren af systemet) godkender én gang, at connectoren må få adgang.
• Du bestemmer, hvilke døre kortet åbner — måske kun “læse kalender”, ikke “slette mails”.
• Kortet kan spærres når som helst, uden at du skal skifte din egen kode.
• Connectoren ser aldrig dit kodeord. Den får kun kortet.

Tokens: adgangsbeviser med udløbsdato

Det “nøglekort”, OAuth udsteder, hedder i teknisk sprog et token — en lang, tilfældig tekststreng, der fungerer som adgangsbevis. To egenskaber gør tokens fornuftige:

• De er afgrænsede: Et token giver kun adgang til det, der blev godkendt (de såkaldte scopes) — fx “læs kontakter” men ikke “slet kontakter”.
• De udløber: Adgangstokens har typisk kort levetid og fornys automatisk via et såkaldt refresh-token. Lækkes et token, er skaden tidsbegrænset, og adgangen kan trækkes tilbage centralt.

Sæt de tre begreber sammen, og billedet er komplet: connectoren bruger API’et (den betjente indgang) med et token (nøglekortet), som I har udstedt via OAuth (godkendelsesproceduren). Det er hele hemmeligheden — resten er håndværk.

Hvad sker der, når noget går galt?

En undervurderet del af en connectors arbejde er fejlhåndtering. Systemer er nede engang imellem, API’er sætter grænser for, hvor mange forespørgsler man må sende i minuttet, og tokens udløber. En professionel connector håndterer alt dette: den venter og prøver igen ved midlertidige fejl, den respekterer systemets grænser, og den siger tydeligt til, hvis en adgang skal fornys. Det er præcis den slags arbejde, ingen har lyst til at bygge og vedligeholde selv for hvert eneste system.

Connector vs. integration vs. API: begreberne adskilt

De tre ord bruges ofte i flæng, og det skaber forvirring i både indkøb og ledelsesmøder. Her er den rene udgave: API’et er systemets indgang, connectoren er den genanvendelige byggeklods, der bruger indgangen, og integrationen er det samlede, konkrete flow, I bygger med byggeklodserne.

Connector, integration og API — hvad er hvad?

Begreb	Hvad er det?	Hverdagsbillede	Hvem leverer det?
API	Systemets officielle, maskinvendte indgang: faste regler for at hente og sende data.	Varemodtagelsen bag butikken — med faste regler for aflevering.	Systemleverandøren (CRM'et, økonomisystemet, mailudbyderen).
Connector	Færdigbygget komponent, der kender ét systems API, login (OAuth) og datamodel — klar til genbrug.	Rejseadapteren, der passer til netop dét stik.	Integrationsplatformen eller AI-platformen (fx en platform med et kurateret udvalg af connectors).
Integration	Det konkrete, samlede flow mellem to eller flere systemer — bygget oven på connectors.	Hele el-installationen: adaptere, ledninger og den lampe, der faktisk lyser.	Jer selv, en partner eller platformen — konfigureret til jeres behov.

En praktisk konsekvens af skellet: når en leverandør siger “vi har en integration til X”, så spørg, om der menes en connector (byggeklodsen findes, men flowet skal stadig bygges) eller en færdig integration (flowet virker fra dag ét). Forskellen kan være uger af projektarbejde.

Eksempler på hverdags-flows der kræver connectors

Teori er godt — men connectors bliver først interessante, når man ser, hvad de muliggør i en almindelig arbejdsuge. Her er tre genkendelige flows.

Fra kundemøde til opdateret CRM

Et klassisk hul i de fleste virksomheder: mødet bliver holdt, men CRM’et får aldrig besked. Med connectors til kalender, mail og CRM kan flowet se sådan ud:

1. Mødet ligger i kalenderen med kundens mailadresse som deltager.
2. Kalender-connectoren registrerer, at mødet er afholdt.
3. CRM-connectoren finder kunden og logger mødet som aktivitet.
4. Mail-connectoren finder den seneste korrespondance, så opfølgningen har kontekst.
5. Et udkast til opfølgningsmail ligger klar — et menneske godkender og sender.

Ingen af delene er magi. Det er tre connectors og et veldefineret flow. Vil du se, hvordan den slags flows hænger sammen med hele salgsprocessen, går vi i dybden i vores komplette guide til automatisering af salgsprocesser.

Fakturaopfølgning på tværs af økonomisystem og mail

Endnu et hul, næsten alle kender: fakturaen er sendt, betalingen udeblev, og ingen opdagede det, før kvartalet var slut. Med en connector til økonomisystemet og en til mail:

1. Økonomi-connectoren ser, at faktura 1042 er forfalden.
2. CRM-connectoren slår kunden op: er der en aktiv dialog eller en åben sag, man bør kende, før man rykker?
3. Et venligt rykkerudkast genereres med de rigtige fakturaoplysninger.
4. Et menneske godkender — og opfølgningen logges på kunden i CRM’et.

Bemærk mønsteret: connectoren henter og samler; mennesket beslutter. Det er den arbejdsdeling, der gør automatisering tryg.

Lagerstatus, ordrer og kundeservice

Kunden ringer: “Hvor bliver min ordre af?” Uden connectors betyder det tre systemer åbne på skærmen og lange tastaturpauser i røret. Med connectors til ordresystem, lager og mail kan en medarbejder — eller en AI-agent, der forbereder svaret til medarbejderen — samle billedet på sekunder: ordren findes, varen er på lager, forsendelsen er afsted, og track-and-trace-nummeret ligger i den mail, der blev sendt i tirsdags. Det samlede overblik på tværs af systemer er i øvrigt hele grundtanken i moderne revenue operations — den disciplin har vi beskrevet i Revenue Operations-guiden.

Sikkerhed: hvad I skal kræve, før I forbinder noget

Connectors åbner døre ind til jeres mest følsomme data. Derfor er sikkerhedskravene ikke et appendiks — de er halvdelen af beslutningen. Her er de fire krav, I bør stille til enhver leverandør.

Kryptering af tokens og data

Tokens er nøglekort, og nøglekort skal opbevares i et pengeskab — ikke i en skuffe. Kræv, at:

• Tokens opbevares krypteret (ikke i klartekst i en database eller en konfigurationsfil).
• Al trafik mellem connector og system sker over krypterede forbindelser (TLS/HTTPS).
• Leverandøren kan svare klart på, hvor tokens opbevares, hvem der kan tilgå dem, og hvordan de roteres.

Kan leverandøren ikke svare præcist på de tre spørgsmål, er det et advarselstegn i sig selv.

Mindst-mulig-adgang (least privilege)

Princippet er enkelt: en connector skal kun have adgang til præcis det, den skal bruge — hverken mere eller længere. I praksis betyder det:

• Afgrænsede scopes: Skal flowet kun læse kalenderen, skal tokenet kun kunne læse kalenderen. “Fuld adgang, det er nemmest” er en fælde.
• Adgang pr. formål: Undgå én samlekonto med adgang til alt. Adskil adgange, så de kan trækkes tilbage enkeltvis.
• Synlighed: I skal kunne se en liste over aktive adgange — hvilke connectors har adgang til hvad — og kunne spærre hver enkelt med det samme.

GDPR og databehandleraftaler

Så snart en connector flytter personoplysninger — og det gør den næsten altid, for kundedata er personoplysninger — er I inde i databeskyttelsesreglerne. To roller er afgørende at få på plads: I er som virksomhed typisk dataansvarlig (I bestemmer formålet med behandlingen), mens leverandøren af integrationsplatformen typisk er databehandler (den behandler data efter jeres instruks). Datatilsynet forklarer rollefordelingen og kravet om en databehandleraftale i deres vejledning om dataansvarlig og databehandler — og pointerer, at ansvaret ikke stopper ved underskriften: I skal også føre tilsyn med, at databehandleren lever op til aftalen.

De overordnede GDPR-krav til virksomheder — hvornår reglerne gælder, hvad der tæller som personoplysninger, og hvilke rettigheder de registrerede har — er samlet i EU’s officielle gennemgang af databeskyttelsesreglerne for virksomheder. Minimum for jer, før en connector sættes i drift:

• Databehandleraftale på plads med leverandøren, før persondata flyder.
• Klarhed over datastrømme: Hvilke oplysninger flyttes, hvorhen, og opbevares der kopier undervejs?
• Placering af data: Behandles data i EU/EØS, eller overføres de til tredjelande — og på hvilket grundlag?
• Sletning: Hvad sker der med data (og tokens), når samarbejdet stopper?

Arbejder I med AI oven på jeres kundedata, kommer der desuden et ekstra regelsæt i spil — det har vi gennemgået i artiklen om EU AI Act og salg i danske virksomheder.

Kontrol og revision

Sidste krav: sporbarhed. I skal kunne svare på “hvem gjorde hvad, hvornår?” — også når “hvem” er en connector. Kræv logning af, hvilke handlinger der er udført gennem hvilke adgange, og mulighed for at gennemgå det bagefter. Uden log er fejlsøgning gætværk, og compliance-samtaler bliver ubehagelige.

iPaaS og integrationsplatforme vs. AI-agent med connectors

Når I har besluttet, at systemerne skal forbindes, står valget typisk mellem to arkitekturer — og det er værd at forstå begge, for de udelukker ikke hinanden.

Den klassiske vej: iPaaS og integrationsplatforme

En iPaaS (integration Platform as a Service — fx Zapier, Make eller Workato) er en platform, hvor man bygger flows af typen “når X sker i system A, så gør Y i system B”. Styrkerne er reelle:

• Modenhed: Kategorien har eksisteret længe, og platformene har connectors til hundredvis af systemer.
• Forudsigelighed: Et flow gør præcis det, det er tegnet til — hver gang. Det er en styrke, når opgaven er fast og regelbaseret.
• Lav indgangsbarriere: Simple flows kan bygges uden udviklere.

Svaghederne følger af samme design: hvert flow skal tegnes på forhånd. Virkeligheden er sjældent så pæn — undtagelser, tvetydige data og opgaver, der kræver et skøn, passer dårligt ind i faste kasser. Mange virksomheder ender med et voksende landskab af små flows, som ingen har det fulde overblik over, og som knækker stille, når et system ændrer sig.

Den nye vej: AI-agent med connectors

Alternativet — eller supplementet — er en AI-agent, der har connectors som sine “hænder”. Forskellen i tankegang er væsentlig:

• En iPaaS udfører foruddefinerede flows. En AI-agent får et mål (“følg op på forfaldne fakturaer hos aktive kunder”) og bruger selv de relevante connectors til at samle information og foreslå handlinger.
• En iPaaS stopper, når virkeligheden afviger fra tegningen. En agent kan håndtere variation — og eskalere til et menneske, når den er i tvivl.
• En iPaaS kræver, at nogen vedligeholder hvert flow. En agent samler logikken ét sted, hvor den kan overskues og styres.

Det afbalancerede svar: har I en fast, høj-volumen, regelbaseret opgave, er en klassisk integration eller iPaaS stadig et glimrende valg. Har I opgaver, der kræver kontekst på tværs af systemer og et skøn undervejs, er en AI-agent med connectors det stærkere værktøj. Mange virksomheder ender fornuftigt med begge dele.

Sådan ser det ud hos Agent360

Hos Agent360 er connectors en kernedel af platformen: virksomhedens AI-platform i én IDE, med 35+ connectors til de systemer, danske virksomheder faktisk bruger — CRM, økonomi, mail, kalender og flere. Tre arkitekturvalg er værd at kende, fordi de adresserer præcis de bekymringer, denne artikel har rejst:

• Egen instans og egen database pr. virksomhed — jeres data blandes ikke med andres, og self-host er muligt for dem, der vil have det hele inden for egne mure.
• App-model med et kurateret registry — connectors og apps kommer fra et gennemgået udvalg, ikke et åbent tag-selv-bord. Det gør sikkerhedsvurderingen overskuelig.
• Fair source-licens — ægte open source efter to år — koden kan efterses, og I er ikke låst til en lukket sort boks.

Selve agenten bygger på Claude, og arbejdsdelingen er den samme som i eksemplerne ovenfor: agenten samler og forbereder via connectors; mennesket godkender det, der betyder noget.

Tjekliste: når I vurderer integrations-muligheder

Til sidst det praktiske. Print denne liste, og brug den, næste gang en leverandør siger “vi integrerer med alt”:

1. Findes connectoren til netop jeres systemer? Ikke “et lignende system” — jeres. Tjek også jeres version/udgave (cloud vs. lokalt installeret gør en forskel).
2. Connector eller færdig integration? Er det en byggeklods, eller virker flowet fra dag ét? Hvad kræver det at komme fra det ene til det andet?
3. Hvordan gives adgang? OAuth med afgrænsede scopes er standarden. Kræver leverandøren brugernavn/kodeord til jeres systemer, er det et rødt flag.
4. Hvordan opbevares tokens? Krypteret, med klare svar på hvor, hvem og hvordan de roteres og spærres.
5. Kan I se og styre adgange centralt? Én oversigt over alle aktive connectors og deres rettigheder — med mulighed for at trække hver enkelt tilbage øjeblikkeligt.
6. Er GDPR-fundamentet på plads? Databehandleraftale, klarhed over datastrømme og -placering, sletterutiner. Rollefordelingen (dataansvarlig/databehandler) skal være aftalt på skrift.
7. Hvad sker der ved fejl? Prøver connectoren igen? Får I besked? Kan data gå tabt undervejs — og hvordan opdager I det?
8. Er der log og sporbarhed? “Hvem gjorde hvad, hvornår” skal kunne besvares — også for automatiserede handlinger.
9. Hvem holder connectoren ved lige? API’er ændrer sig. Er det leverandørens ansvar at følge med — eller jeres problem, når noget knækker?
10. Er der en exit? Kan I komme ud igen med jeres data og uden at skulle genopbygge alt? Self-host-mulighed og åben kildekode er her konkrete forsikringer.

Kan en leverandør svare klart på alle ti punkter, er I i gode hænder. Kan de ikke, har I lige sparet jer selv for et dyrt projekt.

Ofte stillede spørgsmål om connectors

Er en connector det samme som en app eller et plugin?

Ikke helt. Et plugin udvider ét program med ny funktionalitet inde i programmet (fx en stavekontrol i din browser). En connector forbinder to adskilte systemer, så data kan flyde imellem dem. I nogle platforme leveres connectors ganske vist som "apps", man installerer — men funktionen er broen mellem systemer, ikke en ny knap i ét system.

Skal vi kunne programmere for at bruge connectors?

Nej — det er netop pointen. Connectoren er bygget, så det tekniske (API-kald, OAuth, dataformater, fejlhåndtering) er pakket væk. Jeres opgave er at godkende adgangen (typisk et par klik i et login-vindue) og beslutte, hvilke flows der skal bruge den. Kompleksiteten flytter fra jeres it-afdeling til leverandøren af connectoren — og det er dér, den hører hjemme.

Er det sikkert at give en connector adgang til vores systemer?

Det kan det sagtens være — hvis grundprincipperne overholdes: adgang via OAuth (aldrig delte kodeord), tokens opbevaret krypteret, mindst-mulig-adgang (kun de nødvendige rettigheder), en databehandleraftale på plads og mulighed for at spærre adgangen øjeblikkeligt. En connector med afgrænsede, sporede rettigheder er i praksis ofte sikrere end alternativet: medarbejdere, der deler kodeord og kopierer data manuelt mellem systemer.

Hvad sker der, hvis vi opsiger samarbejdet med en connector-leverandør?

Tre ting skal ske: adgangene (tokens) skal trækkes tilbage i jeres systemer, leverandøren skal slette de data og adgangsbeviser, de opbevarer — det skal databehandleraftalen forpligte dem til — og I skal have jeres konfiguration og data med ud i et brugbart format. Spørg til alle tre før I skriver under, ikke når I skal ud. Exit-vilkår er billigst at forhandle, mens alle stadig er venner.

Vores systemer er gamle — kan de overhovedet forbindes?

Ofte ja. De fleste systemer, også ældre, har en eller anden form for maskinadgang: et API, en database, filudveksling eller eksport/import. En connector kan bygges oven på flere af disse veje, selvom moderne API'er med OAuth er det klart bedste udgangspunkt. Det ærlige svar er dog: jo ældre og mere lukket systemet er, desto mere håndarbejde kræver forbindelsen — og i nogle tilfælde er systemskiftet den rigtige investering frem for en skrøbelig bro til et døende system.

Hvor mange connectors har vi brug for?

Færre end du tror. Start med de tre-fire systemer, hvor hverdagens friktion er størst — typisk CRM, økonomisystem, mail og kalender. Alene de fire dækker de fleste af de flows, der er beskrevet i denne artikel: mødeopfølgning, fakturaopfølgning og samlet kundehistorik. Udvid derefter efter behov i stedet for at forbinde alt fra dag ét. Hver connector er en adgang, der skal styres — så forbind med omtanke, ikke pr. refleks.

Konklusion: connectoren er broen — og broer skal bygges ordentligt

En connector er hverken magi eller marketing: det er en veldefineret softwarekomponent, der giver sikker, afgrænset og vedligeholdt adgang til jeres systemer, så data kan flyde derhen, hvor arbejdet foregår. Datasiloerne forsvinder ikke af sig selv, og alternativet til connectors — manuel dobbeltindtastning og kodeord i regneark — er både dyrere og mere usikkert.

Det vigtigste at tage med herfra: forstå forskellen på API, connector og integration, når I taler med leverandører; kræv OAuth, krypterede tokens og mindst-mulig-adgang som en selvfølge; få databehandleraftalen på plads, før persondata flyder; og vælg arkitektur efter opgaven — fast flow til faste opgaver, AI-agent med connectors til opgaver, der kræver kontekst og skøn. Med tjeklistens ti spørgsmål i hånden er I klædt bedre på end de fleste indkøbsafdelinger.