Agenter i Business Central: Er det prototype eller produktion?

Denne status pr. 3. juni 2026. Microsoft opdaterer agent-roadmap ret ofte, så tjek deres release plan for at være sikker. Eller bare ræk ud til os, så undersøger vi og vender tilbage.

Der bliver talt meget om agenter i Business Central lige nu og hvis du åbner din LinkedIN, så flyder det nærmest over med cases og webinarer. Men det pudsige er, at ordet bruges om vidt forskellige ting. Nogle mener Microsofts færdige Sales Order Agent. Andre mener det nye værktøj hvor man selv klikker en agent sammen uden en eneste linje kode. Og en tredje gruppe tænker på noget de så i en demo engang og aldrig rigtig fik placeret. Så når en kunde læner sig frem og siger “Vi vil gerne have en agent”, er mit første svar altid spørgsmål.

Hvad skal være på plads

Begge færdige agenter kræver et minimum af setup men alligevel nogle detaljer:

• Business Central-version skal understøtte agenter (Payables Agent kræver et understøttet land og DK er med fra 9. januar 2026)
• En delt postkasse (Microsoft 365) som agenten kan overvåge. Sales Order Agent skal også kunne sende som postkassen
• Read and manage (Full Access)-rettigheder på postkassen skal laves for de brugere, som aktiverer agenten
• Billing model sat op i Business Central Admin Center. Du kan vælge enten pay-as-you-go via Azure eller en Copilot Credit Pack
• Permissions skal opsættes i BC: SOA AGENT – EDIT (Sales Order) eller tilsvarende kan bruges

Hvad en agent egentlig er

En agent i Business Central er en autonom, AI-drevet aktør som arbejder inde i systemet nogenlunde på samme måde som et menneske gør. Den læser data, navigerer mellem sider, udfylder felter og kalder actions. Det vigtige er at den gør det gennem brugerfladen, ikke gennem en klassisk integration i baggrunden. Microsoft kalder det den logiske UI-API: agenten ser hvad der står på siderne, henter metadata som captions og tooltips, kombinerer det med sine instruktioner og bruger AI til at regne ud hvilke skridt der skal til for at løse opgaven. Skridtene er altså ikke hardkodet på forhånd, de besluttes undervejs. Det er ret smart, og det er også derfor den kan gå galt på måder en almindelig integration aldrig ville. Det er nemlig her udviklerne begynder at stille de sværere spørgsmål.

Tre ting definerer en agent. Den har instruktioner, altså naturligt sprog som beskriver hvad den skal og hvordan den skal opføre sig. Den får tasks, som er måden man trigger den på. Og den kører som sin egen bruger i Business Central med sit eget permission set og en profil (rollen) som bestemmer hvilke sider, felter og handlinger den overhovedet kan se. Den sidste detalje er vigtigere end den lyder.

En agent har sit eget bruger-ID, og alt hvad den foretager sig dukker op i historik, bogførte bilag og notifikationer præcis som om en kollega havde gjort det.

Rettighederne er værd at stoppe op ved et øjeblik⁹. Når en bruger sætter en opgave i gang for en agent, kører opgaven med snittet mellem brugerens rettigheder og agentens egne. Kan agenten godt slette debitorer, men brugeren ikke? Så bliver der ikke slettet noget. En agent kan med andre ord aldrig få mere end den person som sætter den i gang, og hvis agenten undervejs beder om hjælp, overtager rettighederne fra den som svarer på anmodningen (det kan godt være en anden end den der startede opgaven). Det er en pæn, stram sikkerhedsmodel, og den er bevidst lavet sådan.

Og så er der mennesket i loopet. Agenter sender notifikationer, fører en tidslinje over hvert skridt de tager, viser deres ræsonnement og beder om godkendelse før de gør noget vigtigt. Alle udgående beskeder kræver som udgangspunkt et review. Det er ikke en tilfældighed. Microsoft vil ikke have agenter som poster eller sender ud i verden uden at et menneske har set efter.

De tre slags agenter

Business Central skelner mellem tre oprindelser, og de har hver sit lille ikon i klienten. Førsteparts-agenter er bygget og udgivet af Microsoft. Tredjeparts-agenter kommer fra en extension, typisk noget man har hentet på Marketplace. Og custom-agenter er dem man selv laver med det nye agent design-værktøj. Den sondring lyder akademisk⁸, men den er faktisk nøglen til hele spørgsmålet om prototype kontra produktion, fordi de tre kategorier slet ikke er lige modne.

Hvilke agenter findes der i forvejen

Færdige, generelt tilgængelige agenter fra Microsoft er der præcis to af lige nu. Bevares, det lyder ikke af meget, men de to dækker hver sin tunge proces.

Den første er Sales Order Agent, Microsofts første out-of-the-box-agent¹. Den overvåger en delt firmapostkasse, læser kundens mail (inklusive PDF- og billedvedhæftninger), identificerer kunden, tjekker varetilgængelighed, laver et tilbud som PDF, kører en mailafklaring frem og tilbage med kunden og konverterer det godkendte tilbud til en salgsordre. Hver eneste udgående mail skal godkendes af et menneske. Den er generelt tilgængelig, altså produktion, og står da også under “Generally available” på siden med Copilot- og agent-kapabiliteter. En enkelt underfunktion, selve tjekket af varetilgængelighed, er stadig markeret som production-ready preview², men agenten som helhed er GA.

Den anden er Payables Agent, en agent til kreditorbogholderiet³. Den overvåger en postkasse for fakturavedhæftninger, trækker fakturadata ud via Azure Document Intelligence, matcher leverandøren, foreslår konteringer, matcher mod indkøbsordrer og varemodtagelser og laver kladder til indkøbsfakturaer som en supervisor så gennemgår. Vigtig detalje: den laver kun kladder. Den bogfører aldrig selv og rører aldrig ved økonomidata på en irreversibel måde uden eksplicit godkendelse. Payables Agent var i public preview fra 4. juli 2025 (med 26.3-opdateringen) i USA, Storbritannien, Australien og New Zealand, og blev generelt tilgængelig 7. november 2025⁴. Danmark kom først med i januar 2026⁵, da Microsoft udvidede til Canada, Tyskland, Italien, Frankrig, Spanien og os. Så ja, vi kan bruge den i produktion herhjemme nu. Det er nyt, og det er værd at have med.

Lad mig gøre det konkret med et tænkt eksempel. Forestil dig en handelsvirksomhed som får tre-fire hundrede leverandørfakturaer ind om måneden, mange af dem som PDF’er i en fællespostkasse. I dag sidder en bogholder og taster dem ind, finder den rigtige leverandør, gætter konteringen og matcher mod indkøbsordren. Payables Agent kan tage førsteudkastet på dem alle: trække data ud, foreslå leverandør og kontering, matche mod ordre og varemodtagelse, og lægge en kladde klar. Bogholderen går fra at taste til at gennemgå. Det fjerner ikke mennesket, det flytter mennesket fra indtastning til kontrol. Og det er lige præcis sådan en grim, gentaget proces hvor en agent giver mening, frem for de skæve enkelttilfælde hvor den alligevel ville bede om hjælp hvert andet minut.

Alt det andet man støder på under overskriften “AI i Business Central” er som regel Copilot-funktioner, ikke selvstændige agenter. E-document matching med Copilot, bankafstemning, Analysis Assist, chat med Copilot, marketing text og så videre. Nyttige sager, men ikke autonome agenter. Og den “Sales Validation Agent” man kan falde over i dokumentationen er ikke et produkt. Det er en skabelon i prototyping-værktøjet som man selv bygger videre på. Værd at vide, så man ikke kommer til at tælle den med som om den var noget færdigt man bare kunne tænde for.

Hvad koster det?

Begge BC agenter betales pr. forbrug via Copilot Credits. Det er Microsofts måleenhed for AI-forbrug på tværs af Copilot Studio og er — ærligt talt — ikke så transparent som man kunne ønske sig. Pay-as-you-go-prisen er dog ca. $0,01 per credit, hvilket gør det nemt at regne på.

Microsofts egne eksempler⁶ ser sådan her ud:

• Sales Order Agent: 100 mailforespørgsler om måneden (hvor halvdelen har sales-data i vedhæftningen) ≈ 1.650 credits ≈ ca. $16,50 pr. måned. Altså cirka 115 kr. Til at overskue.
• Payables Agent: 100 indkommende fakturaer med 3 linjer i gennemsnit ≈ 6.500 credits ≈ ca. $65 pr. måned. Cirka 450 kr.

