Copilot Studio i praksis: fra idé til AI-agent som faktisk gjør nytte

Spørsmålet vi får oftest om dagen er en variant av «kan vi ikke bare lage en AI-agent for dette?». Svaret er nesten alltid ja – teknisk sett. Copilot Studio har senket terskelen dramatisk. Det vanskelige er ikke lenger å bygge agenten. Det vanskelige er å bygge en som fortsatt er i bruk om tre måneder.

Vi har brukt en god del tid på Copilot Studio det siste året, både internt og sammen med kunder. Dette er mønstrene vi ser går igjen.

Hva Copilot Studio faktisk er

Kort fortalt: et lavkodeverktøy for å bygge samtalebaserte agenter som kan slå opp i dine egne data, kalle egne API-er og utføre handlinger – ikke bare svare på spørsmål. Den kobles rett på Dataverse, SharePoint, Dynamics 365 og alt annet som allerede finnes i Microsoft-økosystemet ditt.

Det er den koblingen som er poenget. En agent som bare kan snakke er en chatbot. En agent som kan slå opp ordrestatusen din, opprette en sak i Dynamics 365 og varsle riktig person i Teams er noe annet.

De fire tingene som avgjør

1. Omfanget må være pinlig smalt

Den vanligste feilen er å bygge «en agent for kundeservice». Det er ikke et omfang, det er en avdeling. Agenter som lykkes gjør én ting: svarer på spørsmål om leveringstid. Finner riktig dokument i kvalitetssystemet. Registrerer en avviksmelding.

Start smalere enn du tror er fornuftig. Du kan alltid utvide. Det motsatte – å snevre inn en agent som allerede har skuffet folk – er mye vanskeligere.

2. Datagrunnlaget avgjør alt

En agent er bare så god som kildene den har tilgang til. Hvis dokumentasjonen din er spredt over tre SharePoint-områder, halvparten er utdatert og ingen vet hvilken versjon som gjelder, så vil agenten reflektere nøyaktig det – bare raskere og med mer selvtillit.

3. Eskalering må være designet, ikke ettertanke

Agenten kommer til å møte spørsmål den ikke kan svare på. Det som skiller en god opplevelse fra en frustrerende er hva som skjer da. «Jeg forstår ikke spørsmålet» er et blindspor. En ryddig overlevering til et menneske, med samtalehistorikken intakt, er en tjeneste.

Vi bygger alltid eskaleringsløpet før vi bygger samtaleflyten. Det tvinger fram et konkret svar på hvem som faktisk eier henvendelsene agenten ikke klarer.

4. Noen må eie agenten etter lansering

En agent er ikke et prosjekt som avsluttes. Den er et produkt som må vedlikeholdes. Spørsmål endrer seg, produkter endrer seg, dokumentasjon endrer seg. Uten en eier som ser på hva folk faktisk spør om, forfaller agenten stille.

Dette er den vanligste grunnen til at gode piloter dør. Ikke teknologien – eierskapet.

Når du ikke bør bygge en agent

Det finnes tilfeller der svaret bør være nei, i hvert fall foreløpig:

• Volumet er for lavt. Får du fem henvendelser i uka om et tema, løser du det med en bedre FAQ-side, ikke en agent.
• Konsekvensen av feil svar er høy. Juridiske, medisinske eller sikkerhetskritiske svar krever et menneske i løkka, og da forsvinner mye av gevinsten.
• Prosessen bak er ødelagt. En agent som gjør en dårlig prosess raskere gir deg bare dårlige resultater fortere.

Klarer man å svare konkret på alle fem, går det som regel bra. Klarer man det ikke, er det fem gode oppgaver å ta tak i før man skriver en eneste prompt.

Hvor vi begynner

I praksis starter vi som regel med en halvdags workshop der vi kartlegger hvilke spørsmål som faktisk stjeler tid i dag, og hvilke av dem som har et entydig fasitsvar. Det gir en kort liste med kandidater, og som regel er den øverste kandidaten noe helt annet enn det man trodde da man bestilte workshopen.

Derfra er selve byggingen ofte den raskeste delen.

Gustav Larsson Dynamics 365 & Power Platform-konsulent