Middleware cu Om în Buclă în Python: Construirea Agenților AI Siguri cu Fluxuri de Aprobare

Introducere

Construirea agenților AI care pot executa autonom instrumente și lua decizii este puternică, dar vine cu riscuri inerente. Ce se întâmplă când un agent decide să trimită un email cu informații incorecte, să aprobe o tranzacție financiară mare sau să modifice înregistrări critice dintr-o bază de date? Fără măsuri de siguranță adecvate, agenții autonomi pot cauza daune semnificative înainte ca cineva să realizeze ce s-a întâmplat. Aici devine esențial middleware-ul cu om în buclă. În acest ghid cuprinzător, vom explora cum să implementezi middleware cu om în buclă în Python folosind LangChain, permițându-ți să construiești agenți AI care se opresc pentru aprobare umană înainte de a executa operațiuni sensibile. Vei învăța cum să adaugi fluxuri de aprobare, să implementezi capabilități de editare și să gestionezi respingerile—totul păstrând eficiența și inteligența sistemelor tale autonome.

Înțelegerea buclelor agentului AI și a execuției instrumentelor

Înainte de a intra în detaliile middleware-ului cu om în buclă, este esențial să înțelegem cum funcționează fundamental agenții AI. Un agent AI operează printr-o buclă continuă care se repetă până când agentul decide că și-a îndeplinit sarcina. Bucla de bază a agentului constă din trei componente principale: un model lingvistic care raționează ce să facă în continuare, un set de instrumente pe care agentul le poate invoca pentru a acționa și un sistem de gestionare a stării care urmărește istoricul conversației și orice context relevant. Agentul începe prin a primi un mesaj de intrare de la un utilizator, apoi modelul lingvistic analizează această intrare împreună cu instrumentele disponibile și decide dacă să apeleze un instrument sau să ofere un răspuns final. Dacă modelul decide să apeleze un instrument, acel instrument este executat, iar rezultatele sunt adăugate înapoi la istoricul conversației. Acest ciclu continuă—raționament al modelului, selecție de instrument, execuție de instrument, integrare a rezultatului—până când modelul determină că nu mai sunt necesare apeluri de instrument și oferă un răspuns final utilizatorului.

Acest model simplu, dar puternic, a devenit fundația pentru sute de framework-uri de agenți AI în ultimii ani. Eleganța buclei agentului constă în flexibilitatea sa: schimbând instrumentele disponibile pentru un agent, îi poți permite să îndeplinească sarcini extrem de diverse. Un agent cu instrumente de email poate gestiona comunicări, un agent cu instrumente de baze de date poate interoga și actualiza înregistrări, iar un agent cu instrumente financiare poate procesa tranzacții. Totuși, această flexibilitate introduce și riscuri. Deoarece bucla agentului operează autonom, nu există un mecanism implicit de a pune pauză și de a întreba un om dacă o anumită acțiune ar trebui cu adevărat efectuată. Modelul ar putea decide să trimită un email, să execute o interogare în baza de date sau să aprobe o tranzacție financiară, iar până când un om își dă seama ce s-a întâmplat, acțiunea a fost deja realizată. Aici devin evidente limitările buclei de bază a agentului în mediile de producție.

De ce este importantă supravegherea umană în sistemele AI de producție

Pe măsură ce agenții AI devin mai capabili și sunt implementați în medii reale de business, nevoia de supraveghere umană devine din ce în ce mai critică. Miza acțiunilor autonome ale agentului variază dramatic în funcție de context. Unele apeluri de instrument sunt cu risc scăzut și pot fi executate imediat fără revizuire umană—de exemplu, citirea unui email sau preluarea de informații dintr-o bază de date. Alte apeluri de instrument sunt cu miză ridicată și potențial ireversibile, cum ar fi trimiterea de comunicări în numele unui utilizator, transferul de fonduri, ștergerea de înregistrări sau asumarea de angajamente care obligă o organizație. În sistemele de producție, costul unei greșeli a unui agent într-o operațiune cu miză ridicată poate fi enorm. Un email formulat greșit, trimis destinatarului nepotrivit, poate afecta relațiile de business. Un buget aprobat incorect poate duce la pierderi financiare. O ștergere a unei baze de date executată din greșeală poate duce la pierderi de date care necesită ore sau zile pentru restaurare din backup.

Dincolo de riscurile operaționale imediate, există și considerații de conformitate și reglementare. Multe industrii au cerințe stricte ca anumite tipuri de decizii să implice judecată și aprobare umană. Instituțiile financiare trebuie să aibă supraveghere umană pentru tranzacții peste anumite praguri. Sistemele medicale trebuie să aibă revizuire umană pentru anumite decizii automate. Firmele de avocatură trebuie să asigure că toate comunicările sunt revizuite înainte de a fi trimise în numele clienților. Aceste cerințe nu sunt doar birocrație—ele există pentru că consecințele deciziilor complet autonome în aceste domenii pot fi severe. În plus, supravegherea umană oferă un mecanism de feedback care ajută la îmbunătățirea agentului în timp. Când un om revizuiește acțiunea propusă de agent și o aprobă sau sugerează modificări, acel feedback poate fi folosit pentru a rafina prompturile agentului, a ajusta logica selecției instrumentelor sau a antrena din nou modelele de bază. Acest lucru creează un ciclu virtuosos în care agentul devine mai fiabil și mai bine calibrat la nevoile și toleranța la risc a organizației.

Ce este middleware-ul cu om în buclă?

Middleware-ul cu om în buclă este o componentă specializată care interceptează bucla agentului într-un moment critic: chiar înainte ca un instrument să fie executat. În loc să permită agentului să ruleze imediat un apel de instrument, middleware-ul oprește execuția și prezintă acțiunea propusă unui om pentru revizuire. Omul are apoi mai multe opțiuni privind modul de răspuns. Poate aproba acțiunea, permițându-i să continue exact așa cum a propus agentul. Poate edita acțiunea, modificând parametrii (cum ar fi schimbarea destinatarului emailului sau ajustarea conținutului mesajului) înainte de a permite execuția. Sau poate respinge acțiunea în totalitate, trimițând feedback înapoi agentului cu explicația de ce acțiunea a fost nepotrivită și cerându-i să regândească abordarea. Acest mecanism de decizie în trei direcții—aprobă, editează, respinge—oferă un cadru flexibil care acomodează diferite tipuri de nevoi de supraveghere umană.

Middleware-ul funcționează prin modificarea buclei standard a agentului pentru a include un punct suplimentar de decizie. În bucla de bază a agentului, secvența este: modelul apelează instrumente → instrumentele se execută → rezultatele revin la model. Cu middleware-ul cu om în buclă, secvența devine: modelul apelează instrumente → middleware-ul interceptează → omul revizuiește → omul decide (aprobă/editează/respinge) → dacă e aprobat sau editat, instrumentul se execută → rezultatele revin la model. Această inserare a unui punct de decizie uman nu rupe bucla agentului; dimpotrivă, o îmbunătățește adăugând o supapă de siguranță. Middleware-ul este configurabil, ceea ce înseamnă că poți specifica exact ce instrumente ar trebui să declanșeze revizuire umană și ce instrumente pot fi executate automat. Poate vrei să întrerupi toate instrumentele de trimitere email, dar să permiți interogările read-only în bază de date fără revizuire. Acest control granular asigură că adaugi supraveghere umană exact acolo unde este nevoie, fără a crea blocaje inutile pentru operațiuni cu risc scăzut.

Cele trei tipuri de răspuns: Aprobare, Editare și Respingere

Când middleware-ul cu om în buclă întrerupe execuția unui instrument al agentului, revizorul uman are trei moduri principale de a răspunde, fiecare servind unui scop diferit în fluxul de aprobare. Înțelegerea acestor trei tipuri de răspuns este esențială pentru proiectarea unor sisteme eficiente cu om în buclă.

Aprobare este cel mai simplu tip de răspuns. Când un om revizuiește un apel de instrument propus și determină că este potrivit și ar trebui să continue exact așa cum a propus agentul, oferă o decizie de aprobare. Acest lucru semnalează middleware-ului că instrumentul trebuie executat cu parametrii exacți specificați de agent. În contextul unui asistent de email, aprobarea înseamnă că draftul de email arată bine și poate fi trimis destinatarului specificat cu subiectul și conținutul indicate. Aprobarea este calea cu cea mai mică rezistență—permite acțiunii propuse de agent să continue fără modificări. Acest lucru este potrivit când agentul și-a îndeplinit sarcina corect, iar revizorul uman este de acord cu acțiunea propusă. Deciziile de aprobare se iau, de obicei, rapid, ceea ce este important pentru a nu transforma revizuirea umană într-un blocaj care încetinește întregul flux.

Editarea este un tip de răspuns mai nuanțat care recunoaște că abordarea generală a agentului este corectă, dar anumite detalii trebuie ajustate înainte de execuție. Când un om oferă un răspuns de editare, nu respinge decizia agentului de a acționa; mai degrabă, rafinează detaliile acțiunii. Într-un scenariu de email, editarea ar putea însemna schimbarea adresei destinatarului, modificarea subiectului pentru a fi mai profesional sau ajustarea conținutului pentru a adăuga context suplimentar sau a elimina limbajul problematic. Caracteristica cheie a unui răspuns de editare este că modifică parametrii instrumentului păstrând același apel de instrument. Agentul a decis să trimită un email, iar omul este de acord că aceasta este acțiunea corectă, dar dorește să ajusteze ce conține emailul sau cui îi este trimis. După ce omul oferă editările, instrumentul se execută cu parametrii modificați, iar rezultatele revin la agent. Această abordare este valoroasă pentru că permite agentului să propună acțiuni, oferind în același timp oamenilor posibilitatea de a le ajusta pe baza expertizei lor de domeniu sau a contextului organizațional de care agentul poate să nu fie conștient.

Respingerea este cel mai semnificativ tip de răspuns deoarece nu doar oprește execuția acțiunii propuse, ci și trimite feedback înapoi agentului explicând de ce acțiunea era nepotrivită. Când un om respinge un apel de instrument, transmite că acțiunea propusă de agent nu trebuie executată deloc și oferă îndrumări despre cum agentul ar trebui să-și regândească abordarea. În exemplul cu emailul, respingerea poate apărea când agentul propune trimiterea unui email de aprobare a unei cereri de buget major fără suficiente detalii sau justificare. Omul respinge această acțiune și oferă un mesaj agentului explicând că este nevoie de mai multe detalii înainte de a putea fi dată aprobarea. Acest mesaj de respingere devine parte din contextul agentului, care poate apoi să raționeze pe baza feedback-ului și să propună o abordare revizuită. Agentul ar putea apoi propune un alt email în care cere mai multe informații despre propunerea de buget înainte de a se angaja la aprobare. Răspunsurile de respingere sunt cruciale pentru a preveni ca agentul să propună repetat aceeași acțiune nepotrivită. Oferind feedback clar despre motivul respingerii, ajuți agentul să învețe și să-și îmbunătățească deciziile.

Implementarea middleware-ului cu om în buclă: Un exemplu practic

Să parcurgem o implementare concretă a middleware-ului cu om în buclă folosind LangChain și Python. Exemplul este un asistent de email—un scenariu practic ce demonstrează valoarea supravegherii umane, fiind ușor de înțeles. Asistentul de email va putea trimite emailuri în numele utilizatorului, iar noi vom adăuga middleware cu om în buclă pentru a ne asigura că toate trimiterile de email sunt revizuite înainte de execuție.

Mai întâi, trebuie să definim instrumentul de email pe care agentul nostru îl va folosi. Acest instrument primește trei parametri: adresa destinatarului, subiectul și conținutul emailului. Instrumentul este simplu—reprezintă pur și simplu acțiunea de a trimite un email. Într-o implementare reală, acesta s-ar putea integra cu un serviciu de email precum Gmail sau Outlook, dar pentru demonstrație îl păstrăm simplu. Iată structura de bază:

def send_email(recipient: str, subject: str, body: str) -> str:
    """Trimite un email către destinatarul specificat."""
    return f"Email trimis către {recipient} cu subiectul '{subject}'"

Apoi, creăm un agent care folosește acest instrument de email. Vom folosi GPT-4 ca model lingvistic și vom furniza un prompt de sistem care îi spune agentului că este un asistent de email util. Agentul este inițializat cu instrumentul de email și este gata să răspundă solicitărilor utilizatorului:

from langchain.agents import create_agent
from langchain_openai import ChatOpenAI

model = ChatOpenAI(model="gpt-4o")
tools = [send_email]

agent = create_agent(
    model=model,
    tools=tools,
    system_prompt="Ești un asistent de email util pentru Sydney. Poți trimite emailuri în numele utilizatorului."
)

În acest punct, avem un agent de bază care poate trimite emailuri. Totuși, nu există supraveghere umană—agentul poate trimite emailuri fără nicio revizuire. Acum să adăugăm middleware-ul cu om în buclă. Implementarea este remarcabil de simplă, necesitând doar două linii de cod:

from langchain.agents.middleware import HumanInTheLoopMiddleware

agent = create_agent(
    model=model,
    tools=tools,
    system_prompt="Ești un asistent de email util pentru Sydney. Poți trimite emailuri în numele utilizatorului.",
    middleware=[
        HumanInTheLoopMiddleware(
            interrupt_on={"send_email": True}
        )
    ]
)

Prin adăugarea HumanInTheLoopMiddleware și specificarea interrupt_on={"send_email": True}, spunem agentului să pună pauză înainte de a executa orice apel de tip send_email și să aștepte aprobarea umană. Valoarea True înseamnă că toate apelurile send_email vor declanșa o întrerupere cu configurația implicită. Dacă am dori un control mai granular, am putea specifica ce tipuri de decizii sunt permise (aprobă, editează, respinge) sau să oferim descrieri personalizate pentru întrerupere.

Testarea middleware-ului cu scenarii cu miză scăzută

Odată ce middleware-ul este activ, să-l testăm într-un scenariu de email cu miză scăzută. Să presupunem că un utilizator îi cere agentului să răspundă la un email casual de la o colegă pe nume Alice, care propune o cafea săptămâna viitoare. Agentul procesează solicitarea și decide să trimită un email prietenos de răspuns. Iată ce se întâmplă:

1. Utilizatorul trimite un mesaj: “Te rog să răspunzi la emailul lui Alice despre cafeaua de săptămâna viitoare.”
2. Modelul lingvistic procesează solicitarea și decide să apeleze instrumentul send_email cu parametri de genul recipient=“alice@example.com ”, subject=“Cafeluța săptămâna viitoare?”, body=“Mi-ar plăcea să bem o cafea săptămâna viitoare!”
3. Înainte ca emailul să fie trimis, middleware-ul interceptează apelul de instrument și ridică o întrerupere.
4. Revizorul uman vede emailul propus și îl analizează. Emailul pare potrivit—este prietenos, profesional și răspunde cererii utilizatorului.
5. Omul aprobă acțiunea oferind o decizie de aprobare.
6. Middleware-ul permite executarea instrumentului, iar emailul este trimis.

Acest flux demonstrează calea de aprobare de bază. Revizuirea umană adaugă un nivel suplimentar de siguranță fără a încetini semnificativ procesul. Pentru operațiuni cu miză scăzută ca aceasta, aprobarea se întâmplă rapid pentru că acțiunea propusă de agent este rezonabilă și nu necesită modificări.

Testarea middleware-ului cu scenarii cu miză ridicată: Răspunsul de editare

Acum să considerăm un scenariu mai important, unde editarea devine valoroasă. Agentul primește o cerere de a răspunde la un email de la un partener startup care îi solicită utilizatorului să aprobe un buget de 1 milion de dolari pentru Q1. Aceasta este o decizie cu miză mare, care necesită atenție sporită. Agentul ar putea propune un email de genul: “Am analizat și aprobat propunerea pentru bugetul de 1 milion de dolari pentru Q1.”

Când acest email propus ajunge la revizorul uman prin întreruperea middleware-ului, omul recunoaște că este un angajament financiar semnificativ care nu ar trebui aprobat fără o analiză amănunțită. Omul nu vrea să respingă ideea de a răspunde la email, dar dorește să modifice răspunsul pentru a fi mai precaut. Oferă un răspuns de editare care modifică conținutul emailului pentru a spune, de exemplu: “Mulțumesc pentru propunere. Aș vrea să analizez mai atent detaliile înainte de a oferi aprobarea. Poți să-mi trimiți o defalcare a modului în care va fi alocat bugetul?”

Exemplu de răspuns de editare în cod:

edit_decision = {
    "type": "edit",
    "edited_action": {
        "name": "send_email",
        "args": {
            "recipient": "partner@startup.com",
            "subject": "Propunere Buget Inginerie Q1",
            "body": "Mulțumesc pentru propunere. Aș vrea să analizez mai atent detaliile înainte de a oferi aprobarea. Poți să-mi trimiți o defalcare a modului în care va fi alocat bugetul?"
        }
    }
}

Când middleware-ul primește această decizie de editare, execută instrumentul cu parametrii modificați. Emailul este trimis cu conținutul revizuit de om, mult mai potrivit pentru o decizie financiară cu miză ridicată. Acest lucru demonstrează puterea răspunsului de editare: permite oamenilor să beneficieze de capacitatea agentului de a redacta comunicări, asigurând în același timp că rezultatul final reflectă judecata umană și standardele organizației.

Testarea middleware-ului cu respingere și feedback

Tipul de răspuns de respingere este deosebit de puternic pentru că nu doar oprește o acțiune nepotrivită, ci oferă și feedback care ajută agentul să-și îmbunătățească raționamentul. Să considerăm același scenariu cu bugetul ridicat. Să presupunem că agentul propune un email de genul: “Am analizat și aprobat bugetul de 1 milion de dolari pentru Q1.”

Revizorul uman vede acest lucru și realizează că decizia este mult prea pripită. Un angajament de 1 milion de dolari nu trebuie aprobat fără o analiză extinsă, discuții cu factorii de decizie și înțelegerea detaliilor bugetului. Omul nu vrea doar să editeze emailul, ci să respingă această abordare și să ceară agentului să regândească. Oferă un răspuns de respingere cu feedback:

reject_decision = {
    "type": "reject",
    "message": "Nu pot aproba acest buget fără mai multe informații. Te rog să redactezi un email prin care să soliciți o defalcare detaliată a propunerii, inclusiv modul de alocare a fondurilor pe echipele de inginerie și rezultatele așteptate."
}

Când middleware-ul primește această decizie de respingere, nu execută instrumentul. În schimb, trimite mesajul de respingere înapoi agentului ca parte a contextului conversațional. Agentul vede acum că acțiunea propusă a fost respinsă și înțelege de ce. Poate apoi să raționeze pe baza acestui feedback și să propună o altă abordare. În acest caz, agentul ar putea propune un nou email în care cere mai multe detalii despre propunerea de buget, ceea ce este un răspuns mult mai potrivit pentru o cerere financiară cu miză ridicată. Omul poate revizui această nouă propunere și fie să o aprobe, să o editeze sau să o respingă din nou, dacă este cazul.

Acest proces iterativ—propunere, revizuire, respingere cu feedback, nouă propunere—este unul dintre cele mai valoroase aspecte ale middleware-ului cu om în buclă. Creează un flux colaborativ unde viteza și raționamentul agentului se combină cu judecata umană și expertiza de domeniu.

Configurare avansată: Control granular al întreruperilor

Deși implementarea de bază a middleware-ului cu om în buclă este simplă, LangChain oferă opțiuni avansate de configurare care îți permit să ajustezi exact cum și când apar întreruperile. O opțiune importantă este specificarea tipurilor de decizii permise pentru fiecare instrument. De exemplu, poți permite aprobare și editare pentru trimiterea de emailuri, dar nu și respingere. Sau poți permite toate cele trei tipuri de decizie pentru tranzacții financiare, dar doar aprobare pentru interogări read-only în baze de date.

Exemplu de configurare granulară:

from langchain.agents.middleware import HumanInTheLoopMiddleware

agent = create_agent(
    model=model,
    tools=tools,
    middleware=[
        HumanInTheLoopMiddleware(
            interrupt_on={
                "send_email": {
                    "allowed_decisions": ["approve", "edit", "reject"]
                },
                "read_database": False,  # Aprobare automată, fără întrerupere
                "delete_record": {
                    "allowed_decisions": ["approve", "reject"]  # Fără editare pentru ștergeri
                }
            }
        )
    ]
)

În această configurație, trimiterea de emailuri va întrerupe și va permite toate cele trei tipuri de decizie. Operațiunile de citire se execută automat fără întrerupere. Operațiunile de ștergere vor genera întrerupere dar nu permit editarea—omul poate doar aproba sau respinge, fără a modifica parametrii ștergerii. Acest control granular asigură că supravegherea umană este adăugată exact unde este nevoie, evitând blocajele inutile pentru operațiuni cu risc scăzut.

O altă funcționalitate avansată este posibilitatea de a furniza descrieri personalizate pentru întreruperi. Implicit, middleware-ul oferă o descriere generică precum “Execuția instrumentului necesită aprobare.” Poți personaliza acest mesaj pentru a oferi mai mult context:

HumanInTheLoopMiddleware(
    interrupt_on={
        "send_email": {
            "allowed_decisions": ["approve", "edit", "reject"],
            "description": "Trimiterile de email necesită aprobare umană înainte de execuție"
        }
    }
)