Bruger I 25.000+ credits om måneden konsekvent, bliver Microsofts prepaid Copilot Credit Pack ($200/måned for 25.000 credits) billigere pr. credit. Indtil da er pay-as-you-go nok en fin start via en Azure-subscription og det er nemmeste sted at starte.

Så: prototype eller produktion?

Her bliver det lidt rodet, og her modsiger Microsofts egen dokumentation faktisk sig selv. Det ærlige svar er: begge dele, alt efter hvad du taler om.

De to færdige Microsoft-agenter er produktion. Det er afklaret, og det behøver vi ikke bruge flere ord på.

Værktøjet til selv at bygge en agent uden kode, altså AI development toolkit eller agent designeren⁷, er en anden sag. Det er stadig preview og kun til sandbox. Det kræver version 27.2, og her ligger fælden: den generiske preview-banner øverst på hver dokumentationsside siger at funktionen “er supporteret i produktionsmiljøer”, mens den funktionsspecifikke tekst længere nede siger det stik modsatte. Sandbox only, står der, “available exclusively in sandbox environments; never in production”. Banneren er standard preview-boilerplate som Microsoft hælder på alle preview-sider. Teksten længere nede er den som faktisk gælder. Jeg faldt selv i den fælde første gang og brugte et stykke tid på at lede efter en deploy-knap der ikke findes. Så hvis nogen siger “jeg har bygget en agent i designeren, kan vi ikke bare sætte den i drift hos kunden”, er svaret nej. Ikke endnu.

Vejen til produktion med en custom-agent går gennem AL-kode. Agent SDK’et, hvor man koder agenten i en extension, har kunnet bruges til sandbox-evaluering siden version 27.4, og fra version 28.1 er produktionsmiljøer også understøttet¹⁰. Det er en anden disciplin end at klikke i designeren (og ærligt talt en del mere arbejde), men det er der man rent faktisk kan levere noget til en kunde i drift. De to ting hænger heldigvis sammen: man kan prototype hurtigt i designeren, eksportere agenten og bygge den færdig i AL. Prototypen ender med at være kravspecifikationen, og det er faktisk en ret behagelig måde at arbejde på.

Hvis nogen spørger hvad de skal starte med, er mit råd som regel kedeligt: tag en af de to færdige agenter først. Sales Order Agent hvis I drukner i tilbudsforespørgsler på mail, Payables Agent hvis kreditorbunken vokser. De er færdige, de er i drift, og I lærer hvordan et agent-flow opfører sig i jeres egne data uden at skulle bygge en linje selv. Designeren og AL-koden kommer i spil bagefter, når I har fundet en proces som de færdige agenter ikke rammer, og som er grim nok og hyppig nok til at det er værd at putte udviklingstimer i.

Mit take er at hele den her forvirring er værd at holde styr på, for den afgør hvad man kan love. Microsofts to agenter: produktion, brug dem nu. Designeren: et prototype- og læringsværktøj i sandbox, intet andet. AL-kodede agenter: vejen til produktion, fra 28.1. Så når kunden læner sig frem og siger “vi vil gerne have en agent”, skal du ikke svare ja eller nej med det samme. Du skal stille modspørgsmålet: hvilken af de tre virkeligheder står du i? Resten af samtalen, og hele overslaget, afhænger af svaret.

---

Kilder

1. Microsoft Learn, Sales Order Agent. ↩︎
2. Microsoft Learn, Item availability in Sales Order Agent (production-ready preview). ↩︎
3. Microsoft Learn, Payables Agent. ↩︎
4. Microsoft, Release plan: Payables Agent (preview 4. juli 2025 / GA 7. november 2025). ↩︎
5. Microsoft, Use Payables Agent in more countries and regions (Danmark fra 9. januar 2026). ↩︎
6. Microsoft Learn, Manage consumption-based billing for agent capabilities. ↩︎
7. Microsoft Learn, Designing and coding agents (overview). ↩︎
8. Microsoft Learn, Create and activate an agent (agent-ikoner og de tre oprindelser). ↩︎
9. Microsoft Learn, Set up agent permissions and profiles (effektive rettigheder = snit). ↩︎
10. Microsoft Learn, Coding agents in AL (Agent SDK, sandbox fra 27.4 / produktion fra 28.1). ↩︎