Sezamo nu este doar un magazin online: anatomia unei platforme distribuite de e-grocery

La ora 01:00 vrei să adaugi o sticlă de kefir într-o comandă pentru dimineață. Presupunem, pentru acest exemplu, că modificarea mai este permisă. Pentru tine înseamnă o atingere a ecranului. Pentru platformă, schimbarea trebuie să rămână compatibilă cu stocul, pregătirea comenzii și plecarea vehiculului.

Nu este suficient ca o bază de date să conțină încă un rând. Sticla trebuie să existe, să fie disponibilă pentru vânzare, să ajungă în punga potrivită și apoi în duba care deservește adresa ta.

Acesta este punctul de plecare al arhitecturii e-grocery: sincronizarea dintre informație și realitate fizică. O promisiune din interfață trebuie să rămână realizabilă chiar și atunci când stocul, capacitatea depozitului și condițiile de livrare se schimbă între două apeluri API. Continuă direct cu analiza tehnică.

1. Un supermarket online nu este doar un website

Modelul frontend → API → bază de date explică o cerere web, dar ascunde aproape toate deciziile operaționale.

Rohlik descrie software propriu pentru magazin, prognoză, fulfillment, plăți și comunicare cu clientul. Sezamo este brandul grupului din România.

Un bounded context delimitează un model de business și regulile sale. „Disponibil” poate însemna produs afișabil în catalog, cantitate rezervabilă sau articol deja pregătit. Confundarea acestor sensuri produce probleme chiar dacă fiecare API funcționează separat.

2. Ce măsoară, de fapt, dimensiunea platformei

Inventar consultat la 28.08.2026: Rohlik.

Surse declarate: GitLab — 9 iunie 2026; Mesmer; Datadog DORA. Data consultării nu este data colectării. Nu am măsurat independent activitatea operațională.

Cele cinci piețe principale sunt Cehia, Germania, Austria, Ungaria și România. Participația minoritară în eBag, Bulgaria, este prezentată separat. Countries.

Un repository poate conține o bibliotecă, un frontend, infrastructură declarativă, pipeline-uri ML sau mai multe servicii. Nu rezultă „342 de microservicii”. Nici contributorii nu reprezintă automat numărul angajaților.

La această scară, întrebarea utilă este cum gestionezi contractele, versiunile și responsabilitatea operațională. Numărul repository-urilor nu măsoară singur calitatea arhitecturii.

Eticheta paved road marchează standardele interne recomandate. Growing, Steady, New și Sunsetting descriu adopția, nu un clasament al calității. Legenda Rohlik. O tehnologie în retragere poate încă susține funcții importante; eticheta nu stabilește singură un termen de migrare.

Pentru a înțelege inventarul, îl putem organiza după responsabilități. Tabelul este un model explicativ, nu o mapare confirmată a serviciilor interne.

Aceste responsabilități se influențează reciproc. O prognoză poate schimba planificarea personalului, dar nu confirmă că o anumită comandă este deja pregătită. Un deployment reușit nu confirmă că produsul a ajuns în vehicul.

3. Nucleul tranzacțional: reguli care trebuie să rămână adevărate

În inventarul tehnologic Rohlik, Java este descris ca centrul nucleului tranzacțional, iar Spring Boot apare ca framework backend standard.

Un nucleu tranzacțional trebuie să protejeze invarianți precum „aceeași rezervare nu consumă stocul de două ori”. Spring oferă abstracții pentru tranzacții și integrarea cu accesul la date. Asta îl face potrivit pentru asemenea probleme, fără să demonstreze că fiecare componentă Rohlik de checkout, inventar sau plăți este scrisă în Java. Spring: tranzacții.

Să presupunem că plata este autorizată, dar răspunsul se pierde. O reîncercare fără identitate stabilă poate repeta efectul comercial. Idempotency, sau idempotența, înseamnă ca reluarea aceleiași operații logice să nu producă încă o debitare sau încă o comandă.

Protecția cere mai mult decât un identificator: asocierea lui cu utilizatorul și cererea, salvarea rezultatului și reguli pentru cereri concurente. O tranzacție locală nu include automat procesatorul de plăți, brokerul și depozitul. Framework-ul nu poate transforma aceste sisteme independente într-o singură operație atomică.

