Microsoft rozširuje Copilot Studio o nové prostredie postavené na GitHub Copilot harness. Názov môže vyvolať dojem, že ide predovšetkým o prepojenie s GitHubom alebo o funkciu určenú vývojárom. V skutočnosti je jeho význam širší. Copilot Studio získava riadiacu vrstvu, ktorá umožňuje agentom samostatne plánovať zložitejšiu prácu, používať nástroje, spracúvať súbory, vyhodnocovať priebežné výsledky a hľadať iný postup, ak pôvodná cesta nevedie k cieľu.
Microsoft túto novú funkcionalitu pozicionuje pre komplexné viackrokové firemné procesy, ktoré nemožno jednoducho opísať pevnou postupnosťou podmienok a akcií. GitHub Copilot harness však prináša aj iný model účtovania. Použitie agentov a workflows v runtime sa meria prostredníctvom Copilot Credits. Spotreba môže vznikať aj počas tvorby, napríklad pri tvorbe pomocou prirodzeného jazyka, testovaní v Preview a evaluáciách. Ručná tvorba agenta sa podľa aktuálneho prehľadu Microsoftu neúčtuje. Licencia Microsoft 365 Copilot účtované použitie GitHub Copilot harness nepokrýva.
Novinka preto nie je len ďalším rozšírením funkcií Copilot Studia. Mení spôsob, akým je potrebné navrhovať architektúru agentov, vyberať vhodné automatizačné technológie a riadiť ich prevádzkové náklady.
Samotný jazykový model dokáže porozumieť zadaniu, analyzovať informácie a navrhnúť odpoveď alebo ďalší krok. To však ešte nestačí na to, aby proces spoľahlivo dokončil.
Agent potrebuje riadiacu vrstvu, ktorá prepojí model s inštrukciami, kontextom, nástrojmi, dátami a výsledkom. Táto vrstva sa označuje ako harness. V slovenčine pre tento pojem zatiaľ nemáme zavedený presný ekvivalent. Prakticky ho možno chápať ako riadiace a runtime prostredie agenta.
Harness určuje, ako agent postupuje od požiadavky k výsledku. Rozhoduje, aký kontext odovzdať modelu, kedy použiť znalostný zdroj, ktorý nástroj zavolať a čo urobiť s jeho odpoveďou. Zabezpečuje tiež pokračovanie práce medzi jednotlivými krokmi a kontroluje, či sa agent stále približuje k zadanému cieľu.
Zjednodušene možno rozdiel opísať takto.
Predstavme si požiadavku na spracovanie dodávateľskej faktúry. Model môže dokument prečítať, rozpoznať dodávateľa a navrhnúť kontrolu voči objednávke. Harness však musí zabezpečiť, aby agent skutočne otvoril príslušný systém, našiel objednávku, porovnal hodnoty, vyhodnotil odchýlku a podľa výsledku pokračoval ďalším krokom.
Práve schopnosti harnessu rozhodujú, či agent iba odpovedá na otázky, nasleduje vopred pripravené konverzačné cesty, alebo dokáže samostatne riešiť dlhšiu úlohu s premenlivým priebehom.
GitHub Copilot harness využíva agentné prostredie, ktoré stojí za pokročilými schopnosťami GitHub Copilotu. Neznamená to však, že agent musí pracovať so zdrojovým kódom, používať GitHub repozitár alebo byť určený iba vývojárom.
GitHub Copilot pre vývojárov pomáha pri tvorbe a úpravách softvéru. GitHub Copilot harness v Copilot Studiu prenáša jeho spôsob plánovania a práce s nástrojmi do širších firemných procesov.
Agent postavený na tomto harnessu môže dostať cieľ, rozdeliť ho na jednotlivé kroky a priebežne rozhodovať, aké nástroje použije. Môže pracovať s konektormi, znalostnými zdrojmi, MCP servermi, skills a ďalšími agentmi. Nové prostredie podporuje aj prácu so súbormi Wordu, Excelu, PowerPointu a PDF, pamäť medzi interakciami a hľadanie alternatívnej cesty po neúspešnom kroku. Čo je dôležité, pamäť agenta je trvalá cez viacero sessions a je dedikovaná konkrétnemu používateľovi.
Kód môže byť jedným z prostriedkov, ktoré agent na pozadí použije. Nemusí však byť hlavným výstupom a autor agenta ho nemusí ručne vytvárať. Formuláciu, že GitHub Copilot harness dáva Copilot Studiu schopnosti programovania a reasoning, preto nie je vhodné chápať tak, že sa Copilot Studio mení na vývojársky nástroj. Presnejšie je povedať, že agent získava flexibilnejšie prostredie na dokončenie zložitých úloh.
GitHub Copilot harness dáva najväčší zmysel tam, kde proces nemá jednu vopred známu cestu a ďalší krok závisí od toho, čo agent počas práce zistí.
Vhodnými príkladmi môžu byť:
Pri príprave obchodnej ponuky môže agent napríklad načítať informácie z CRM, vyhľadať zodpovedajúcu produktovú dokumentáciu, zohľadniť predchádzajúcu komunikáciu, pripraviť návrh dokumentu a doplniť finančné podklady. Ak niektoré informácie chýbajú, môže sa ich pokúsiť získať iným nástrojom alebo úlohu odovzdať špecializovanému agentovi.
Tradičná automatizácia by pre každý takýto stav potrebovala vopred pripravenú vetvu. Agent s GitHub Copilot harness môže pracovať s cieľom, priebežným stavom a dostupnými nástrojmi. Nejde teda len o inteligentnejší chat. Ide o schopnosť organizovať a dokončovať prácu naprieč dokumentmi, dátami, podnikovými systémami a ďalšími špecializovanými agentmi.
Táto flexibilita však neznamená, že GitHub Copilot harness automaticky nahradí klasických agentov alebo Power Automate. Pri dobre definovanom procese môže byť pevná a predvídateľná automatizácia rýchlejšia, lacnejšia a jednoduchšia na správu.
Spôsob účtovania je pre správne pochopenie novej funkcie zásadný.
Agenti, workflows a aplikácie bežiace na GitHub Copilot harness používajú usage based billing. Spotreba sa meria prostredníctvom Copilot Credits a zahŕňa použitie jazykových modelov, nástrojov, znalostných zdrojov, MCP serverov a samotného harnessu.
Na rozdiel od Standard harnessu môže účtovanie začať už počas tvorby. Copilot Credits môžu spotrebúvať napríklad tieto činnosti:
Spotreba teda nevzniká až vo chvíli, keď je agent publikovaný používateľom. Môže sa objaviť už počas vývoja a ladenia. Microsoft túto skutočnosť opakovane uvádza priamo v dokumentácii nového prostredia.
Licencia Microsoft 365 Copilot túto spotrebu nepokrýva. Používateľ môže mať licenciu Microsoft 365 Copilot, ale použitie agenta alebo workflow na GitHub Copilot harness sa napriek tomu účtuje podľa skutočnej spotreby.
Ide o samostatný prevádzkový model, ktorý zodpovedá tomu, že agent môže vykonávať dlhú a výpočtovo náročnú prácu, používať rôzne modely a volať niekoľko nástrojov bez priamej interakcie s používateľom.
Ak chce organizácia využiť scenáre zahrnuté v licencii Microsoft 365 Copilot, musí zvoliť zodpovedajúceho agenta používajúceho Copilot chat alebo Standard harness. Tým však získa iný rozsah schopností. GitHub Copilot harness nemožno zachovať a iba zmenou licencie odstrániť jeho účtovanie podľa aktuálnej spotreby. Prehľad harnessov uvádza pri GitHub Copilot harness účtovanie pomocou Copilot Credits, zatiaľ čo Copilot chat a Standard harness môžu podľa konkrétneho scenára používať spotrebný model alebo zahrnuté použitie Microsoft 365 Copilotu.
Rozdiel medzi jednotlivými harnessmi nie je iba v ich schopnostiach. Líši sa aj okamih, keď môže vzniknúť spotreba, a podmienky, za ktorých je použitie zahrnuté do licencie Microsoft 365 Copilot.
Pri Copilot chat a Standard harness sa základný model účtovania nemení. Ručná tvorba agenta, testovací panel a štandardný authoring nie sú samy osebe účtované. Pri produkčnom používaní však záleží na tom, kto agenta používa, v akom kanáli beží a či používateľ má licenciu Microsoft 365 Copilot.
GitHub Copilot harness má odlišný model. Usage based billing sa pri ňom vzťahuje na tvorbu aj samotný beh. Spotreba môže vzniknúť pri tvorbe pomocou prirodzeného jazyka, evaluáciách, testovaní aj pri samotnom používaní agenta alebo workflow.
| Oblasť | Copilot chat harness | Standard harness | GitHub Copilot harness |
|---|---|---|---|
| Ručná tvorba agenta | Neúčtuje sa | Neúčtuje sa | Neúčtuje sa |
| Tvorba pomocou prirodzeného jazyka | Nie je relevantné | Neúčtuje sa | Usage based billing |
| Evaluácie | Nie je relevantné | Neúčtuje sa | Usage based billing |
| Testovací panel a preview | Neúčtuje sa | Neúčtuje sa | Usage based billing |
| Externé kanály | Nie je relevantné | Podľa cenníka | Usage based billing |
| Používatel bez licencie Microsoft 365 Copilot | Podľa publikovaného cenníka | Podľa cenníka | Usage based billing |
| Používateľ s licenciou Microsoft 365 Copilot | V rámci fair use sa neúčtuje | V rámci fair use sa neúčtuje | Usage based billing |
| Štandardné, prémiové a vlastné konektory | Samotná integrácia sa neúčtuje | Samotná integrácia sa neúčtuje | Samotná integrácia sa neúčtuje |
| Správa v Power Platform admin center | Neúčtuje sa | Neúčtuje sa | Neúčtuje sa |
Tabuľka: Porovnanie účtovania v jednotlivých fázach životného cyklu agenta pri použití konkrétneho harnessu.
Označenie „neúčtuje sa“ sa vzťahuje na konkrétnu funkciu uvedenú v tabuľke. Neznamená to automaticky, že celý scenár nemôže vyžadovať ďalšie licencie, kapacitu alebo platené konektory.
Zahrnuté použitie pre používateľov s licenciou Microsoft 365 Copilot sa vzťahuje na zamestnanecké scenáre, v ktorých agent pracuje pod identitou autentizovaného licencovaného používateľa. Pri Agent Flows platí zahrnutie do ceny iba pre behy spustené triggerom When an agent calls the flow. Agent Flows, ktoré používajú iné triggery, spotrebúvajú Copilot Credits podľa štandardného cenníka.
Voľba harnessu je preto zároveň funkčným, architektonickým a finančným rozhodnutím.
Prehľad usage based billing pre GitHub Copilot harness najdete zde.
Microsoft teraz rozlišuje GitHub Copilot harness, Standard harness a Copilot chat harness. Pre bežného používateľa je jednoduchšie priradiť si ich k prostrediam, v ktorých dnes agentov vytvára.
Copilot chat harness používajú deklaratívni agenti, ktorí rozširujú Microsoft 365 Copilot. Najjednoduchšou cestou k ich vytvoreniu je Agent Builder priamo v Microsoft 365 Copilote.
Autor môže pomocou prirodzeného jazyka opísať účel agenta, pridať vlastné inštrukcie, zdroje znalostí a podporované akcie. Výsledný agent používa orchestrátor, modely a služby Microsoft 365 Copilotu.
Typickým scenárom je špecializovaný znalostný asistent, ktorý odpovedá nad internou dokumentáciou, projektovými podkladmi alebo produktovými materiálmi. Microsoft 365 Copilot zostáva hlavným prostredím pre konverzáciu a deklaratívny agent ho prispôsobuje konkrétnemu účelu.
Agent Builder nie je jediný nástroj, ktorým možno deklaratívneho agenta vytvoriť. Možno použiť aj Copilot Studio alebo Microsoft 365 Agents Toolkit. Pre základnú orientáciu však platí praktická pomôcka.
Agent Builder zvyčajne znamená Copilot chat harness.
Standard harness predstavuje prostredie, ktoré väčšina používateľov pozná ako pôvodné alebo klasické Copilot Studio. Obsahuje topics, otázky, podmienky, premenné, actions, nástroje a Agent Flows.
Autor má väčšiu kontrolu nad priebehom konverzácie a môže presne navrhnúť dôležité časti procesu. Standard harness je vhodný pre štruktúrované a opakovateľné scenáre, kde má agent kombinovať prirodzený jazyk s pravidlami a predvídateľnými krokmi.
Príkladom môže byť HR agent, ktorý zistí typ požiadavky, položí potrebné otázky, overí vstupné údaje a založí požiadavku v príslušnom systéme.
Klasické Copilot Studio s topics a Agent Flows znamená Standard harness.
GitHub Copilot harness používa nové prostredie Copilot Studia. Je určený pre komplexnejšiu prácu, pri ktorej agent potrebuje samostatne rozhodovať, plánovať, pracovať so súbormi a meniť postup podľa priebežných výsledkov.
Nejde iba o modernizovanú obrazovku pôvodného Copilot Studia. Nové prostredie používa odlišnú architektúru, spôsob orchestrácie a licenčný model. Nové prostredie bolo uvedené na trh vo finálnom vydaní 4. augusta 2026.
Nové prostredie Copilot Studia znamená GitHub Copilot harness.
Harness nie je vlastnosť, ktorú možno pri existujúcom agentovi ľubovoľne zmeniť podobne ako názov, model alebo znalostný zdroj. Je súčasťou typu artefaktu a prostredia, v ktorom agent vzniká.
Copilot Studio umožňuje prechádzať medzi novým prostredím a prístupom k štandardným agentom a Agent Flows. To však neznamená, že sa pri zmene prostredia prevedie konkrétny agent na iný harness. Agentov a workflows vytvorené v novom prostredí nemožno automaticky previesť do klasického prostredia a naopak.
Výber harnessu by preto mal prebehnúť už počas návrhu riešenia, nie až po dokončení vývoja.
Pojem „harness“ môže pôsobiť príliš technicky. Na pochopenie rozdielov je preto jednoduchšie použiť jeden konkrétny scenár a sledovať, ako by ho jednotlivé varianty riešili.
Predstavme si interného HR asistenta pre služobné automobily. Všetky tri harnessy môžu pracovať s rovnakou oblasťou. Ich rola a spôsob riešenia však budú odlišné. Copilot chat harness rozširuje Microsoft 365 Copilot o špecializované znalosti. Standard harness je vhodný pre štruktúrované konverzácie a vopred navrhnuté procesy. GitHub Copilot harness sa zameriava na zložitejšie úlohy, pri ktorých musí agent samostatne plánovať, pracovať s viacerými nástrojmi a prispôsobovať ďalší postup priebežným výsledkom.
Používateľ otvorí Microsoft 365 Copilot a opýta sa:
Aké sú pravidlá pre pridelenie služobného automobilu?
Agent vyhľadá relevantnú internú smernicu, zohľadní inštrukcie, ktoré dostal od autora, a pripraví odpoveď v prostredí Microsoft 365 Copilotu. Môže vysvetliť, ktoré pracovné pozície majú nárok na automobil, aké existujú kategórie vozidiel a ako prebieha ich schvaľovanie.
Takýto agent nevytvára samostatnú agentnú aplikáciu. Rozširuje existujúci Microsoft 365 Copilot o konkrétnu odbornú oblasť. Microsoft pre tento typ riešenia používa označenie „deklaratívny agent“. Deklaratívny agent môže obsahovať vlastné inštrukcie, podnikové znalosti a podporované akcie, ale naďalej využíva základné konverzačné a bezpečnostné prostredie Microsoft 365 Copilotu.
Najjednoduchšou cestou k vytvoreniu takéhoto agenta je Agent Builder v Microsoft 365 Copilote. Agent Builder však nie je samotný harness. Ide o autorský nástroj. Rovnaký typ deklaratívneho agenta možno pripraviť aj v Copilot Studiu alebo pomocou Microsoft 365 Agents Toolkitu.
Copilot chat harness je vhodný najmä vtedy, keď chceme používateľovi sprístupniť firemné znalosti v známom prostredí Microsoft 365 Copilotu. Agent môže byť vybavený aj akciami, jeho hlavnou rolou je však špecializovať Copilot pre určitú oblasť, nie riadiť rozsiahlu vlastnú aplikáciu s presne navrhnutými dialógovými cestami.
Používateľ otvorí samostatného HR agenta a zadá:
Chcem požiadať o služobný automobil.
Agent sa najprv opýta na informácie, ktoré nie sú k dispozícii v profile používateľa. Zistí krajinu, pracovnú pozíciu, požadovanú kategóriu vozidla alebo predpokladaný ročný nájazd. Potom overí nárok podľa interných pravidiel, vyžiada súhlas nadriadeného a pomocou Agent Flow alebo pripojeného nástroja vytvorí požiadavku v príslušnom systéme.
Tu už nejde iba o odpoveď nad firemnou dokumentáciou. Agent vedie používateľa konkrétnym procesom, kontroluje povinné údaje a vykonáva transakčné operácie.
Standard harness zodpovedá prostrediu, ktoré väčšina používateľov pozná ako klasické Copilot Studio. Správanie agenta možno riadiť pomocou topics, otázok, podmienok, premenných, pravidiel a akcií. Autor môže presne určiť časti konverzácie, v ktorých je dôležitý predvídateľný priebeh, a prepojiť ich s generatívnymi funkciami alebo nástrojmi.
Standard harness je vhodný napríklad pre HR požiadavky, IT podporu, onboarding, registráciu zákazníka alebo objednávkové procesy. Spoločným znakom je štruktúra. Organizácia pozná požadované kroky, pravidlá aj možné výsledky a potrebuje mať nad ich vykonaním vysokú mieru kontroly.
Používateľ zadá širší cieľ:
Priprav moju žiadosť o služobný automobil, over nárok, nájdi vhodné dostupné varianty a priprav všetky podklady na schválenie.
Agent musí najprv zostaviť plán. Môže potrebovať získať informácie z HR systému, načítať aktuálnu smernicu, zistiť rozpočet podľa pracovnej pozície, prejsť katalóg dostupných vozidiel, porovnať niekoľko ponúk a pripraviť dokument so zdôvodnením výberu.
Ak niektorý údaj chýba, agent sa ho pokúsi získať prostredníctvom iného nástroja alebo požiada používateľa o doplnenie. Ak požadované vozidlo prekračuje limit, môže vyhľadať vhodnú alternatívu. Ak narazí na výnimku v pravidlách, pripraví podklady na individuálne schválenie. Výsledkom nemusí byť len odpoveď, ale aj upravený dokument, tabuľka s porovnaním alebo sada pripravených krokov pre nadväzujúci workflow.
GitHub Copilot harness je navrhnutý pre podobné komplexné a viackrokové úlohy. Agent postupuje podľa cieľa, samostatne plánuje ďalšie kroky, používa nástroje a vyhodnocuje ich výsledky. Podporuje prácu so súbormi Wordu, Excelu, PowerPointu a PDF, skills, pamäť, konektory, MCP servery, workflows a spoluprácu s ďalšími agentmi. Ak niektorý krok zlyhá, môže sa pokúsiť nájsť alternatívnu cestu.
Tento scenár by bolo možné vytvoriť aj pomocou Standard harnessu a veľkého množstva vetvenia. Vývojár alebo maker by však musel vopred navrhnúť väčšinu možných ciest. GitHub Copilot harness presúva väčšiu časť rozhodovania na agenta, čo prináša vyššiu flexibilitu, ale aj nižšiu predvídateľnosť, náročnejšie testovanie a spotrebné účtovanie pomocou Copilot Credits.
Rozdiel nie je v tom, že by jeden harness bol určený pre HR a iný pre obchod alebo financie. Všetky tri možno použiť v rovnakej podnikovej oblasti. Líšia sa typom práce, ktorú má agent vykonávať.
| Oblasť | Copilot chat harness | Standard harness | GitHub Copilot harness |
|---|---|---|---|
| Hlavný účel | Špecializácia Microsoft 365 Copilotu | Vlastný riadený agent | Komplexné otvorené úlohy |
| Typické prostredie | Agent Builder a Microsoft 365 Copilot | Klasické Copilot Studio | Nové Copilot Studio |
Tabuľka 2: Porovnanie funkcií v jednotlivých harnessoch
Rozhodovanie možno zjednodušiť podľa očakávaného výsledku.
Najdôležitejší rozdiel teda nie je iba v počte funkcií. Každý harness predstavuje iný vzťah medzi autorom a agentom.
Pri Copilot chat harness autor špecializuje existujúci Microsoft 365 Copilot. Pri Standard harness autor navrhuje vlastné konverzačné a procesné cesty. Pri GitHub Copilot harness definuje cieľ, inštrukcie, nástroje a hranice, zatiaľ čo väčšiu časť konkrétneho postupu zostavuje agent až počas práce.
Ďalšou dôležitou otázkou je, kde vytvoriť súvisiacu automatizáciu. Rozšírenie Copilot Studia neznamená, že by všetky existujúce flows mali byť presunuté do agentnej platformy.
Ak proces presne vie, čo má urobiť, býva Power Automate najprirodzenejšou voľbou. Platí to napríklad pre automatizácie, ktoré reagujú na udalosť, bežia podľa plánu, synchronizujú dáta alebo vykonávajú pevne definované podmienky.
Typickými príkladmi sú:
Tieto scenáre nepotrebujú reasoning ani autonómne plánovanie. Power Automate pre ne ponúka široké možnosti integrácie, zdieľania, správy, monitoringu a ALM.
Agent Flows patria k Standard harnessu. Sú deterministické, takže pri rovnakých vstupoch majú vykonať rovnakú postupnosť krokov. Môžu byť spustené agentom, udalosťou, plánom alebo ručne a spotrebúvajú kapacitu Copilot Studia podľa vykonaných akcií.
Najväčší zmysel majú vtedy, keď sú prirodzenou súčasťou agenta. Agent najprv pochopí požiadavku používateľa a získa potrebné parametre. Agent Flow potom vykoná presne definovanú operáciu, napríklad vyhľadanie objednávky, vytvorenie požiadavky alebo aktualizáciu CRM.
Agent rozhoduje, kedy je potrebné operáciu vykonať. Flow zabezpečuje jej predvídateľné vykonanie.
Agent Flow používaný ako nástroj agenta musí obsahovať zodpovedajúci trigger a odpoveď pre agenta a musí byť dostupný v rovnakom prostredí.
Nové workflows vznikajú v prostredí GitHub Copilot harnessu. Ponúkajú prepracované prostredie na tvorbu, natívne AI akcie, odovzdávanie práce agentom a testovanie jednotlivých uzlov. Môžu kombinovať deterministické kroky s časťami, ktoré vyžadujú úsudok alebo adaptáciu.
Workflow môže napríklad prijať dokument, vykonať základnú kontrolu a následne odovzdať obsah agentovi. Agent určí typ dokumentu, vyhodnotí odchýlky a vráti rozhodnutie, podľa ktorého workflow pokračuje.
Nejde teda iba o nový názov pre Agent Flow. Ide o inú kategóriu automatizácie postavenú na novom harnessu.
Dobrá architektúra nemusí používať iba jednu platformu. Copilot Studio môže riešiť porozumenie, rozhodovanie a komunikáciu s používateľom. Power Automate môže ďalej zabezpečovať predvídateľné integračné a transakčné kroky.
Copilot Studio výrazne znižuje bariéru pre tvorbu agentov. Citizen developer môže v krátkom čase pripojiť firemné dáta, pridať nástroje, nastaviť event trigger a publikovať riešenie ďalším používateľom.
To je jedna z hlavných výhod platformy. Súčasne sa však časť architektonického a finančného rozhodovania presúva k autorom, ktorí nemusia poznať rozdiely medzi harnessmi, typmi flows a spôsobmi účtovania.
Jednoduchý znalostný agent môže vzniknúť v GitHub Copilot harnessu, hoci by stačil Agent Builder. Bežná synchronizácia dát môže byť postavená ako AI workflow, hoci by ju Power Automate vyriešil priamočiarejšie, predvídateľnejšie a bez zbytočného agentného rozhodovania. Agent môže byť spustený pri každej zmene v systéme, hoci by väčšinu udalostí mohol vopred odfiltrovať jednoduchý flow.
Nie je nutné vždy použiť bager, keď by stačila obyčajná lopata. Môže vzniknúť neočakávaná spotreba Copilot Credits.
Zmyslom governance nie je citizen development zastaviť. Musí vytvoriť bezpečné mantinely a jasnú cestu od osobného experimentu k produkčnému riešeniu. Organizácia by mala minimálne rozlišovať prostredia pre:
Microsoft odporúča využívať environment stratégiu, role, tenant isolation, data policies, riadenie životného cyklu a ďalšie kontroly Power Platform.
Každý produkčný agent by mal mať jasne určeného vlastníka, obchodný účel, cieľovú skupinu, dátovú klasifikáciu, zvolený harness, povolené nástroje, prevádzkový rozpočet a spôsob monitoringu. Súčasťou správy by mal byť aj proces pre agentov, ktorí sa už nepoužívajú, alebo ktorých vlastník odišiel z organizácie.
Data policies môžu riadiť, aké zdroje znalostí alebo informácií, konektory, HTTP endpointy, skills a publikačné kanály môžu autori používať. Môžu tiež obmedziť event triggery a automatické evaluácie.
Microsoft výslovne uvádza, že event triggery môže byť vhodné blokovať nielen pre riziko úniku dát, ale aj pre neželanú spotrebu alebo vyčerpanie kvót.
Event trigger môže agenta aktivovať bez priamej požiadavky používateľa. Napríklad trigger spustený každých desať minút posiela agentovi vstup pri každom behu a jeho aktivita sa započítava do spotreby.
Vhodným dizajnovým princípom preto môže byť predbežná filtrácia pomocou Power Automate. Deterministický flow najprv overí, či má udalosť skutočný význam. Agenta zavolá iba vtedy, keď je potrebný reasoning, práca s dokumentom alebo riešenie výnimky.FinOps pri agentoch nezačína kontrolou faktúry. Začína sa už rozhodnutím, akú technológiu pre daný scenár použiť.
Pred začiatkom vývoja je vhodné odhadnúť:
Microsoft na tento účel poskytuje Agent Usage Estimator, ktorý umožňuje odhadovať mesačnú spotrebu Copilot Credits pre viac agentov a scenárov. Nejde o záväzný cenový kalkulátor, ale o nástroj na plánovanie kapacity a overenie business case. V čase prípravy článku Agent Usage Estimator ešte neobsahoval GitHub Copilot harness.
Po nasadení možno spotrebu sledovať v analytike Copilot Studia a v Power Platform admin center. Administrátori majú k dispozícii informácie o spotrebovaných kreditoch, produktoch, funkciách a prostrediach, v ktorých spotreba vznikla.
Samotný počet kreditov však nehovorí, či je agent drahý alebo lacný. Náklady je potrebné porovnať s hodnotou výsledku.
Lepšími ukazovateľmi preto môžu byť:
Copilot Studio ponúka aj možnosti odhadu časových a finančných úspor, ktoré môžu pomôcť porovnať nový proces s pôvodným spôsobom práce.
GitHub Copilot harness výrazne rozširuje možnosti Copilot Studia. Nie je však náhradou za všetkých existujúcich agentov a automatizácie.
Na základné rozhodovanie možno použiť nasledujúce pravidlá:
GitHub Copilot harness nie je iba ďalšou technickou funkciou. Posúva hranicu medzi klasickou automatizáciou a agentnou prácou. Umožňuje riešiť procesy, ktoré boli pre tradičné flows príliš premenlivé alebo zložité, súčasne však vyžaduje iný prístup k architektúre, testovaniu a riadeniu nákladov.
Najdôležitejšia otázka preto nie je, či použiť nový harness. Dôležité je vedieť, kde jeho autonómia prinesie vyššiu hodnotu než to, koľko bude stáť.
Pomôžeme vám pripraviť vhodné AI scenáre pre vaše M365 Copilot prostredie.
Pomôžeme vám pripraviť vhodné AI scenáre pre vaše M365 Copilot prostredie.
