Siden Microsoft annoncerede Agent Builder Playground på BCTechDays 2025, har der hersket en del forvirring blandt BC-partnere om, hvad man egentlig kan med custom agents i Business Central. Forvirringen er forståelig. Når man kombinerer målgruppen (konsulenter, product owners, specialister) med beskeden “Create new agents”, er det naturligt at tænke: endelig et low-code agent-værktøj, vi kan deploye til produktion.
Men det er ikke. Alligevel er det, det i virkeligheden er, mindst lige så interessant.
I artiklen gennemgår jeg, hvad Agent Design Experience er, hvordan agenter teknisk fungerer i Business Central, og hvad der skal til for at bringe en agent fra sandbox til produktion. Undervejs trækker jeg lidt på Microsofts dokumentation, community-blogs og konkrete erfaringer fra partnere, der har haft hands-on adgang.
Hvad er en agent i BC-sammenhæng?
Forskellen er vigtig at forstå, inden man kaster sig over designeren.
En Copilot svarer på spørgsmål. Den kalder en LLM og kan køre forskellige tools. En agent kalder også en LLM og kører tools, men den gør det i et loop, indtil opgaven er fuldført, eller til der kræves et menneskelig input.
I Business Central betyder det, at agenten logger ind, navigerer, filtrerer, åbner og lukker sider. Præcis som en almindelig, menneskelig bruger. Agenten opererer i det logiske UI-lag, mellem HTML og BC-serveren og den ser kun det, som den tildelte profil og rolle viser: Kolonner, felter, handlinger og de poster, der er synlige på siden.
Det har en lidt sjov, praktisk konsekvens. Agenten ser ikke alle 10.000 bogførte salgsfakturaer i dit system. Den ser det, siden viser i BC – og heldigvis kan den scrolle.
Arkitekturen bag Agent Runtime
Microsofts release plan beskriver den arkitektoniske strategi i detaljer, og der er tre punkter, der er værd at forstå:
Agent runtime er fundamentet. De samme runtime-kapaciteter, der driver de indbyggede Sales Order Agent og Payables Agent, er tilgængelige for custom agents. Runtime sikrer, at hvert trin er sporbart, at adgangsrettigheder som du laver i BC håndhæves, og at brugeren holdes inde i løkken via human-in-the-loop godkendelser.
Intern eksekvering og ekstern orkestrering er adskilt. BC-agenter er det dybe, kontrollerede eksekveringslag inde i produktet. I fremtiden vil BC-agenternes kapaciteter kunne eksponeres som MCP-tools og bruges af Declarative Agents i Copilot Studio og Microsoft 365. Det lagdelte design betyder, at BC håndterer den ERP-specifikke eksekvering alt imens orkestrering på tværs af systemer sker i højere lag.
Så det vil sige, at agenter er reelle brugere. De har almindelige permission sets, og de rettigheder er så snitfladen mellem agentens permission sets og den menneske-bruger, der trigger agenten. Mangler én af dem adgang, kan agenten ikke agere. Det er ikke en begrænsning som sådan. Det er en bevidst sikkerhedsmodel, som ikke er så dum endda.
Hvad Agent Design Experience IKKE er
Lad os starte med at rydde nogle misforståelser af vejen.
Agent Design Experience er (desværre) ikke en low-code agent, der kan deployes til produktion. Den trigges ikke automatisk af interne eller eksterne events. Og den kan ikke installeres i et produktionsmiljø.
Microsoft Learn bekræfter dette eksplicit: Der er endnu ikke indbyggede integrationer til automatisk at trigge custom agents baseret på indgående e-mails, events eller andre planlagte actions. Man kan simulere disse scenarier ved at inkludere e-mail-header og body i task-beskeden, eller manuelt trigge agenten.
Forvirringen skyldes delvist Microsofts egen formulering (“Create new agents”), men ærligt talt også, at mange af os ikke læste ordentligt, hvad der mentes med “design proof of concept agents”.
Hvad Agent Design Experience i virkeligheden er
Jeg mener, at designeren i virkeligheden er er en sandbox-toolbox til at simulere en agent.
I praksis kan man f.eks.:
Skrive, teste og forfine instruktioner. Instruktionerne er agentens “program”, skrevet i naturligt sprog. Yun Zhu viser det konkrete setup-flow fra wizard’en: Man opretter agenten, vælger profil, tildeler permissions, skriver instruktioner og aktiverer agenten i sandboxen. Microsoft har publiceret en dedikeret guide til instruction keywords og best practices for instruktionsdesign.
Simulere triggering. Man opretter manuelt en task med en besked og valgfrie vedhæftninger. Det er muligt at mimiske indgående e-mails ved at inkludere e-mail-indhold i task-beskeden.
Monitorere og reviewe trin. Runtime leverer en timeline-visning af alle agent-aktiviteter. Fejlfinding sker via detaljerede diagnostiske views, der viser agentens inputs, ræsonneringsproces og outputs.
Teste med forskellige profiler og permissions. Valget af profil er kritisk. I sin demo erfarer Dmitry Katson, at Sales Order Agent (Copilot)-rollen ikke viser Balance-feltet, og agenten derfor ikke kan filtrere. Først med Sales Order Processor-profilen, der har den rette listevisning med Balance-felt og Release-handling, fungerer det. Det er en vigtig indsigt: agentens profil bestemmer, hvad den kan se, og dermed hvad den kan gøre.
Debugge med VS Code. Stefano Demiliani beskriver den nye mulighed for at attache til agent-sessioner direkte fra Visual Studio Code, med en ny client type “Agent” og to nye launch-konfigurationer (cloud sandbox og on-prem). Man angiver agent-brugerens security ID, og snapshot debugging stopper ved næste agent-session.
Reviewe AI-kreditforbrug. Custom agents forbruger Copilot-credits ligesom de indbyggede agents. Credits kan provisioneres via prepaid eller pay-as-you-go.
Og alt dette foregår i en sandbox, så man ikke risikerer at påvirke produktionsdata.
Tænk på det som den in-client page designer, man kender fra BC. Med én forskel: page designeren genererer faktisk en app, man kan downloade. Det gør agent designeren ikke. I hvert fald ikke endnu.
Instruktioner: prompt engineering for ERP
Kernen i enhver agent er dens instruktioner. De skrives i naturligt sprog og fungerer som prompts til den underliggende LLM. Man kan anvende generelle prompt-writing best practices og endda bruge Copilot til at optimere dem.
Bert Verbeek dedikerer en hel blogpost til emnet og understreger, at god promptskrivning ikke er valgfrit, men afgørende for, om agenten bliver en pålidelig assistent eller en forvirret chatbot. Så det er jo ikke meget anderledes end andre agent, som vi også skal prompte meget præcist.
Et konkret eksempel fra Yun Zhus gennemgang viser en Sales Validation Agent med strukturerede instruktioner: Nummererede trin, betinget logik (f.eks. “hvis shipping advice er Complete, release kun hvis reservation stock er full”), og et specifikt output-format med summary. Det minder nok lidt om et flowchart skrevet i prosa.
Microsoft har i øvrigt lavet en guide til “instruction keywords”, der giver agenten specifikke færdigheder, og en dedikeret best-practices side til instruktionsdesign.
Fra prototype til produktion: konvertering til AL-kode
Når man først har designet og testet en agent i sandboxen, skal den konverteres til AL-kode for at komme i produktion og virke i driften. Desværre eller heldigvis (alt afhængigt af øjnene der ser) er det bare ikke bare “click-of-a-button”. Det tager lidt mere tid og finesse.
Eksport
Man eksporterer agent-definitionen som en fil (XML/JSON), der indeholder agent-identitet, instruktioner, tildelte profiler og permissions.
AL-projekt fra template
I VS Code kører man AL: New Project og vælger templaten Agent. Det giver et skelet, man bygger videre på.
De tre core interfaces
Agent dokumentationen beskriver tre interfaces, man skal implementere:
AgentFactory definerer, hvordan agent-instanser oprettes og konfigureres. Det inkluderer standardindstillinger, setup-sider og oprettelsesregler.
AgentMetadata leverer runtime-metadata for individuelle agent-instanser: display name, initialer, setup-sider, summary-sider og annotationer. Det er alt, brugeren ser, når de interagerer med agenten.
AgentTaskExecution styrer, hvordan agenten processerer og eksekverer tasks. Det inkluderer beskedanalyse, forslag til brugerens involvering og page context.
Agenten skal desuden registreres via Copilot Capability-enum’en, præcis som andre Copilot-kapaciteter i BC. Setup-sider implementeres som ConfigurationDialog page type.
Task-triggering via kode
Agent Task Builder API’et giver mulighed for at oprette tasks fra page actions, business events eller e-mail-triggers. Man kan tilføje vedhæftninger, monitorere task-livscyklus og oprette public API’er, så andre apps kan interagere med den nye agent.
Open source-eksempler
Jeg har fundet to gode eksempler som er frit tilgængelige:
Microsofts SalesValidationAgent er det officielle sample i BCTech-repositoriet og følger templaten fra Agent Design Experience.
Bert Verbeeks InventoryCheckAgent er et community-eksempel, der modtager e-mail-forespørgsler om lagerbeholdning, tjekker inventory levels, opretter purchase orders ved lav beholdning og sender HTML-svar via e-mail. Projektet viser et komplet e-mail workflow med separate codeunits til e-mail-hentning (ICARetrieveEmails) og svar-afsendelse (ICASendReplies), plus dedikerede tables til tracking af processerede e-mails og sendte beskeder.
Praktiske tips
Edit Instructions er disabled efter publicering. Handlingerne Edit Instructions og Export Agent Definition på Agent Card er kun tilgængelige for agenter oprettet i Agent Design Experience-appen. Publicerer man sin egen agent-app til en sandbox, er de disabled. Vil man give brugere mulighed for at redigere instruktioner, skal man inkludere sin egen edit instructions-side i appen. Det ville give mening, hvis Microsoft flyttede denne side fra designer-appen til agent framework’et, så man får en ensartet brugeroplevelse.
Setup-siden kan udvides. Agent setup-siden er en ConfigurationDialog page type. I template-projektet har den kun én gruppe. Har agenten brug for ekstra indstillinger, tilføjer man flere grupper.
Profil-valg er afgørende. Agenten kan kun se og gøre det, som profilen tillader. Bygger man en agent til et specifikt formål, kan det give mening at oprette en dedikeret profil med præcis de sider, felter og handlinger, agenten har brug for. Det reducerer også antallet af trin, agenten skal udføre.
Perspektiv: tre veje til agenter
Det betyder – i min optik – at der nu er tre måder at bygge agenter i Microsoft-økosystemet:
- Agenter i Business Central (Agent Design Experience + AL SDK)
- Copilot Studio (low-code)
- Pro-code agenter (Microsoft Agent Framework med Semantic Kernel/AutoGen)
Jeg vil tro, at de fleste BC-partnere vil fokusere på enten BC-agenter eller Copilot Studio. BC-agenter har nemlig den fordel, at de er pålidelige og kører inden for BC’s sikkerhedsmodel.
Begrænsninger og hvad der mangler
Der er bred enighed om at der stadigvæk mangler noget viderudvikling af designeren, før det bliver rigtigt brugbart.
UI som eneste tool er en flaskehals som er til at tage og føle på. Flere påpeger, at agenter, der udelukkende opererer via UI, har performance-begrænsninger ved store mængder gentagne operationer. Det kan man selfølgelig optimere ved at reducere antallet af trin vha. bedre prompts eller custom pages med minimalt feltantal og maksimal information pr. side. Men så kunne man måske lige så godt have kodet processen i stedet?
Jeg synes der er behov for en hybrid model, som kan lidt mere. Dmitry Katson ser f.eks. potentiale i en model, hvor agenter kan kombinere UI-handlinger med interne MCP-tools, f.eks. dynamiske queries. Andre agent-frameworks har vist, at agenter bliver langt mere brugbare, når de kan køre strukturerede queries i stedet for kun at navigere sider.
Agent-to-agent protocol er på ønskelisten. Verbeek håber, at BC i fremtiden vil understøtte en agent-to-agent protokol, der ville åbne for mere kraftfulde integrationer og chat-interfaces bygget oven på BC’s datastruktur.
Der mangler simpelthen en simuleringsmode. Jeg selv og flere andre efterlyser en form for “preview posting”, der lader agenten køre i simuleringsmode uden reelle dataændringer. Det virker som et naturligt næste skridt for Microsoft at bygge på – netop for at bygge tillid til de autonome agenter selvom vi kan snakke om tunge og vigtige finansprocesser.
Konklusion
Agent Design Experience er ikke det low-code produktionsværktøj, man kunne have håbet på. Men det er et udmærket prototyping-miljø, der gør det muligt for konsulenter og udviklere at validere agent-scenarier hurtigt, inden de investerer mere tid i AL-kode. Det vigtige er at forstå det som to adskilte faser: Design i sandboxen -> Deploy via kode.
For BC-partnere som os er det relevante spørgsmål ikke “Kan vi deploye agenter i morgen?”, men “Hvilke processer hos vores kunder egner sig til agentic automation, og kan vi validere dem nu?”. Med designeren i hånden kan man svare på det spørgsmål uden at skrive en linje kode – og det er mange konsulenter nok glade for.
Når prototypen så virker, er vejen til produktion via AL-kode veldokumenteret med templates, SDK, community-eksempler og coding agents, der kan hjælpe med konverteringen.
Kilder
[1] AJ Kauffmann, “Designing Agents for Business Central”, kauffmann.nl, 13. marts 2026. https://www.kauffmann.nl/2026/03/13/designing-agents-for-business-central/
[2] Dmitry Katson, “Meet Custom Agents in Business Central”, katson.com, 5. november 2025. https://katson.com/meet-custom-agents-in-business-central/
[3] Bert Verbeek, “Microsoft Agent Framework and Business Central MCP server”, bertverbeek.nl, 12. november 2025. https://www.bertverbeek.nl/blog/2025/11/12/microsoft-agent-framework-and-business-central-mcp-server/
[4] Microsoft, “Envision and design AI agents in Business Central”, Release Plan 2025 wave 2. https://learn.microsoft.com/en-us/dynamics365/release-plan/2025wave2/smb/dynamics365-business-central/envision-prototype-custom-ai-agents-using-agent-designer
[5] Yun Zhu, “BC27.4: Envision and design AI agents in Business Central (Custom Agent)”, yzhums.com, 9. februar 2026. https://yzhums.com/70502/
[6] Microsoft, “Designing and coding agents in Business Central (preview)”, AI Development Toolkit landing page. https://learn.microsoft.com/ca-es/dynamics365/business-central/dev-itpro/ai/ai-development-toolkit-landing-page
[7] Stefano Demiliani, “Dynamics 365 Business Central: debugging agent sessions”, demiliani.com, 21. oktober 2025. https://demiliani.com/2025/10/21/dynamics-365-business-central-debugging-agent-sessions/
[8] Bert Verbeek, “Agents in Business Central – part 2 – the prompt”, bertverbeek.nl, 16. februar 2026. https://www.bertverbeek.nl/blog/2026/02/16/agents-in-business-central-part-2-the-prompt/
[9] Microsoft, “Coding agents in AL (preview)”, AI Agent SDK Overview. https://learn.microsoft.com/nl-nl/dynamics365/business-central/dev-itpro/ai/ai-agent-sdk-overview
[10] Bert Verbeek, “Agents in Business Central – part 6 – The conclusion”, bertverbeek.nl, 26. februar 2026. https://www.bertverbeek.nl/blog/2026/02/26/agents-in-business-central-part-6-the-conclusion/
[11] Microsoft, “SalesValidationAgent”, BCTech GitHub. https://github.com/microsoft/BCTech/tree/master/samples/BCAgents/SalesValidationAgent
[12] Bert Verbeek, “InventoryCheckAgent”, GitHub. https://github.com/Bertverbeek4PS/InventoryCheckAgent
Denne artikel er inspireret af og bygger videre på AJ Kauffmanns “Designing Agents for Business Central” (kauffmann.nl, 13. marts 2026). Tak til AJ for det solide udgangspunkt.
