Från demo till produktion – när mötesanteckningsagenten kom ur malpåsen

Ur malpåsen

I våras byggde jag en agent som skulle ta ett Teams-möte och göra färdiga mötesanteckningar av det i Confluence. Jag kom en bit på vägen men körde fast: agenten kunde inte läsa mötets transkript. För att lösa det hade jag behövt bygga en integration som jag som projektledare inte klarade på egen hand. Så projektet hamnade i malpåse.

I oktober plockade jag fram det igen. Copilot Studio har utvecklats mycket på några månader, och det som stoppade mig i våras gick nu att lösa. Men när agenten väl kunde läsa transkripten upptäckte jag att det kluriga inte var att få AI:n att skriva bra anteckningar. Det kluriga var allt runt omkring.

Det här inlägget handlar om just det: fyra saker jag lärde mig på vägen från en demo till en agent som går att lita på. Förklarat för dig som, precis som jag, inte är utvecklare.

Vad agenten gör

Agenten heter Meeting notes to Confluence och lever i Teams. Du skriver till exempel ”gör mötesanteckningar av mitt senaste möte”, och sedan gör den fyra saker:

1. Hittar rätt möte i din kalender.
2. Hämtar mötets transkript – texten Teams skapar när mötet transkriberas.
3. Skriver mötesanteckningar med beslut, actions, ägare, deadlines och öppna frågor.
4. Föreslår var i Confluence anteckningarna ska ligga och publicerar först när du sagt ja.

Allt är byggt i Copilot Studio utan att jag skrivit en rad kod. Agenten använder färdiga kopplingar till kalendern, Teams och Confluence.

Lärdom 1: Ett möte har många nummer – bara ett fungerar

Ett Teams-möte har inte ett ID-nummer utan flera: kalenderns, möteskoden och Teams eget nummer för mötesrummet. Transkriptet kan bara hämtas med det sista, och det fanns inte i kalenderkopplingen jag först använde. Agenten gissade, provade fel nummer och misslyckades varje gång.

Lösningen blev den nyare kopplingen Calendar MCP, som ger agenten hela kedjan från kalenderinbjudan till transkript. När en agent fastnar saknar den oftast en länk i kedjan, inte intelligens. Kolla också med din administratör att åtkomst till transkript för Copilot är påslagen i Teams Admin Center – hos oss var den avstängd.

Lärdom 2: Bestäm vems nycklar agenten använder

I Microsoft 365 kör agenten med din egen inloggning, så den ser bara det du redan får se. I Confluence skriver den via ett eget servicekonto.

Två saker att veta om ett sådant konto. Det behöver samma rättigheter som en vanlig medarbetare – vårt saknade dem, och agenten fick ett missvisande ”hittades inte” tills jag loggade in som kontot och såg felet direkt. Och allt kontot når, når alla som använder agenten. Håll det så snålt som möjligt.

Lärdom 3: Skills slår långa instruktioner

Det här är den viktigaste lärdomen, och den bygger på något nytt i Copilot Studio: skills.

I våras skrev jag all logik i agentens instruktionsfält. För varje problem jag löste växte texten. Till slut stod samma regler på flera ställen, ibland i konflikt med varandra, och agenten tog omvägar trots att den redan hade svaret. En regel jag lade till för publiceringen fick plötsligt sidor att hamna på fel plats i Confluence.

En skill är en avgränsad instruktion med ett enda ansvar. Jag delade upp agenten i tre:

Så här skiljer det sig från en lång instruktion:

• Varje regel finns på ett ställe. Inga dubbletter som kan säga emot varandra.
• Felsökningen blir lokal. När taggningen av actionägare inte fungerade ändrade jag bara publiceringsskillen. Resten av agenten rördes inte.
• Kortare instruktioner ger rakare resonemang.
  Agentens egna instruktioner krympte till syfte, språk, ordningen mellan skillsen och gränserna. Mindre att tolka gav färre sidospår.
• Hantverket får plats. I sammanfattningsskillen har jag skrivit in sådant jag lärt mig genom åren som projektledare för att hjälpa agenten tolka: tystnad är inget ja till en action, att ingen invänder betyder inte att något är beslutat, och en deadline som ingen sagt får inte hittas på.

Det är samma princip som i ett projektteam: tydliga roller och ett ansvar per roll. Då vet alla vad de ska göra.

Lärdom 4: Du behöver inte skriva skillsen själv

Jag visste inte hur en bra skill skulle se ut när jag började. Det behövde jag inte heller. Jag beskrev för Copilot vad agenten skulle göra, vad som gick fel och vad jag ville uppnå – och fick tillbaka färdiga utkast till skill-filerna. Sedan itererade vi.

Så här såg arbetsgången ut:

1. Beskriv uppgiften med egna ord, som du skulle förklara den för en ny kollega.
2. Be Copilot föreslå hur arbetet kan delas upp i skills och skriva ett första utkast till varje.
3. Testa agenten på ett riktigt möte.
4. När något går fel, fråga agenten varför. När namnen inte blev taggade förklarade agenten själv att den aldrig slagit upp personerna i Confluence. Den förklaringen tog jag med tillbaka och bad om en uppdaterad skill.
5. Upprepa tills resultatet håller.

Tröskeln är alltså lägre än man tror. Du behöver inte kunna skriva perfekta instruktioner från start. Du behöver kunna beskriva hur slutresultatet ska se ut och känna igen när något blir fel.

Vad det säger om projektledarens roll

Jag trodde att utmaningen var att ”förstå AI”. Det var den inte. Att få modellen att skriva bra anteckningar var det enkla. Det svåra var att bestämma rätt identitet, rätt behörigheter, rätt godkännandesteg och vad agenten ska göra när den är osäker.

Det är inga tekniska frågor i grunden. Det är styrning, ansvar och kvalitetssäkring – samma frågor vi ställer i varje projekt. Skillnaden mellan en demo och en agent som går att lita på ligger i de kontrollpunkterna.

Nästa steg är att projektledargruppen på Contica får bli försökskaniner och ambassadörer. Målet är att våra möten som regel dokumenteras och blir en del av en gemensam kunskapsbank – där vi kan se vilka frågor vi diskuterar om och om igen, och var vårt sätt att driva projekt har luckor.

Vill du bygga en själv?

Du behöver inte vara utvecklare. Så här skulle jag göra om jag började om i dag:

1. Kolla förutsättningarna: Copilot Studio, att transkribering är påslagen i Teams och att din administratör tillåtit åtkomst till transkript.
2. Börja med att bara hämta transkriptet. Få det att fungera innan du lägger till sammanfattning och publicering.
3. Bestäm identiteterna tidigt. Ska agenten skriva som dig eller som ett servicekonto? Testa kontots rättigheter genom att logga in som det.
4. Dela upp jobbet i skills, ett ansvar per skill, och håll de övergripande instruktionerna korta.
5. Visa agenten goda exempel. Ge den dina egna bästa mötesanteckningar som mall.
6. Bygg in ett ja innan publicering, och låt agenten kontrollera resultatet efteråt.
7. Testa att agenten inte ser mer än du, till exempel mot ett möte du inte är inbjuden till.

Tänk också på att en publicerad agent inte automatiskt blir tillgänglig för hela organisationen. Du väljer själv vem den delas med.

Sitter du med liknande utmaningar kring dokumentation och kunskapsöverföring i dina projekt? Hör av dig – vi på Contica delar gärna med oss.

Läs mer

Leonels första artikel om agenten: Så kopplade vi ihop Teams, AI och Confluence för att sluta tappa möteskunskap