Considerente importante de implementare: Checkpointere și gestionarea stării

Un aspect esențial al implementării middleware-ului cu om în buclă, adesea trecut cu vederea, este nevoia unui checkpointer. Un checkpointer este un mecanism care salvează starea agentului în momentul întreruperii, permițând reluarea fluxului ulterior. Acest lucru este esențial pentru că revizuirea umană nu are loc instantaneu—poate exista o întârziere între momentul întreruperii și momentul în care omul oferă decizia. Fără un checkpointer, starea agentului s-ar pierde în acest interval și nu ai putea relua corect fluxul.

LangChain pune la dispoziție mai multe opțiuni de checkpointer. Pentru dezvoltare și testare, poți folosi un checkpointer în memorie:

from langgraph.checkpoint.memory import InMemorySaver

checkpointer = InMemorySaver()

agent = create_agent(
    model=model,
    tools=tools,
    checkpointer=checkpointer,
    middleware=[
        HumanInTheLoopMiddleware(
            interrupt_on={"send_email": True}
        )
    ]
)

Pentru sistemele de producție, vei dori de obicei un checkpointer persistent care să salveze starea într-o bază de date sau sistem de fișiere, asigurând reluarea întreruperilor chiar dacă aplicația se restartează. Checkpointer-ul menține o evidență completă a stării agentului la fiecare pas, inclusiv istoricul conversației, orice apeluri de instrument efectuate și rezultatele acestora. Când omul oferă o decizie (aprobare, editare sau respingere), middleware-ul folosește checkpointer-ul pentru a prelua starea salvată, aplică decizia umană și reia bucla agentului din acel punct.

Aplicații și cazuri de utilizare reale

Middleware-ul cu om în buclă este aplicabil într-o varietate largă de scenarii reale în care agenții autonomi trebuie să acționeze, dar acele acțiuni necesită supraveghere umană. În servicii financiare, agenții care procesează tranzacții, aprobă credite sau gestionează investiții pot folosi middleware-ul cu om în buclă pentru a se asigura că deciziile cu valoare mare sunt revizuite de oameni calificați înainte de execuție. În sănătate, agenții care recomandă tratamente sau accesează dosare de pacienți pot folosi middleware pentru a respecta regulamentele de confidențialitate și protocoalele clinice. În servicii juridice, agenții care redactează comunicări sau accesează documente confidențiale pot folosi middleware-ul pentru a asigura supravegherea avocaților. În servicii clienți, agenții care pot emite rambursări, face angajamente către clienți sau escalada probleme pot folosi middleware-ul pentru a se asigura că acțiunile respectă politicile companiei.

Dincolo de aceste aplicații specifice industriilor, middleware-ul cu om în buclă este valoros în orice scenariu unde costul unei greșeli a agentului este semnificativ. Asta include sisteme de moderare a conținutului în care agenții pot elimina conținut generat de utilizatori, sisteme HR unde agenții pot procesa decizii de angajare și sisteme de lanț de aprovizionare unde agenții pot plasa comenzi sau ajusta stocurile. Elementul comun pentru toate aceste aplicații este că acțiunile propuse de agent au consecințe reale, iar acele consecințe sunt suficient de importante pentru a justifica revizuirea umană înainte de execuție.

Comparație cu abordări alternative

Merită să analizăm cum se compară middleware-ul cu om în buclă cu alte abordări pentru adăugarea supravegherii umane în sistemele cu agenți. O alternativă este ca oamenii să revizuiască toate ieșirile agentului după execuție, dar această abordare are limitări majore. Până când un om revizuiește acțiunea, aceasta a fost deja executată și poate fi dificil sau imposibil de anulat. Un email a fost deja trimis, o înregistrare din baza de date a fost deja ștearsă sau o tranzacție financiară a fost deja procesată. Middleware-ul cu om în buclă previne ca aceste acțiuni ireversibile să aibă loc.

O altă alternativă este ca oamenii să efectueze manual toate sarcinile pe care le-ar putea face agenții, dar astfel pierdem avantajele automatizării. Agenții sunt valoroși tocmai pentru că pot gestiona rapid și eficient sarcinile de rutină, eliberând oamenii pentru decizii de nivel mai înalt. Scopul middleware-ului cu om în buclă este să găsească echilibrul: agenții să gestioneze munca de rutină, dar să se oprească pentru revizuire umană când miza