Iulie 2026 este momentul în care Microsoft spune că Microsoft 365 Copilot va permite utilizatorilor să ceară Frontier agents blocați și să trimită acele cereri în Microsoft 365 admin center. Dacă rulezi Copilot cu controale mai stricte, asta contează mai mult decât pare.
Astăzi, modelul util pentru multe tenants este simplu: blochezi în mod larg, apoi permiți deliberat. Acest element din roadmap face modelul mult mai practic pentru agenții Microsoft-built din Frontier, pentru că utilizatorii nu mai ajung într-un punct mort. Pot cere agentul, iar administratorii pot aproba sau respinge cererea din același loc în care gestionează deja inventarul de agenți.
Ce se adaugă concret?
Conform roadmap-ului, agenții Microsoft-built disponibili în programul Frontier vor apărea în Agent Store, chiar și atunci când politicile organizației îi blochează. Utilizatorii pot cere acces, iar administratorii pot revizui acele cereri în zona de agents and connectors din Copilot Control System în Microsoft 365 admin center.
Asta se potrivește cu modelul mai larg de management al agenților din Microsoft: admin center are deja un Requests view pentru agenții care necesită review, cu stări precum Pending review, Pending update și Pending activate. Administratorii pot inspecta detaliile agentului și apoi publica sau respinge. Această noutate pare să extindă acel flux de aprobare către Frontier și Microsoft agents blocați, nu doar către cei creați în tenant.
În practică, este un design rezonabil. Păstrează discovery la utilizatori și controlul la administratori. Dacă construiești în jurul Microsoft Copilot și AI agents, acesta este un model operațional mult mai bun decât să ceri fiecărei echipe să deschidă un ticket cu un nume vag de agent și fără context.
De ce contează în practică
Partea interesantă nu este butonul. Este schimbarea de workflow.
Un request flow creează un feedback loop pe care administratorii de obicei nu îl au: ce agenți blocați încearcă oamenii, de fapt, să folosească. Asta ajută să separi cererea teoretică de cererea reală. Pentru majoritatea organizațiilor, probabil înseamnă mai puține presupuneri despre ce agenți Microsoft merită evaluați mai întâi.
Efectul de ordinul doi: odată ce cererile devin vizibile, presiunea se mută pe guvernanță și pe modelul operațional. Cineva trebuie să dețină SLA-urile de review, criteriile de aprobare, audience scoping și retragerea mai târziu. Dacă nimeni nu deține asta, coada de cereri devine doar încă un backlog ignorat.
Acesta este și unul dintre acele cazuri în care „disponibil în store” nu este același lucru cu „pregătit pentru rollout larg”. Frontier este în continuare early access prin definiție. Documentația Microsoft descrie Frontier ca acces preview la capabilități care se pot schimba în timp. Eu nu aș trata o cerere din partea unui utilizator ca dovadă că un agent este suficient de matur pentru deployment larg.
Unghiul de cost e ușor de ratat
Cercetarea din comunitate subliniază și că administratorii pot gestiona cheltuielile legate de agenți prin budgets și spending policies în Microsoft 365 admin center. Este util, dar există o capcană importantă în documentația Microsoft: atingerea a 100% dintr-un budget nu oprește serviciul și nici facturarea. Budgets notifică; nu impun o oprire reală pentru politicile pay-as-you-go.
Asta înseamnă că fluxul de aprobare și controlul costurilor sunt legate, dar nu sunt același lucru. Dacă aprobi mai mulți agenți, mai ales unii bazați pe usage-based billing, ai nevoie și de cineva care să urmărească Copilot Cost Management, spending la nivel de utilizator și grup, și policy limits. Dacă asta devine o parte mai mare din tenantul tău, merită un audit AI și automation înainte ca aprobările să se extindă mai repede decât vizibilitatea asupra costurilor.
Ce aș urmări înainte de rollout
Acesta este un element de roadmap, deci încă nu știm multe lucruri:
- dacă administratorii pot personaliza logica de aprobare dincolo de approve sau reject
- ce metadata despre un Frontier agent este afișată la momentul cererii
- dacă volumul de cereri poate fi delegat curat unor roluri care nu sunt global admin
- cum interacționează cu spending policies pentru agenții bazați pe usage-based billing
Pentru majoritatea organizațiilor, nu este nimic de făcut încă în afară de a nota data din iulie 2026. Dar dacă intenționezi să te bazezi pe Frontier agents, începe să definești cine revizuiește cererile și ce înseamnă de fapt „aprobat”. Mecanica vine. Disciplina operațională rămâne de obicei în urmă.
Iar dacă îți construiești propriile custom MCP servers sau un ecosistem intern de agenți, această funcție este un semn util despre direcția Microsoft: mai mult self-service discovery, cu aprobările și controlul costurilor trase înapoi în planul administrativ.