Inventarul Rohlik include și Testcontainers. Potrivit documentației bibliotecii, aceasta poate porni baze de date și alte dependențe în containere temporare pentru teste de integrare. Pentru rezervări, un scenariu util este concurența dintre două cereri pentru ultima unitate: testul cu motorul real poate surprinde comportamente pe care un substitut simplificat le ascunde. Nu reproduce automat încărcarea, configurația și toate modurile de defectare din producție.

4. Prognoza nu produce doar grafice

Rohlik enumeră Python pentru servicii, ML, date și agenți, alături de FastAPI. Veloq este platforma tehnologică proprie Rohlik, disponibilă și altor comercianți online. Documentația Veloq WMS descrie legătura dintre cererea anticipată și alocarea personalului.

Conceptual, dependența este:

cerere → prognoză → aprovizionare → programarea recepțiilor de la furnizori → necesar de personal → capacitate de pregătire.

Pentru produse perisabile, supraestimarea poate însemna expirare și risipă, nu doar bani blocați în stoc. Subestimarea poate duce la pierderea vânzării și poate lăsa coșul incomplet. Electronicele au și ele costuri de stocare și depreciere, dar nu aceeași presiune zilnică a prospețimii.

Un model bun statistic nu este suficient. Dacă prezice corect cererea, dar marfa sosește după vârful de picking, rezultatul operațional rămâne slab. Predicția trebuie convertită în decizii realizabile, ținând cont de termenele de aprovizionare și de limitele de spațiu și personal.

Aceasta explică de ce data engineering, ML și optimizarea operațională trebuie evaluate împreună, nu doar prin scorul unui model.

5. Unde software-ul întâlnește depozitul

În prezentarea automatizării și optimizării operaționale, Rohlik descrie integrarea WMS cu automatizarea, MIP pentru alocarea SKU-urilor în grilă, ML pentru aprovizionare și programare liniară pentru planificarea turelor.

Un WMS — Warehouse Management System — gestionează operațiunile depozitului. Un WES — Warehouse Execution System — coordonează, în terminologia Veloq, execuția între WMS și automatizare. Picking înseamnă colectarea articolelor; fulfillment cuprinde pregătirea comenzii pentru livrare. Veloq WMS, Veloq WES.

AutoStore nu este o metaforă pentru cloud: sunt containere stivuite într-o grilă, accesate de roboți și aduse către posturile de lucru. Rohlik a anunțat pornirea unei asemenea instalații la München în septembrie 2022, inclusiv legături prin benzi transportoare. Acesta este un exemplu localizat și datat. Sursele consultate nu confirmă aceeași configurație în depozitul Sezamo România. Comunicatul Rohlik.

Programarea liniară optimizează un obiectiv în condițiile unor relații liniare. MIP, mixed-integer programming, permite și variabile întregi pentru decizii discrete: alegi sau nu un articol pentru o anumită zonă. SKU este codul prin care identifici un tip de articol în stoc. Nu presupunem că Rohlik folosește solverele din documentația citată pentru explicarea conceptului. OR-Tools: optimizare.

Exemplu conceptual: grila poate avea suficient stoc, dar porturile de picking pot fi saturate. Accelerarea unui robot nu ajută dacă următoarea bandă este blocată. Optimizarea locală trebuie judecată prin efectul asupra fluxului complet.

Integrarea cu roboții nu dezvăluie unde rulează fiecare controler. Nu putem deduce că GKE comandă direct motoarele. Într-un model de integrare, o cerere acceptată, o operație în curs și rezultatul fizic confirmat sunt stări diferite. Un răspuns HTTP reușit poate confirma doar prima etapă.

Nici rutarea nu începe obligatoriu după ambalare. Veloq Router descrie estimarea timpilor de pregătire și încărcare împreună cu ruta, apoi transmiterea priorităților către WMS. Veloq Router.

Rohlik declară solvere proprii pentru rute, urmărirea flotei în timp real și optimizarea capacității curierilor. Acestea sunt capabilități declarate, nu o configurație demonstrată pentru România.

6. De ce există stoc, dar nu neapărat o promisiune livrabilă

Pentru exemplul nostru, condițiile ar putea fi:

produs eligibil → cantitate disponibilă → rezervare → capacitate în depozit → pregătire la timp → vehicul și slot → autorizarea plății → livrare fezabilă.

Este o listă conceptuală de constrângeri, nu ordinea publicată a checkoutului Sezamo.

Doi clienți pot vedea simultan ultima sticlă. Dacă ambii încearcă să o rezerve pornind de la aceeași stare, fără controlul concurenței, poate apărea o race condition: rezultatul depinde de ordinea operațiilor. Un cache poate afișa o stare veche, iar simpla citire a cantității nu garantează rezervarea ei.

Rezervarea trebuie să aibă o regulă de concurență și, când este temporară, o expirare. Dacă plata eșuează, capacitatea și stocul trebuie eliberate. Dacă plata reușește, dar confirmarea întârzie, sistemul trebuie să poată reconcilia rezultatul.

O opțiune arhitecturală este o succesiune de tranzacții locale cu acțiuni compensatorii, cunoscută drept saga. Compensarea nu înseamnă că timpul poate fi dat înapoi: eliberarea unei rezervări nu readuce în depozit o pungă deja expediată. AWS: saga orchestration.

La reluarea unui flux, întrebarea corectă este „ce s-a executat deja?”, nu doar „ce request a eșuat?”. Aici se întâlnesc consistența, reîncercările și recuperarea după erori.

7. RabbitMQ și stările care nu se actualizează simultan

RabbitMQ apare în 50 de repository-uri, conform inventarului Rohlik. Este plauzibil să existe fluxuri asincrone între domenii; inventarul nu dezvăluie topologia lor.

Evenimente precum OrderCreated, OrderModified, OrderCancelled, PickingStarted, OrderDispatched sau OrderDelivered sunt nume ilustrative, nu contracte Rohlik confirmate. Un consumer este componenta care prelucrează mesajele primite.

Sursa autoritativă, sau source of truth, este evidența de referință pentru o anumită stare. Un read model este un model de date organizat pentru citire. Poate fi implementat ca proiecție materializată: o reprezentare derivată a datelor, stocată și actualizată pe baza modificărilor din sursă.

În exemplul de mai sus, comanda poate fi anulată în evidența autoritativă, în timp ce analytics încă numără versiunea anterioară, iar fidelizarea nu a ajustat punctele. Propagarea evenimentelor poate explica diferența. Nu înseamnă că orice divergență este acceptabilă sau că am identificat mecanismul intern Sezamo.

Diferențele pot proveni și din filtre sau reguli comerciale distincte. Fără loguri, tracing și codul backend nu putem stabili cauza unei situații reale. În modelul eventual consistency, dacă actualizările încetează și sunt procesate corect, reprezentările ajung să reflecte starea relevantă pentru fiecare model.

Un sistem bazat pe eventual consistency are nevoie de criterii operaționale clare: ce întârziere accepți, cum detectezi consumatori blocați și cum repari proiecțiile? „Se sincronizează cândva” nu este un criteriu suficient.

RabbitMQ documentează posibilitatea relivrării mesajelor; consumatorii trebuie să gestioneze duplicatele. Confirmarea primirii mesajului de către broker nu certifică finalizarea tuturor efectelor comerciale. RabbitMQ: reliability, acknowledgements și confirms.

Pentru a evita salvarea comenzii fără publicarea evenimentului, un pattern posibil este transactional outbox: starea și evenimentul se persistă în aceeași tranzacție locală, apoi evenimentul este transmis separat. Este o recomandare conceptuală, nu o implementare atribuită Rohlik. AWS: transactional outbox.

8. Mai multe piețe înseamnă mai mult decât un tenant_id

Pentru operarea în mai multe piețe, Rohlik descrie cod comun, date izolate, identitate regională, comutatoare de funcționalitate și rutare tenant-aware. Rohlik.

Arhitectural, comutatoarele de funcționalitate permit aceleiași baze de cod să expună comportamente diferite. Rutarea tenant-aware păstrează contextul pieței. Nu aflăm însă dacă izolarea folosește baze separate, scheme distincte sau alte mecanisme.

Exemple posibile de variație: metode de plată, promoții, fiscalitate, sortiment, integrări și modele logistice. Nu atribuim României o configurație concretă fără documentație.

Într-o platformă cu operațiuni fizice, izolarea trebuie păstrată și în cache-uri, mesaje, joburi și contextul de autorizare. Un tenant selectat corect în interfață nu protejează un consumer care pierde acel context.

Față de un SaaS simplu, reutilizarea codului trebuie să țină cont și de constrângeri fizice care nu se schimbă printr-o simplă configurare: personal, condiții de temperatură, vehicule și geografie. „Shared codebase” nu înseamnă „aceleași constrângeri peste tot”.

9. Infrastructura care permite schimbarea continuă

Infrastructura enumerată de Rohlik include Google Cloud/GKE, Docker, GitLab CI/CD, Argo CD și Terraform, alături de Datadog, OpenTelemetry, Grafana, Sentry și lansări canary.

Un flux conceptual compatibil este dezvoltator → GitLab CI → imagine Docker în registry → configurație versionată → Argo CD → Kubernetes/GKE. Terraform gestionează aici infrastructura declarativă. Nu fiecare modificare trebuie să parcurgă identic această succesiune.

Imaginea împachetează aplicația și dependențele necesare; containerul este o instanță de execuție. În Kubernetes, Podul grupează unul sau mai multe containere care împart rețeaua și pot folosi volume comune. Podurile rulează pe nodurile clusterului. GKE este serviciul Kubernetes administrat de Google, nu un strat suplimentar pe care îl traversează fiecare cerere. Aceste concepte explică unde și cum rulează aplicațiile; nu descriu regulile comenzilor. Docker: imagini, Kubernetes: Pods, GKE.

În fluxul ilustrat, CI execută verificările configurate și produce artefactul. Livrarea continuă îl pregătește pentru lansare; deploymentul continuu automatizează și promovarea în producție. Un commit sau un merge nu dovedește singur că versiunea a ajuns la clienți. Etapele și condițiile de lansare trebuie definite în pipeline. GitLab: CI, delivery și deployment.

În GitOps, Git exprimă starea dorită, iar Argo CD o compară cu starea efectivă a sistemului. Aplicarea automată și corectarea abaterilor depind de politica de sincronizare. Argo CD: automated sync.

O lansare canary limitează inițial expunerea versiunii noi și folosește criterii de evaluare înainte de extindere. Controlul traficului și analiza sunt distincte de sincronizarea configurației; Argo Rollouts este un proiect separat care poate coordona asemenea strategii. Nu deducem din inventarul Rohlik ce controller, praguri ori mecanism de revenire sunt configurate. Argo Rollouts.

Frecvența publicată agregă deploymenturi de producție; nu înseamnă tot atâtea schimbări zilnice ale storefrontului. Fără rata incidentelor și timpul de recuperare, nu putem deduce fiabilitatea.

Un container se poate reporni în același Pod, conform politicii configurate; un controller poate crea un Pod înlocuitor când este necesar. Sunt mecanisme diferite. Kubernetes: lifecycle. Dacă procesul dispare după autorizarea plății, o instanță nouă trebuie să afle rezultatul deja produs. Refacerea execuției nu este echivalentă cu recuperarea tranzacției.

Observability înseamnă să poți explica starea sistemului din semnalele sale. Tracingul corelează operații distribuite; metricile arată tendințe, iar logurile oferă detalii. OpenTelemetry oferă instrumente pentru generarea, colectarea și exportul semnalelor; stocarea și vizualizarea revin altor sisteme. Rolul OpenTelemetry.

În exemplul cu kefirul, ai vrea să urmărești rezervarea, întârzierea mesajului și acceptarea în picking. Un rollback de aplicație nu retrage automat o acțiune fizică și poate necesita compatibilitate cu datele deja scrise.

Inventarul nu permite stabilirea topologiei clusterelor, a mecanismului exact de izolare a datelor sau a procedurilor de recuperare. Acestea cer documentație de arhitectură și dovezi operaționale, nu doar numele produselor folosite.

Până aici am privit platforma prin interfețele web și mobile. Dar comenzile, rezervările și regulile comerciale nu sunt definite de ecranele prin care ajungem la ele. Ce se schimbă când utilizatorul formulează o intenție în limbaj natural, iar o aplicație AI propune operațiile necesare?

Platforma primește un nou tip de client: agentul AI.

10. MCP, explicat unui dezvoltator care cunoaște REST

MCP adaugă o interfață către infrastructura discutată până aici. Nu înlocuiește serviciile care decid dacă un produs poate fi rezervat sau o comandă modificată.

Analogia „MCP este aproximativ un USB-C pentru aplicațiile AI” ajută la prima întâlnire: există o modalitate comună de conectare. Limita analogiei este că un conector comun nu garantează semantica, permisiunile sau calitatea sistemului conectat.

Model Context Protocol nu este un model AI. Este un protocol prin care o aplicație poate descoperi și utiliza capabilități externe.

Aceste roluri și primitive sunt definite în documentația MCP; nu trebuie să presupunem că orice server le expune pe toate. Arhitectură, primitivele serverului.

Mesajele folosesc JSON-RPC. Transporturile standard includ stdio, pentru un proces local, și Streamable HTTP, pentru comunicare HTTP. Autorizarea HTTP este tratată separat, printr-un cadru bazat pe OAuth. Conectarea nu acordă automat dreptul la orice acțiune comercială. Transporturi, autorizare.

Pentru un dezvoltator REST, diferența utilă este contractul destinat clientului AI: instrumente descoperibile, descrieri, scheme de intrare și rezultate. API-urile existente pot rămâne în spate; modelul nu trebuie să cunoască structura bazei de date.

Referințele MCP din articol folosesc ediția 2026-07-28 a specificației. Nu atribuim automat această versiune serverului Sezamo.

11. Ce expune un Grocery MCP Server

Sezamo documentează conectarea prin HTTP și OAuth, cu acces la funcții de cumpărături și asistență. Documentația introductivă nu publică însă un catalog nominal complet de instrumente. Sezamo MCP, prezentarea în română.

În metadatele conectorului Sezamo consultate la 28 august 2026 apar următoarele denumiri. Acesta este un contract observat, nu dovada executării operațiilor:

Nu substituim aceste nume cu aliasuri presupuse. Mai ales, get_checkout nu plasează comanda. Descrierea show_submit_checkout indică un buton către checkoutul web, unde utilizatorul verifică și finalizează comanda.

Operațiile expuse acoperă responsabilități precum catalogul, coșul, livrarea, comenzile, profilul/fidelizarea, reclamațiile, ambalajele returnabile și rețetele. Gruparea lor în domenii este interpretarea noastră, nu inventarul microserviciilor companiei.

12. MCP nu este backend-ul supermarketului

În modelul ilustrat, hostul și modelul interpretează intenția, iar serverul MCP expune operațiile comerciale. Evidența autoritativă pentru stoc, plăți, comenzi sau livrare rămâne în sistemele care gestionează acele domenii.

Un server MCP poate valida argumente, combina răspunsuri și simplifica o operație pentru agent. Nu trebuie să devină o cale prin care regulile backendului sunt ocolite.

De exemplu, un tool de anulare trebuie să obțină o decizie a domeniului comenzilor asupra eligibilității. Nu poate deduce dintr-un mesaj conversațional că pregătirea fizică s-a oprit.

Aceasta este o recomandare de separare a responsabilităților, nu o concluzie că am verificat intern implementarea Sezamo.

13. Interfața se schimbă, obligațiile rămân

Într-o interfață clasică, utilizatorul interacționează cu elementele interfeței, iar acțiunile sale declanșează apeluri API. Într-o interfață conversațională, utilizatorul formulează intenția, modelul propune apeluri de instrumente, iar aplicația le execută în limitele permise.

Exemplu conceptual: „Adaugă ingredientele pentru carbonara, alege variantele pe care le cumpăr de obicei și evită produsele indisponibile.”

Agentul ar putea consulta preferințele la care are acces autorizat, căuta produse, verifica variantele și adăuga articolele acceptate. Dacă nu cunoaște numărul de porții sau bugetul, poate cere clarificări. Dacă o parte din operații reușește, trebuie să comunice exact ce a schimbat, fără să repete automat tot fluxul.

Un coș afișat vizual rămâne util pentru cantități, prețuri și înlocuiri. UI-ul clasic nu dispare: devine și suprafața în care verifici consecințele unei intenții formulate liber.

14. MCP dincolo de cumpărături

Rohlik enumeră MCP în 17 repository-uri și în 15+ servicii, iar FastMCP în 8 repository-uri. OpenAI GPT, LangChain/LangGraph, Langfuse și LiteLLM completează inventarul. Rohlik.

Repository-urile, serviciile și instrumentele sunt categorii distincte; numerele lor nu sunt interschimbabile. Nici prezența FastMCP nu dovedește că fiecare server MCP al grupului folosește acel framework.

Distincția arhitecturală rămâne utilă: protocolul definește contractul, biblioteca serverului îl implementează, iar orchestrarea stabilește succesiunea apelurilor. Modelul și observabilitatea au alte responsabilități. Inventarul tehnologic nu dovedește cum sunt legate toate aceste componente într-un anumit agent.

Inferență: un protocol comun poate servi agenți pentru clienți, dezvoltare, operațiuni și analiză. Nu rezultă că toți au aceleași permisiuni sau accesează aceleași sisteme. Exemplul de raportare internă arată concret o utilizare distinctă de cumpărături.

15. reporting-mcp: accesul la date nu înlocuiește sensul lor

În articolul din 24 aprilie 2026, Rohlik prezintă reporting-mcp, un gateway către Snowflake și un semantic layer versionat în Git. Sunt documentate search_verified_queries, search_tableau_metrics și read_query; scrierile sunt dezactivate implicit. Articolul Rohlik.

Problema generală este semantică. „Venit” poate include sau exclude retururi; „client activ” are nevoie de o perioadă și de criterii; „marjă” cere o formulă convenită. O interogare SQL care rulează fără eroare poate calcula indicatorul greșit. Un strat semantic face explicite relațiile, dimensiunile și formulele. Snowflake: semantic views.

Stratul Rohlik nu trebuie confundat automat cu produsul Snowflake „Semantic Views”.

Prioritatea interogărilor verificate este îndrumare pentru agent. Rohlik permite și explorare cu SQL nou; nu garantează folosirea exclusivă a interogărilor aprobate. Articolul Rohlik.

Lecția de guvernanță este să separi trei verificări: are utilizatorul dreptul să vadă datele, este permisă interogarea și corespunde rezultatul definiției comerciale? Read-only limitează modificările, dar nu rezolvă riscul divulgării datelor, costul unei interogări sau interpretarea greșită. O formulă aprobată cere și controlul filtrelor, perioadei și granularității folosite.

16. Când AI-ul primește dreptul să modifice lumea reală

Citirea catalogului și anularea unei comenzi au consecințe diferite. Agentul poate propune un apel, dar backendul trebuie să verifice dreptul utilizatorului asupra comenzii și dacă modificarea mai este permisă.

O autorizare OAuth nu înlocuiește confirmarea acțiunii concrete. Utilizatorul trebuie să înțeleagă ce se schimbă, iar reluarea unei cereri după un timeout nu trebuie să dubleze efectul. Acestea sunt reguli generale de proiectare, nu constatări despre implementarea Sezamo. MCP: tools, autorizare.

La fel, o descriere de tool care cere confirmare nu dovedește că serverul o impune tehnic. Între intenția exprimată și efectul comercial există limite de autorizare, validare și execuție care trebuie verificate separat.

De aici pornește o analiză distinctă: „Când AI-ul poate anula o comandă: cum securizezi un server MCP tranzacțional”. În acest articol, lecția rămâne arhitecturală: apariția unui client AI nu transferă către model autoritatea serviciilor comerciale.

17. Ce putem învăța ca ingineri

1. Modelul domeniului precedă framework-ul. Definește ce înseamnă rezervat, confirmat, pregătit și expediat.
2. Lumea fizică schimbă limitele tranzacțiilor. Un rollback software nu poate anula toate efectele operaționale.
3. Convergența stărilor trebuie proiectată. În modelul eventual consistency, stabilește întârzieri acceptabile, reconciliere și reguli pentru stări contradictorii.
4. Observabilitatea face parte din arhitectură. Fără corelare între operații, un răspuns HTTP corect poate ascunde un flux incomplet.
5. Izolarea între piețe trebuie păstrată până la ultimul consumer. Nu se termină la filtrul din interfață.
6. Agenții AI au nevoie de contracte mai precise. Numele, erorile, efectele și limitele instrumentelor trebuie să fie explicite.
7. MCP standardizează accesul, nu adevărul comercial. Autorizarea și sensul datelor rămân responsabilități distincte.
8. Permisiunile și confirmările fac parte din arhitectura de securitate. Nu le lăsa exclusiv în seama instrucțiunilor adresate modelului.

Sticla de kefir face vizibilă problema: utilizatorul cere o schimbare, iar infrastructura trebuie să o transforme într-o livrare posibilă. Agentul AI poate formula următoarea cerere. Sistemul trebuie să verifice dacă aceasta este autorizată, dacă mai este fezabilă și ce s-a întâmplat în realitate.

Pentru verificări practice privind lansarea și responsabilitatea operațională, consultă resursele FiraCode. Despre autor poți citi pe pagina studioului și fondatorului.

Analiză independentă bazată pe surse tehnice Rohlik Group, Sezamo și MCP, precum și pe examinarea metadatelor conectorului Sezamo. Nu au fost executate operații asupra conturilor sau comenzilor pentru acest articol. Diagramele conceptuale nu reprezintă documentație internă Rohlik. FiraCode nu este afiliat cu Rohlik sau Sezamo.