Atlassian AMP: identiteta agentov, ne odprti standard

Atlassian je 6. oktobra 2026 na konferenci Team ’26 Europe v Amsterdamu predstavil Agentic Multiplayer Protocol (AMP) in začel njegovo postopno uvajanje. Z njim želi agente vključiti v delo ekip v Jiri, Confluence in Loomu. Agent naj ima prepoznavno identiteto in lastnika, njegova dejanja pa naj bodo pripisana njemu ter omejena z dovoljenji.

AMP določa, kako ljudje in agenti sodelujejo v skupnih nalogah, ne predstavlja pa novega odprtega omrežnega standarda. Model Context Protocol (MCP) ima drugačno vlogo: zunanjim agentom in orodjem omogoča dostop do Atlassianovih funkcij in konteksta. Za ekipe, ki uporabljajo Atlassian Cloud, je bistveno vprašanje, kdo lahko vidi agentovo delo, kdo zanj odgovarja in kaj agent sploh sme storiti.

Identiteta poveže agentov prispevek z odgovorno osebo

AMP agentu v skupnem delu določi mesto, ki ga lahko vidijo tudi drugi člani ekipe. Predstavljena zasnova vključuje njegov profil, lastnika in pripisovanje dejanj v realnem času. Če agent sodeluje pri dokumentu ali nalogi, njegov prispevek tako ni skrit v zasebnem pogovoru osebe, ki ga je sprožila. Človek lahko spremlja nastajanje vsebine in presodi, ali jo želi sprejeti ali popraviti.

Identiteta sama še ne pove, do katerih podatkov ima agent dostop. Obseg pooblastil je odvisen od načina njegovega delovanja: lahko uporablja dovoljenja osebe, ki mu je dala nalogo, ali pa deluje prek namenskega računa z lastnimi pravicami. Predstavljena revizijska sled zajema tudi to, kdo je agenta sprožil, do katerih podatkov je dostopal in kje je predviden človeški pregled. To je pomembno pri spremembi strani v Confluence ali premiku naloge v Jiri, saj je za presojo rezultata treba poznati tako izvajalca kot meje njegovega dostopa.

Za skrbnike je pomembna razlika med zasnovo AMP in razpoložljivostjo posameznih nadzornih funkcij. Uvajanje se je začelo, skupni pregled računov agentov in drugih nečloveških identitet pa je bil napovedan kot prihodnja zmogljivost. Iz začetka uvajanja zato še ne sledi, da lahko vsaka organizacija že upravlja vse vrste agentov na enem mestu.

AMP ureja sodelovanje, MCP omogoča povezavo

Atlassian v opredelitvi svoje platforme AMP opisuje kot zbirko uporabniških izkušenj, tehnologij in vzorcev za skupno delo ljudi ter agentov. Ime »Protocol« se tu nanaša na pravila sodelovanja, kot so identiteta, omejena pooblastila, skupen kontekst in pregledljivi rezultati; ta opredelitev ne predstavlja ločene odprte tehnične specifikacije. Atlassian MCP je povezovalna pot za agente, ki delujejo zunaj njegovih aplikacij.

Razmerje med sestavnimi deli je mogoče prikazati z zemljevidom naloge, pri kateri sodeluje agent:

Teamwork Graph → agent: poveže podatke o nalogah, dokumentih, ljudeh in odločitvah v delovni kontekst, do katerega agent dostopa v okviru dovoljenj.
MCP → zunanje orodje: agentu zunaj Atlassianovih aplikacij omogoči uporabo ustreznega konteksta in funkcij platforme.
AMP → skupno delo: določa agentovo identiteto, vidnost prispevka, obseg pooblastil in možnost človeškega pregleda.
Jira, Confluence in Loom → delovne površine: v njih ekipa agentu poda nalogo oziroma vidi njegovo delo in rezultat.

MCP lahko torej odpre pot do naloge v Jiri, vendar sama povezava še ne določa, kdo je lastnik agenta in kako se njegov prispevek prikaže sodelavcem. AMP ta vprašanja postavlja v delovni tok. Povezava je posebej pomembna za zunanje agente: ti lahko sodelujejo z Atlassianovim kontekstom, njihov dostop in dejanja pa morajo ostati razumljivi ljudem, ki vodijo delo.

V Jiri in Confluence se spremeni vidnost dela

V Jiri naj bi agentove seje postale povezane z ustreznimi delovnimi nalogami. Ekipa lahko tako ob nalogi spremlja prispevek agenta poleg človeškega dela, namesto da bi iskala rezultat v ločenem orodju. Agent lahko sodeluje tudi v razpravi v komentarjih ali v poteku, ki razvršča in usmerja naloge. Povezovanje sej iz lokalnih razvojnih orodij z Jiro je bilo napovedano za pozneje, zato ga ni mogoče enačiti s funkcijami, katerih uvajanje se je že začelo.

V Confluence lahko sodelavec agenta omeni pri delu na vsebini. Predstavljena zasnova vključuje vidne prispevke pri urejanju dokumenta, tako da je mogoče razlikovati med človekovim in agentovim posegom. Loom ponuja drugačno pot do istega skupnega dela: človek lahko agentu posreduje videonavodilo, v katerem govor, premiki kazalca in izbori na zaslonu določajo, kaj je treba opraviti. Rezultat se nato vrne v okolje, kjer ga lahko ekipa pregleda.

Za projektno ali razvojno ekipo iz tega izhajajo konkretna vprašanja o odgovornosti: kdo je lastnik agenta, ki spremeni dokument ali stanje naloge; ali deluje z dovoljenji zaposlenega ali z namenskim računom; in kje je razvidno, kaj je prebral, spremenil ter predal v odobritev? Odgovor je odvisen od vrste agenta, nastavitev organizacije in tega, katere napovedane funkcije so zanjo že na voljo. Prav ta razlika določa, ali je vidna identiteta tudi uporaben nadzor nad dejanji.

Uporabnost je odvisna od konteksta, ki ga ekipa že hrani

Agentova identiteta pomaga razložiti, kdo je opravil delo, kakovost njegovega predloga pa je odvisna od konteksta, ki ga lahko uporabi. Analitik Torsten Volk iz Omdie je v analizi TechTarget ocenil: »Atlassian's advantage there is Jira and Confluence, not the AI«. Njegova poanta je, da je prednost platforme za obstoječe uporabnike predvsem v že zbranem znanju o njihovem delu.

Če so naloge, odločitve in povezani dokumenti urejeni v Jiri in Confluence, ima Teamwork Graph več uporabnega gradiva za agentovo delo. Kadar ključni razlogi za odločitev niso zabeleženi ali so zunaj dosegljivega konteksta, jih identiteta in revizijska sled ne moreta nadomestiti. Za uporabnike bo zato pravo merilo uvajanja AMP, ali lahko pri konkretni nalogi hkrati vidijo uporabljen kontekst, meje agentovih pooblastil in človeka, ki je sprejel končni rezultat.

Preberite tudi: