Agenter i Microsoft Foundry, och varför vårt arbetssätt blir mer vattenfall än agilt

“Kommer vi ens att använda kod i framtiden?” Den frågan fick jag som motfråga på min undran kring hur programmeringsspråk kommer att utvecklas när vi använder AI som är genererad av gårdagens kod, vilket är skapat av AI som tränats på förra veckans kod, osv, osv..

Detta var en av alla intressanta diskussioner under lunchpausen i tisdagens Agentic Hackathon, en heldagsworkshop anordnad av ALSO. Föreläsare och mentor under dagen var Håkan Forsberg, Partner Solution Architect på Microsoft.

Vad är Microsoft Foundry?

Men vad gjorde vi när vi inte hade lunch? Dagens fokus låg på att skapa, och deploya, egna Agenter till Microsoft Foundry. För den som inte känner till Foundry går det att läsa mer på Microsoft Learn, men kortfattat kan det beskrivas som en plattform i Azure där fokus ligger på allt som har med agenter att göra.

Från prompt agent till hosted agent

Den lättaste typen av agent går att bygga direkt i Foundry, en så kallad Prompt Agent. Det riktigt intressanta är om man sedan kollar vidare på de mer avancerade Hosted Agents – en samling paketerade agenter. Dessa skapar du i VS Code, för att sedan deploya till Foundry. (Även Prompt Agents går att skapa i VS Code.)

En fördel med att ha agenter i Foundry är att de får egna Entra Agent IDn, vilket gör det lättare att spåra deras historik och ge dem relevanta rättigheter. I samband med Foundry har Microsoft också skapat Microsoft Agent 365, där du i ett samlat ställe kan kontrollera och hantera dina agenter. Agenterna kan dessutom inte få högre rättigheter än den användare som skapat agenten. Tryggt och säkert!

Efter en dag med fokus kring agentskapande gick vi därifrån fulla med inspiration och nya lärdomar. Under dagen fick vi gå igenom exempel på agenter, som vi själva fick återskapa i VS Code. För den flitige (eller den som hade turen nog att slippa stöta på problem på vägen) fanns det även tid över för att skapa egna agenter, då endast med hjälp av att prompta. För många programmerare känns det sannerligen fel att inte äga kontrollen, men vad passar väl bättre i ett Agentic Hackathon än att använda sig av AI? Även det kan man behöva öva på.

Min första agent vägrade svara på frågor

Själv lär jag mig helst via lek och passade på att skapa en agent som returnerade filmcitat från den film, eller skådespelare, som användaren promptade in. Rätt oanvändbart, men kanske inte lika oanvändbart som den första agenten jag skapade. En otrevlig prick som vägrar svara på frågor. Jag låter bilden tala för sig själv:

Ska vi bli seriösa för ett tag?

Att kunna bygga egna agenter må vara intet nytt, men när det blir lättare för alla användare att kunna skapa agenter ger det oss ännu fler möjligheter. Inte bara använder vi AI för att hjälpa oss att förstå kravspecifikationer och skriva kod, vi får också möjlighet att skapa (i Conticas fall) integrationer där AI spelar en huvudroll. I teorin skulle vi kunna skapa agenter vars fokus är att skapa och orkestrera agenter vars roller kan vara att tolka krav och bygga integrationer (självklart bestående av agenter) åt oss. Men innan vi blir alldeles för lata och tillitsfulla kanske vi kan diskutera fördelar och nackdelar med att skapa egna agenter?

Vad betyder agenter i Microsoft Foundry för vårt arbetssätt?

Vad är en integrationsspecialist bra på? I vår yrkesroll behöver vi inte bara förstå den teknik vi själva arbetar i och skapar, vi behöver sätta oss in i andra system och APIer samt kundens behov. Förstår vi inte hur kunden och dess andra system fungerar så kan vi inte bygga fungerande integrationer. På Contica har vi gjort en spaning: Agilt arbetssätt kommer att försvinna och våra arbetsuppgifter kommer att förändras. För att få AI att bygga rätt så behöver vi vara specifika. För att vara specifik behöver vi veta vad vi vill. Som integratörer behöver vi då ha koll på vad kunden vill, vad systemen behöver och vad vi anser är best practise innan vi kan definiera för vår agent vad den ska göra. Det gör vårt arbetssätt mer vattenfall-likt, något som många av oss är inpräntade med är ett rätt kasst arbetssätt.

Men om vi tänker att vi människor gärna gör varandra till lags, inte vill vara till besvär och är rädda för att verka dumma.. Är det då inte tänkbart att både det agila och vattenfallsarbetssättet riskerar att generera fel lösning på grund av att vi inte ställt tillräckligt många frågor under förstudierna? Att vi utvecklare trots allt inte har förstått kundbehovet? Skulle det trots allt kunna vara en bra idé att skapa en paragrafridande, kravsamlande agent som vägrar skicka in krav till arkitektagenten innan all info är ifylld? Kan det vara en fördel om vi skapar en kodagent som vägrar bygga vidare på lösningen så länge det finns otydligheter, och som inte är rädd för att verka dum utan ställer frågor när det faktiskt behövs?

Med mänsklig kontroll och väldefinierade agenter

Missförstå mig rätt. Jag förespråkar inte total agent-automation, jag har fortfarande en bra bit kvar innan jag är där. Men efter tisdagen kan jag inte släppa tanken, vad kan vi automatisera mer innan, under och efter vårt arbete? Hur hade förvaltningen påverkats om vi haft agenter som är up-to-date med senaste tekniken, scannar vår integrationsplattform och skickar oss ett dokument på vilka uppdateringar som behövs, samt var de bör implementeras, en gång i veckan? Med mänsklig kontroll, ordentlig säkerhet och väldefinierade agenter i Foundry tror åtminstone jag att vi alla kan bli bättre integratörer, då vi får fokusera på vad vi faktiskt är bra på. Precis det som vi vill låta våra kunder göra genom att ta oss an integrationsjobbet åt dem.

Amanda Orrbeck ingår i Contica AI Center of Excellence, gruppen som driver hur vi använder AI i vårt eget arbete och i våra kunduppdrag. Vill du prata vidare om Microsoft Foundry, eller resonera kring hur morgondagens arbetssätt kommer att se ut, hör av dig till henne på amanda.orrbeck@contica.se.