När ett team av specialiserade AI-agenter väl är byggt ska agenterna också kunna arbeta tillsammans. De får inte fastna i väntan på varandra, och rätt människa ska kopplas in när det behövs.
Hur agenterna samarbetar syns sällan när man pratar om AI, men det är oftast där ett agentteam lyckas eller misslyckas i drift. Exemplen nedan kommer från Talented AI:s Azure Ops-team, som körde i april 2026 och har varit pausat sedan juli 2026.
Heartbeat-modellen
Varje agent i Azure Ops-teamet kör på ett "heartbeat" — en periodisk uppvakningscykel under vilken den kontrollerar sin inkorg, gör sitt arbete, publicerar sina utdata och går tillbaka till vila. Ett heartbeat är ett schemalagt körningsfönster med bestämda villkor för när det börjar och när det är klart. Mellan fönstren gör agenten ingenting.
Varför heartbeats istället för händelsedriven arkitektur? Av två skäl.
Det första är att det mesta driftarbetet inte behöver svar inom en sekund. Läser agenten in telemetri med jämna mellanrum hinner den upptäcka förändringar och avvikelser i tid för att någon ska kunna göra något åt dem. Ett händelsedrivet system som är byggt för att svara på millisekunder blir mer komplicerat än driften oftast behöver.
För det andra skapar heartbeats ett naturligt revisionsspår. Varje agentkörning är en diskret, loggad körning med en starttid, sluttid, konsumerade indata och producerade utdata. Förr eller senare går något fel, och då kan ni spåra exakt vad varje agent såg, vad den beslutade och när. I en händelsedriven arkitektur där händelser sätter igång varandra i långa kedjor är det mycket svårare att felsöka.
I april 2026 körde alla fem agenterna i Azure Ops-teamet i samma takt, var sjätte timme dygnet runt. Däremellan vaknade en agent när den fick ett ärende. Det går att ge varje agent en egen takt, men för vårt team räckte en gemensam.
Hur arbete flödar mellan agenter
Dataflödet i Azure Ops är strikt riktat under normal drift:
Azure-miljö
↓
Azure Monitor Agent → publicerar strukturerade resultat
↓
Ops Coordinator → triagerar, dirigerar
↓ ↓
Infrastructure Incident Responder
Analyzer (när anomali detekteras)
↓ ↓
└───────┬────────┘
↓
Knowledge Writer → rapporter, runbooks, post-mortems
↓
Rapporter till oss
Specialisterna pratar aldrig direkt med varandra. Allt går via Coordinatorn, och det har vi valt för styrningens skull. Om Infrastructure Analyzer och Incident Responder kunde kommunicera direkt, skulle ni ha två agenter som kan sätta igång varandra i loopar som Coordinatorn inte kan observera eller avbryta. All kommunikation mellan agenter flödar genom Coordinatorn, vilket betyder att alla dirigeringsbeslut är synliga och spårbara.
Utlösningsmodellen
Agentuppvakningar är antingen schemalagda (heartbeat) eller händelseaktiverade (tilldelning från Coordinatorn). I praktiken är de flesta specialist-agenters arbete tilldelningsaktiverat:
- Monitor Agent avslutar ett heartbeat → publicerar resultat till den delade projekttråden
- Coordinator vaknar på nästa heartbeat → granskar Monitor-resultat → tilldelar analysuppgift till Infrastructure Analyzer eller Incident Responder baserat på innehåll
- Specialist vaknar → avslutar analys → publicerar utdata
- Coordinator vaknar igen → granskar utdata → tilldelar till Knowledge Writer eller eskalerar till människa
- Knowledge Writer bearbetar → producerar rapport → skickar in för Coordinator-granskning
- Coordinator godkänner → markerar leveransen klar
De schemalagda heartbeat-kadenserna säkerställer att agenter kör sitt basarbete även i frånvaro av händelser (övervakning och veckovisa rapporter). Tilldelningsmekanismen säkerställer att händelseaktiverat arbete (incidenter, ad hoc-analysförfrågningar) når rätt specialist snabbt.
Reglerna för eskalering
AI-agentteam kan arbeta på egen hand med enskilda uppgifter just för att det finns tydliga, hårdkodade regler för när de ska sluta. Därför byggs eskaleringen in från början.
I Azure Ops är eskaleringsregler definierade på tre nivåer:
Nivå 1: Agent-till-Coordinator-eskalering
Varje specialistagent kan flagga Coordinatorn genom att publicera en taggad kommentar till projekttråden. Utlösare inkluderar:
- Anomali detekterad över tröskelvärdet — Monitor Agent flaggar Coordinatorn omedelbart
- API-fel efter 3 på varandra följande försök — agenten markerar sig själv som blockerad och meddelar Coordinatorn
- Tvetydig utdata — om en agent producerar ett resultat den inte är säker på flaggar den det i stället för att hålla inne det
Coordinatorns jobb är att triagera dessa flaggor inom nästa heartbeat och besluta om att dirigera till en specialist, skjuta upp eller eskalera vidare.
Nivå 2: Coordinator-till-människa-eskalering
Coordinatorn eskalerar till den utsedda mänskliga kontakten för ett begränsat antal situationer där mänskligt omdöme krävs:
- P1 eller P2-incidenter — tjänstedegradation eller avbrott. Coordinatorn väntar aldrig med dem. De går till den utsedda personen på eskaleringslistan i samma heartbeat som de klassas.
- Åtgärdsgodkännande — Incident Responders förslag körs inte utan explicit mänskligt godkännande. Varje åtgärdsplan måste godkännas av en människa innan något ändras.
- Frågor om omfattning — om en incident eller ett resultat faller utanför det som ingår i uppdraget flaggar Coordinatorn det i stället för att improvisera.
Vem som står på eskaleringslistan, och vem som tar över om den personen inte svarar, bestäms när teamet sätts upp. Coordinatorn behöver alltså aldrig avgöra vem den ska kontakta, eftersom det redan är bestämt.
Nivå 3: Talented AI intern eskalering
När Coordinatorn själv är blockerad — flera agenter som misslyckas samtidigt, plattformsproblem, Azure-åtkomstindragning — eskalerar den till Talented AI:s interna team. På så sätt kan teamet aldrig sluta fungera utan att någon märker det.
Att hantera brus
Azure-miljöer genererar många lågvärdes-händelser. Utan aktiv brushantering kommer ett övervakningssystem som eskalerar allt att träna sina operatörer att ignorera allt.
Coordinatorn tillämpar tre brusreduktionsregler:
Deduplicering. Om Monitor Agent lyfter fram samma varning i flera på varandra följande heartbeats grupperar Coordinatorn dem till ett enda resultat snarare än att eskalera N gånger för samma tillstånd.
Sortering efter allvarlighetsgrad. P3- och P4-resultat får inte individuella eskaleringar. De samlas i den veckovisa Knowledge Writer-rapporten om de inte bildar ett mönster som tyder på ett framväxande problem.
Tröskelvärdes-disciplin. Varningströsklar sätts när teamet startar, och bara en människa hos oss kan ändra dem. Agenterna kan inte ändra dem själva. En agent som i tysthet ändrar sina egna trösklar för att få färre varningar att bearbeta gömmer just de signaler som övervakningen finns till för.
Vad som händer när saker går sönder
Agentteam går sönder på sätt som går att förutse, om man inte bygger för det. I Azure Ops planerade vi för de här tre.
Dödläge. Två agenter som väntar på varandras utdata. Förhindras av det strikta riktade flödet: specialisterna väntar inte på varandra; de matar alla in i Coordinatorn. Om Coordinatorn väntar på en specialist som är blockerad eskalerar den snarare än att vänta på obestämd tid.
Inaktuell kontext. En agent som agerar på föråldrad information. Varje agent läser aktuella resultat innan den agerar, och resultat är tidsstämplade. Coordinatorn avvisar analyser som baseras på resultat som är äldre än två heartbeat-cykler.
Autentiseringsutgång. Azure Service Principal-autentiseringsuppgifter löper ut. Monitor Agent får ett 401-svar från Azure API → markerar sig själv som blockerad → Coordinatorn detekterar den blockerade statusen → skapar en autentiseringsrotationsuppgift → eskalerar till en människa hos oss. Det blir ett kort uppehåll i övervakningen, och loggen förklarar varför.
Styrningsplattformen
Heartbeats, dirigering, eskaleringskedjan och revisionsspåret körs på vår interna styrningsplattform. Den hanterar agentschemaläggning, uppgiftstilldelning, körningsloggning, budgetspårning och godkännandearbetsflödena som sitter mellan agentrekommendationer och mänskliga beslut. Plattformen sköter också budgeten. Får en agent en budget varnar plattformen vår styrelse när 80 % är använt, och vid 100 % pausas agenten tills styrelsen har tagit ställning.
Plattformen bygger på att agenter kan arbeta på egen hand samtidigt som människor har tillsyn. Agenterna sköter det de klarar pålitligt, och där ett fel skulle kosta för mycket har en människa sista ordet.
Vi använder samma styrningsmodell i vårt eget bolag. Talented AI drivs helt av agentteam, också teamet som byggde den här arkitekturen. Vi testar detta mönster på oss själva innan vi erbjuder det till kunder.
Vad det här betyder för ert team
Samarbetsmekaniken som beskrivs här är inte unik för Azure Operations. Talented AI använder heartbeat-modellen, det riktade dataflödet och eskaleringshierarkin när vi bygger agentteam för vilken del av verksamheten som helst.
Bygger vi ett team för ett annat område byts kunskapen om området ut, liksom vilka specialister som behövs och vilka människor som står på eskaleringslistan. Den underliggande styrningsarkitekturen är återanvändbar.
Om ni funderar på var ett agentteam kan göra nytta i er drift, leta efter arbete där indata är tydliga, utdata är bestämda och det finns regler för när en människa ska ta över. Det är där ett agentteam ger mest och riskerar minst.
För drift börjar vi med Azure Ops Pilot. Den pågår i 30 dagar i er egen miljö, och ni har full övervakning och rapportering från första dagen. Kontakta oss för att diskutera om det passar.
Talented AI bygger AI-agentteam för företag. Samarbetsmodellen som beskrivs här kommer från vår egen erfarenhet av att köra agentteam i produktion.