Kas sprendžia, kai agentas perduoda užduotį?

Delegavimas gali padaryti dirbtinio intelekto darbo eigą pajėgesnę, bet ne atskaitingesnę. Skirtumas tas, ar įgaliojimai, įrodymai ir teisė sustoti lieka...

Kas sprendžia, kai agentas perduoda užduotį?

Perdavimas neištuština kėdės

Agentas perduoda užduotį. Kitas agentas renka medžiagą, lygina įrašus, kviečia įrankį arba rengia rekomendaciją. Trečiasis agentas tikrina rezultatą. Darbas juda, ir tas judėjimas gali būti naudingas. Jis taip pat gali sukurti labai seną valdymo problemą nauja forma: visi kažką padarė, tačiau niekas negali pasakyti, kas turėjo teisę priimti sprendimą.

Vilioklis atsakymas yra agentas, kuris atliko paskutinį veiksmą. Tai taip pat dažniausiai mažiausiai naudingas atsakymas. Programinės įrangos komponentas gali pasirinkti maršrutą, paprašyti daugiau darbo ir pateikti nurodymą prijungtai sistemai. Nė vienas iš šių dalykų nenustato, kas priėmė tikslą, kas nustatė ribas, kas galėjo atsisakyti veiksmo arba kam turėjo būti pranešta pasikeitus sąlygoms. Tai tik nustato, kad programoje buvo grandinės dalis.

Tas skirtumas tampa ryškus, kai darbo eiga turi pasekmių. Pasiūlytas atsakymas gali tapti bendravimu su klientu. Klasifikacija gali tapti priežastimi, dėl kurios byla patenka į tam tikrą eilę. Palyginimas gali tapti pirkimo rekomendacija. Suplanuotas mokėjimo nurodymas gali tapti mokėjimu. Kiekvienas žingsnis gali būti techniškai kompetentingas ir vis tiek organizaciškai neišsamus. Sistema atliko perdavimo darbą, neatlikdama įgaliojimų darbo.

Nereikia sugalvoti dramatiškos nesėkmės, kad pamatytumėte problemą. Paimkite sąmoningai hipotetinę darbo eigą. Pirminio vertinimo agentas gauna klausimą, paprašo tyrimų agento išnagrinėti atitinkamą medžiagą, nusiunčia rezultatą recenzentui ir tada parengia veiksmą bylų valdymo sistemai. Tyrimų agentas nėra įgaliotas veikti. Recenzentas nėra įgaliotas įgyvendinti bylos baigtį. Pirminio vertinimo agentas turi įrankio kredencialą. Organizacija nenurodė, ar tas kredencialas leidžia jam įvykdyti rezultatą. Darbo eiga prietaisų skydelyje gali atrodyti tvarkinga. Vis dėlto ji pasiekė svarbiausią klausimą be atsakymo.

Perdavimas nėra atsakomybės išnykimas. Tai atsakomybė, kurią sunkiau pamatyti. Geras veiklos dizainas vėl ją palengvina. Jis nurodo, koks yra pradinis sprendimas, ką galima perduoti, kokios sąlygos keliauja kartu su užduotimi, kas gali patvirtinti negrįžtamą ar reikšmingą veiksmą, koks įrašas lieka po perdavimo ir kaip žmogus ar sistema gali įsikišti, kai maršrutas nebėra saugus. Iš technologijos nereikalaujama turėti moralinę veikimo galią. Iš jos reikalaujama palikti organizacijos veikimo galią nepažeistą.

Tai praktinė atskaitomybės reikšmė kelių agentų darbo eigoje. Tai ne dekoratyvi eilutė politikoje ir ne retrospektyvi artimiausio darbuotojo paieška, kai kas nors nepavyksta. Tai maršruto savybė prieš prasidedant darbui. Tinkamas žmogus gali peržiūrėti, kas buvo pasiūlyta, suprasti, kodėl tai buvo pasiūlyta, įgyvendinti jam priskirtus įgaliojimus ir palikti įrašą, kurį vėliau galima užginčyti.

Europos besiformuojančios dirbtinio intelekto taisyklės čia naudingos, nes joms mažiau rūpi teatrališkas žmogus srauto gale nei sąlygos, kuriomis priežiūra iš tikrųjų gali veikti. Dirbtinio intelekto akto žmogiškosios priežiūros nuostatos taikomos didelės rizikos sistemoms, o ne kiekvienam agento naudojimui. Ta riba svarbi. Tačiau akte keliami veiklos klausimai puikiai tinka: ar paskirtas fizinis asmuo gali suprasti atitinkamus gebėjimus ir apribojimus, stebėti anomalijas ir netikėtą veikimą, vengti pernelyg didelio pasikliovimo, interpretuoti išvestį, ignoruoti arba panaikinti ją ir sustabdyti sistemą saugioje būsenoje? Darbo eiga su daugybe agentų šių klausimų nesumažina. Ji padaugina vietų, kuriose atsakymas gali pasimesti.

Delegavimas gali perduoti darbą į priekį. Jis negali panaikinti kelio, kuriuo įgaliojimai ir iššūkiai grįžta atgal.

Delegavimas yra grandinė, ne migla

Žmonės deleguoja nuolat. Vadovas paprašo kolegos parengti pastabą. Pirkimų komanda paprašo eksperto patikrinti sutarties sąlygą. Klinikistas paprašo laboratorijos rezultato. Asmuo, gaunantis užduotį, įgyja apibrėžtą vaidmenį darbe; jis neautomatiškai paveldi visus įgaliojimus, kuriuos turi paprašęs asmuo. Geros organizacijos šį kasdienį skirtumą įtvirtina pareigybių aprašymais, tvirtinimo ribomis, procedūromis, pareigų atskyrimu ir įrašais. Jos tai daro, nes gebėjimas ir leidimas yra skirtingi dalykai.

Agentų sistemos linkusios šį skirtumą ištrinti, nes agentas gali apibūdinti, planuoti ir vykdyti vienoje pokalbio erdvėje. Modelis gali sugebėti parengti įtikinamą planą, kaip susisiekti su tiekėju. Įrankio apvalkalas gali techniškai sugebėti išsiųsti pranešimą. Orkestravimo sluoksnis gali sugebėti iškviesti tą apvalkalą be pauzės. Šie faktai apibūdina gebėjimą. Jie nenusprendžia, ar pranešimas turėtų būti išsiųstas, ar siūlomas gavėjas yra apimtyje, ar informacija tinkama atskleisti, ar kas turėtų prisiimti pasekmes, jei siūlomas veiksmas yra neteisingas.

Padeda atskirti penkis klausimus, kurie dažnai sujungiami į vieną. Kas suteikė užduočiai jos tikslą? Kas gali atlikti parengiamąjį darbą? Kas gali deleguoti subt užduotį? Kas gali nuspręsti, kad siūlomas veiksmas yra priimtinas? Kas gali padaryti tą veiksmą veiksmingą išoriniame pasaulyje? Kartais vienas žmogaus vaidmuo tinkamai atsako į kelis iš šių klausimų. Kartais jie turi būti atskirti. Esmė ne sukurti išsamią ceremoniją mažos rizikos pastabai. Esmė vengti tyliai traktuoti techninį gebėjimą kaip institucinio įgaliojimo perdavimą.

Delegavimas todėl turėtų nešti daugiau nei instrukciją. Jis turėtų nešti įgaliojimą. Įgaliojimas apibrėžia tikslą, apribotą kontekstą, leidžiamus įvesties duomenis, laukiamą rezultatą, veiksmus, kurie lieka uždrausti, biudžetą ar laiko limitą, kai tai aktualu, sąlygas, reikalaujančias eskalavimo, ir asmenį ar vaidmenį, atsakingą už rezultatą. Gaunantis agentas tada gali atlikti naudingą darbą matomame apvalkale. Jis gali paprašyti kito agento analizės. Jis negali išplėsti apvalkalo vien todėl, kad jam ateina į galvą tikėtinas kitas žingsnis.

Tai ne argumentas paversti kiekvieną sąveiką tvirtinimo susitikimu. Tai argumentas pasirinkti tašką, kuriame organizacija nori, kad sprendimas įvyktų. Sistema gali parengti paaiškinimą be žmogaus, žiūrinčio į kiekvieną sakinį, kai tikslas, auditorija, šaltinio ribos ir publikavimo taisyklės jau yra nustatytos. Sistema neturėtų įgyti galios pakeisti kliento teisę vien todėl, kad tas pats komponentas turi prieigą prie atitinkamos duomenų bazės. Skirtumas yra pasekmė, ne modelio intelektas.

That consequence is often distributed. A task can be harmless at one stage and consequential at the next. Reading a file may be routine. Combining it with another source may change the sensitivity of the material. Preparing a recommendation may be routine. Pressing a button that creates a legal, financial or service outcome may not be. A governance design that asks only whether an agent is autonomous misses this change of state. The useful question is narrower: autonomous to do what, for whom, against which conditions, and with whose authority?

There is a modest Dutch instinct worth keeping here. If a process needs a dozen signs, stamps and a laminated flowchart to establish who may press one button, it may not be a triumph of governance. But the opposite arrangement, in which a tool credential is treated as a constitutional settlement, is not a triumph either. The aim is a proportionate route that makes consequential authority clear without staging a small opera around every routine action.

European oversight is an operating requirement

The AI Act gives the clearest legal expression of this idea for high-risk AI systems. Article 14 requires them to be designed and developed so that natural persons can effectively oversee them while they are in use. The stated purpose is to prevent or minimise risks to health, safety and fundamental rights where those risks may remain despite other requirements. The measures must be commensurate with risk, autonomy and context of use. That is a deliberately operational standard. It does not say that a person somewhere in the organisation is generally interested in AI.

The provision goes further than a generic instruction to keep a human in the loop. Depending on what is appropriate and proportionate, the person assigned to oversight must be enabled to understand relevant capacities and limitations, monitor operation and detect anomalies, dysfunctions or unexpected performance, remain aware of automation bias, interpret output, decide not to use an output or to disregard, override or reverse it, and intervene or interrupt the system into a safe state. The law does not turn these into a universal checklist for every agent system. It does show why an end-of-process rubber stamp is a poor model of oversight.

Now add delegation. If an agent hands a task to another agent, the oversight role needs to be able to see more than the final sentence produced by the last model. It needs enough context to understand which agent proposed the subtask, which sources or tools were used, whether a policy limit was encountered, whether a result was changed by a reviewer, and whether a later agent extended the scope. Otherwise the human can see an output but not the route that produced it. That may be sufficient for a low-consequence draft. It is not a persuasive basis for accepting a consequential decision.

Article 26 makes the organisational point even plainer for deployers of high-risk systems. It says deployers are to assign human oversight to natural persons with the necessary competence, training, authority and support. Those words belong together. Competence without authority creates a well-informed bystander. Authority without competence creates a formal owner who cannot challenge the system. Both without support create a person expected to intervene in a process they cannot see, at a pace they cannot meet, using information they cannot interpret.

For multi-agent work, support includes the shape of the interface and record. An operator does not need every token a model generated or every internal retry. They do need the action being proposed, the named purpose, the material evidence, the policy and limit that apply, the changes made since the last review point, the expected effect, the possible reversal route, and the reason the case was escalated. This is less a question of making a dashboard look reassuring than of reducing the chance that a person will approve an answer because the system has made the alternative exhausting to find.

The Council of Europe Framework Convention on Artificial Intelligence and Human Rights, Democracy and the Rule of Law makes the broader institutional connection. Its purpose is to ensure that activities in the lifecycle of AI systems are consistent with human rights, democracy and the rule of law. Articles 8 and 9 call for transparency and oversight tailored to specific contexts and risks, and for accountability and responsibility for adverse impacts. The Convention does not prescribe an agent orchestration pattern. It does make a useful corrective to the idea that a chain of software components can dissolve the responsibilities of the public authority or private actor using it.

That broader view matters because a delegated decision can affect more than technical performance. It can affect a person's ability to understand a decision, contest it, obtain redress or simply know which organisation is responsible. A workflow may be made of components from several suppliers, models from several providers, tools operated by another team and a service delivered under a public contract. The fact that the chain is technically distributed does not make the impact on the individual less real. In practice, it makes a clear allocation of roles more important.

Data protection gives the same warning from a different direction. The European Data Protection Board's work on AI models emphasises that the data-protection analysis remains contextual: organisations must determine their role, identify the processing involved and apply the relevant obligations rather than treating the label AI model as an exemption from ordinary accountability. When a multi-agent workflow touches personal data, delegation should not obscure who determines the purposes and means of the processing, which agent or tool receives which data, and whether the next handover is necessary for the task. A subtask is still a processing step. Calling it a delegation does not make it disappear.

None of this produces a magic answer to every hard case. The legal obligations depend on the use, the actors, the data and the sector. An article cannot classify a particular system. But it can state a disciplined principle: if a workflow distributes work, it should distribute it in a way that preserves the ability to identify authority, intervene in time, account for the route and respond to the people affected by the outcome.

The person in the loop needs a real loop

Human oversight is easily reduced to a screen with an approve button. That screen can be useful. It can also be a ceremonial object. The question is whether the person using it has a meaningful choice. A choice is not meaningful merely because the interface displays two buttons. It depends on whether the person has enough time, information, competence and institutional permission to decide differently.

Laikas yra mažiausiai patraukli dizaino dalis ir dažnai pati lemiamiausia. Jei sistema išsiunčia šimtus pasiūlymų per laikotarpį, per kurį vienas vertintojas galėtų pagrįstai peržiūrėti tik dalį jų, organizacija sukūrė eilę, o ne priežiūrą. Jei pasiūlymas nustoja galioti, kol vertintojas dar nespėjo susipažinti su kontekstu, sistema padarė greitį faktiniu sprendimų priėmėju. Jei komanda skatinama tik už pralaidumą, jai tyliai nurodoma, kurį mygtuką spausti. Programinė įranga negali išgydyti šių susitarimų pridėdama pasitikėjimo balą kitokio atspalvio žalia spalva.

Informacija turi būti proporcinga, o ne išsami. Vertintojas, gavęs tik išvadą, negali jos užginčyti. Vertintojas, gavęs neapdorotą visų agento sąveikų nuorašą, paprastai taip pat negali jos užginčyti. Naudingas vidurys yra sprendimų paketas. Jame nurodoma, koks veiksmas siūlomas, kodėl jis atitinka nustatytą tikslą, kokia esminė įrodymų medžiaga jį pagrindžia, koks neapibrėžtumas išlieka, kuri politika ar taisyklė yra aktuali, koks būtų siūlomas poveikis ir kas nutiktų, jei veiksmas nebūtų patvirtintas. Paketas turėtų pateikti nuorodas į išsamesnius įrodymus, tačiau įprastu atveju neturėtų reikalauti archeologinės ekspedicijos.

Kompetencija reiškia daugiau nei bendras kursas apie dirbtinį intelektą. Konkrečiai užduočiai vertintojas turi suprasti produkto tipą, žinomus apribojimus, kurie galėtų turėti reikšmės, kaip darbo eiga turėtų veikti ir kokie požymiai rodo, kad reikia perduoti aukštesniam lygiui. Žmogus, gebantis atpažinti neteisingą tiekėjo sąskaitą faktūrą, gali būti tinkamas vertinti su sąskaita susijusį pasiūlymą. Tas pats žmogus gali nebūti tinkamas vertinti modelio kalbos aprėptį arba duomenų apsaugos padarinius. Todėl priežiūros paskyrimas yra ir personalo sprendimas.

Institucinis leidimas yra išbandymas, kurio daugelis dizainų tyliai neišlaiko. Vertintojas turi galėti atmesti, sustabdyti ar pakeisti siūlomą kelią, nebūdamas laikomas sistemos gedimo priežastimi. Jam reikia prieigos prie asmens ar pareigybės, galinčios nuspręsti, kas bus toliau. Jam reikia būdo užfiksuoti, kad klausimas buvo perduotas aukštesniam lygiui. O sistemai reikia saugios būsenos, kurioje darbas galėtų laukti, nebūdamas netyčia įvykdytas pakartotinio bandymo, laiko pabaigos ar kito agento, laikančio pirminį nurodymą nebaigtu reikalu.

Saugos inžinerija jau seniai traktuoja žmogaus veiklą kaip sistemos dalį, o ne kaip paskutinį lako sluoksnį. Jungtinės Karalystės sveikatos ir saugos vykdomoji institucija žmogiškuosius veiksnius apibūdina kaip užduoties, individo ir organizacijos visumą ir įspėja nelaikyti jų atskirai. Tai yra protinga sistema agento priežiūrai. Vertintojas nėra abstraktus žmogiškas kištukas, užpildantis programinės įrangos spragą. Jis atlieka konkrečią užduotį, turėdamas konkrečią informaciją ir įrankius, konkrečioje organizacijoje, turinčioje konkrečių spaudimų ir apribojimų. Kontrolės kokybė priklauso nuo viso to.

Dėl šios priežasties geras žmogaus įtraukimo į procesą dizainas prasideda dar prieš atsirandant mygtukui. Jis apibrėžia, kuriems sprendimams reikia žmogaus užtvaros, kas ją valdys, kokius įrodymus gaus, kiek laiko užduotis leidžia, kas nutinka, kai vertintojo nėra, ir ar užtvara turi įgaliojimus pačiam veiksmui, ar tik veiksmo paaiškinimui. Jei organizacija negali atsakyti į šiuos klausimus ramų antradienį, nebus aiškiau ir atėjus didelės reikšmės atvejui. Ir jai neturėtų prireikti įsivaizduojamos krizės, kad tai pastebėtų.

Permissions should describe the consequence of an action, not merely the technical reach of a credential.

One task, several kinds of authority

A compact authority model can make an agent workflow easier to operate. It does not need to be grand. Start with the difference between reading, proposing, delegating, committing and stopping. A role allowed to read can inspect the material necessary for a task. A role allowed to propose can prepare a possible action. A role allowed to delegate can assign bounded work to another actor. A role allowed to commit can make a consequential action effective. A role allowed to stop can pause or halt a route when its conditions no longer hold.

These are not simply ranks. A compliance reviewer may be able to stop a workflow but not to commit a customer outcome. A specialist agent may be able to propose a route but not to delegate new work outside its domain. A manager may be accountable for the purpose of a service yet not be the person authorised to release a particular payment. The useful property is not a hierarchy for its own sake. It is that the system can evaluate whether a particular actor has the relevant authority for a particular action in the current context.

Context does much of the work. The same proposed action can be ordinary in one circumstance and consequential in another. Sending an already approved template to a known internal address may be within a routine communication mandate. Sending a newly drafted message with personal data to a new recipient is different. A refund within a defined threshold may be delegated to a well-tested process. A change to an entitlement, a data deletion or an external commitment may need a named human decision. The policy should express that distinction before the model is asked to plan around it.

There is also an important difference between an approval and an acknowledgement. An acknowledgement records that someone saw a message. An approval records that an authorised person accepted a defined action, with the relevant context, at a defined point in the route. In a conversational system those can look similar. The record should not. If a later reviewer cannot tell what action was approved and what effect was expected, the organisation has logged a conversation rather than captured a decision.

Delegation itself needs limits. An agent that receives a task to compare three existing proposals may be allowed to ask a research agent to extract relevant terms. It should not treat that permission as an invitation to contact suppliers, acquire new data or reframe the procurement objective. The boundary can be expressed in policy, in tool scope, in a structured task contract or in all three. What matters is that it is enforceable enough to constrain the route rather than merely describe the desired behaviour after the fact.

Delegacijos gylis yra dar viena riba, kurią verta įvardyti. Žmogus gali duoti agentui užduotį ir vis tiek aiškiai matyti pirmąjį jos perdavimą. Po kelių vienas į kitą įterptų perdavimų pirminis tikslas gali techniškai išlikti metaduomenyse, tačiau praktiškai tapti nematomas. Organizacijos gali nustatyti maksimalų delegacijos gylį tam tikros klasės darbams, reikalauti peržiūros tam tikrame gylyje arba uždrausti delegatui kurti tolesnius delegatus be naujo leidimo. Tai dizaino sprendimai, o ne universalūs reikalavimai. Jie naudingiausi tada, kai dėl ilgesnės grandinės sunku įžiūrėti, kuris veikėjas įvedė naują prielaidą ar pakeitė faktinę taikymo sritį.

Įrankių teisės taip pat turi būti atskirtos nuo modelio teisių. Modelis gali pasirinkti įrankį pagal planą. Įrankio integracija vis tiek turėtų patikrinti, ar prašomas veiksmas, tikslas, duomenų kategorija, išteklių riba ir darbo eigos būsena leidžia atlikti kvietimą. Tai ne modelio nepasitikėjimas moraline prasme. Tai įprastas ribų projektavimas. Gerai suformuotas planas vis tiek gali būti netinkamas konkrečiam atvejui, o prastai suformuotas planas neturėtų tapti realybe vien todėl, kad pasiekė plačios prieigos įgaliojimus.

Tas pats pasakytina ir apie atkūrimą. Pakartotinis bandymas ne visada yra nekenksmingas. Pakartotinai bandyti perskaityti viešą dokumentą nėra tas pats, kas pakartotinai bandyti išsiųsti žinutę ar atlikti mokėjimą. Kai deleguota užduotis nepavyksta, darbo eigoje reikia aiškaus pasirinkimo tarp pakartotinio bandymo, nukreipimo kitur, eskalavimo, pristabdymo ir kontroliuojamo žlugimo. Traktuojant juos kaip vieną bendrą klaidų tvarkytuvę, operacinis sprendimas tyliai priimamas pagal numatytuosius nustatymus. Agentų vykdymo aplinka gali padaryti šias parinktis prieinamas. Organizacija turi nuspręsti, kuri parinktis taikoma kuriai veiksmų klasei.

Nesėkmė dažnai yra nepriimtas sprendimas

Išgirdę žodį „nesėkmė“, žmonės dažnai įsivaizduoja agentą, pateikiantį klaidingą teiginį, arba įrankį, kuriam baigiasi laikas. Abu atvejai gali būti svarbūs. Tačiau deleguotame darbe dažnai labiau atskleidžiančios nesėkmės būna tylesnės. Užduotis buvo priskirta be aiškaus savininko. Pasiūlymas peržengė ribą, kurios niekas nebuvo modeliavęs. Recenzentas matė išvadą, bet ne įrodymus. Pakartotinis bandymas buvo tęsiamas po pristabdymo. Žmogus pastebėjo problemą, bet neturėjo įgaliojimų sustabdyti veiksmą. Sprendimas buvo priimtas, tačiau įraše liko tik galutinis rezultatas, o ne sąlyga, dėl kurios jis buvo priimtinas.

Tai nėra teiginiai apie konkretų įvykį. Tai nesėkmės modeliai, kylantys iš pačios delegacijos struktūros. Jų galima rasti ir žmogiškuose procesuose. Programinėje įrangoje jie vis dėlto gali sklisti automatizavimo greičiu ir kartotis labai nuosekliai. Toks nuoseklumas nėra priežastis nusiminti. Tai priežastis traktuoti darbo eigos projektavimą kaip kontrolės dalį, o ne manyti, kad vieno modelio komponento tikslumo testavimas išsprendžia klausimą.

Apsvarstykime dar vieną aiškiai hipotetinį dizainą. Agentui pavedama parengti bylos santrauką. Jis deleguoja dokumentų ištraukimą vienam komponentui, o kalbos normalizavimą kitam. Trečiasis komponentas mato neišsamų lauką ir naudoja prijungtą žinių šaltinį spragai užpildyti. Galutinė santrauka skaitosi sklandžiai. Jei darbo eiga neįrašė trūkstamo lauko, šaltinio, naudoto jam užpildyti, su juo susijusio pasitikėjimo ar neapibrėžtumo bei fakto, kad pirminė užduotis leido tik apibendrinti, recenzentas negali pasakyti, ar tvirtina santrauką, ar naujai sukurtą faktinį teiginį. Problema ne ta, kad paskutinis sakinys skamba keistai. Problema ta, kad užduoties prasmė pasikeitė kelyje.

A sound response is not to ban delegation. It is to put change points in the record. A new source, a new tool, a new data category, a new action class, a material change in confidence, a failed control, a longer-than-permitted delegation chain, or a proposal to cross an external boundary can each become a reason to surface the work for review. The exact triggers will differ by context. The principle is stable: a change that would matter to the accountable owner should not remain invisible because it occurred between components.

This is one place where safety-case thinking is useful. A safety case is not a promise that nothing can go wrong. It is a structured argument about why a system is acceptable for a defined purpose under defined conditions, with evidence, assumptions, controls and residual risks visible. Applied carefully to an agent workflow, that means the claim is not that agents are generally safe. The claim is narrower: this route may be used for this purpose, with these limits, because these controls and oversight arrangements exist, and it must be reconsidered when the stated assumptions no longer hold.

The workflow is then easier to challenge. An operator can ask whether the action class was properly assigned. A risk owner can ask whether the reviewer still has enough time. An engineer can ask whether a retry could create a duplicate effect. A data-protection specialist can ask whether the subtask remains necessary and proportionate. A person affected by an outcome can, where the applicable framework requires it, be given a route to question the decision. Those questions are not bureaucracy added after the interesting technical work. They are the work of making the technical system answerable in an organisation.

Metrics should follow the same discipline. Counting the number of delegated tasks tells us something about volume, not about accountable operation. More useful measures may include the rate at which a workflow escalates because a boundary changed, the time a decision waits at a gate, the proportion of consequential actions with a complete decision packet, the number of successful reversals, or the number of cases in which a policy check refused a tool call. Such measurements still need a definition and a context. They should never be invented for a brochure. But designing the records so they could be measured is a sign that accountability is being treated as an operating property.

The record is where responsibility survives

A multi-agent system produces an awkward kind of history. It has messages, tool calls, intermediate outputs, policy checks, model versions, timing information, retries, changed assignments and perhaps human approvals. Keeping every byte forever is neither necessary nor often appropriate. Keeping only the final answer is usually too little. The record needs to preserve the decisions and evidence that explain how the workflow crossed from a request to an outcome.

For a consequential action, that record should normally let a reviewer reconstruct a few basic facts. What was the objective? Which policy or mandate made the work permissible? Who or what received each assignment? What was proposed at each consequential gate? Which information was used to support the proposal? What limits, warnings or failures were encountered? Who held authority to approve, stop or reverse the action? What action became effective, and what happened afterwards? These are not exotic questions. They are the questions an organisation asks when it wants to know whether a decision was its decision.

The record should distinguish an operational fact from an explanation produced later. If a system says a reviewer approved an action, the event should record the identity or role of the reviewer, the action they were shown, the relevant context and the time at which the approval bound to that action. If the system says a model selected a delegate, the record should preserve the selection rule, candidates or criteria at the level appropriate for the use, and the resulting assignment. A later narrative can help a reader, but it should not replace the event that occurred.

Versioning matters here. An agent's output may be regenerated. A policy may be updated. A tool schema may change. A model endpoint may be swapped. If a decision depends on a particular version of a prompt, policy, model, knowledge source or integration, the record needs a stable reference to that version. Otherwise replay becomes a performance: it reproduces whatever the organisation happens to have now and calls the result an explanation of what happened then.

Reversibility deserves equal attention. The AI Act expressly refers, in the high-risk oversight context, to the ability to disregard, override or reverse an output and to interrupt a system so it comes to a halt in a safe state. In a multi-agent route, the safe state is not necessarily a stopped model process. It may mean no external communication is sent, a queued action is held, a downstream system is not updated, temporary credentials are no longer usable for the task, and the evidence needed to decide what happens next is retained. That is an operational inference from the oversight requirement, not a quotation of the law. It is also a useful design test.

Safe does not mean frozen forever. A halted workflow needs a controlled resumption path. Someone must decide whether to amend the task, discard the proposal, rerun a bounded part of the work, use a different tool, seek further evidence or abandon the route. A clean record makes that choice easier because it tells the next person what is known, what was attempted, why the work stopped and which effects have and have not occurred. Without that record, recovery becomes another unstructured delegation, usually undertaken under more pressure than the first one.

This is why retention and access need their own decisions. Not every actor should be able to read every trace. A record may contain personal data, commercially sensitive material or security-relevant details. But controlled access is not the same as no record. The Council of Europe Convention's emphasis on transparency, oversight, accountability and responsibility is a useful reminder that the boundary should be designed rather than assumed. An organisation can preserve an accountable route while limiting access to the detail that a particular reviewer genuinely needs.

What a delegation contract should make visible

A delegation contract can be a data structure, a workflow schema, a signed approval packet or a combination of these. Its form matters less than its content. It should tell the receiving actor what it is allowed to do, what it is not allowed to do and how the work will be judged. When these constraints are absent, agents tend to compensate with increasingly elaborate instructions. That may improve a particular run. It does not create an organisational boundary that a tool, reviewer or auditor can enforce.

Begin with the intended purpose. A purpose should be concrete enough to exclude nearby tasks. Compare the terms in the supplied proposals is different from find the best supplier. Summarise the received documents is different from establish the missing facts. Draft a reply for review is different from communicate a decision. The contrast can sound fussy until an agent uses a broad instruction to take a reasonable but unauthorised next step. Then it is the difference between useful initiative and an unbounded mandate.

Nurodykite leidžiamų ir draudžiamų veiksmų klases. Agentui gali būti leista skaityti bylą, išgauti įvardytus laukus, palyginti su politika ir parengti projektą. Jam gali būti draudžiama keisti pirminį įrašą, susisiekti su išorine šalimi, pasirinkti naują šaltinį arba atlikti operaciją. Tai ne vien instrukcijos pokalbio lange. Įrankių ir darbo eigos sluoksnis turėtų jas įgyvendinti ten, kur tai praktiška. Politika, kurios negalima patikrinti veiksmo momentu, vis tiek naudinga kaip gairės, tačiau kaip kontrolės priemonė ji silpnesnė.

Įvardykite savininką ir eskalavimo kelią. Savininkas nebūtinai yra asmuo, kuris spustelės „patvirtinti“ prie kiekvieno veiksmo. Tai vaidmuo, atsakingas už rezultatą ir už sprendimą, kas atsitinka, kai kelias pasiekia neišspręstą klausimą. Eskalavimo kelias nurodo kitą instanciją, kai agentas aptinka ribų pažeidimą, nepakankamų įrodymų, šaltinių konfliktą, politikos neatitikimą arba sąlygą, kurios sistema neturi teisės išspręsti. Eilė be įvardyto sprendimų savininko yra tik delsimas su optimistiška etikete.

Pridėkite įrodymų taisyklę. Taisyklė gali nurodyti, kurie šaltiniai yra autoritetingi, ar agentas gali ieškoti už jų ribų, kaip pateikiamas neapibrėžtumas, kas turi būti cituojama pasiūlyme ir kada prieštaringas šaltinis reikalauja peržiūros. Tai ypač svarbu sistemoms, kurios kuria sklandų tekstą. Sklandumas gali priversti ribų pažeidimą atrodyti kaip naudingas užbaigimas. Įrodymų taisyklė pateikia teisingą klausimą: ar darbo eiga liko medžiagoje, kurią jai buvo leista naudoti?

Nustatykite laiko, išteklių ir delegavimo apribojimus ten, kur jie svarbūs. Užduotis, kuri gali tęstis neribotą laiką, gali sukelti išlaidų, veiklos spūstis arba spaudimą įvykdyti pasenusį rezultatą. Užduotis, kuri gali pakartotinai deleguoti, gali sukurti grandinę, kurios joks savininkas negali lengvai patikrinti. Apribota konstrukcija nurodo, kiek laiko užduotis lieka galiojanti, kiek išteklių ji gali sunaudoti, ar jai leidžiama kurti antrinę užduotį, koks didžiausias gylis leidžiamas ir kas atsitinka, kai pasiekiama riba. Atsakymas gali būti automatinis pristabdymas, eskalavimas arba kontroliuojamas gedimas. Svarbiausia, kad tai būtų nuspręsta prieš peržengiant ribą.

Galiausiai apibrėžkite užbaigimo sąlygą. „Užbaigta“ ne visada reiškia, kad agentas sukūrė tekstą. Tai gali reikšti, kad recenzentas gavo išsamų paketą, politikos vartai priėmė konkretų veiksmą, vėlesnė sistema patvirtino grįžtamąjį atnaujinimą arba atsakingas savininkas nusprendė netęsti. Užbaigimo sąlygos užtikrina darbo eigos sąžiningumą. Jos neleidžia agentui traktuoti sprendimo pasiūlymo taip, tarsi organizacija jį jau būtų priėmusi.

Šie modeliai naudingi tiek tada, kai darbo eigoje yra vienas modeliu pagrįstas agentas, tiek tada, kai yra didesnė specializuotų komponentų komanda. Daugiau agentų automatiškai nereiškia daugiau procesų. Tačiau jie reikalauja, kad ribos tarp vaidmenų būtų išreikštos, o ne numanomos. Tokio išreiškimo kaina paprastai yra daug mažesnė nei bandymo atkurti autoritetą po to, kai kelios sistemos apsikeitė dalinėmis instrukcijomis ir viena iš jų palietė išorinį pasaulį.

Delegavimas turėtų padaryti organizaciją pajėgesnę, o ne mažiau atskaitingą

Agentų sistemos dažnai apibūdinamos taip, tarsi jų vertė būtų pašalinti organizuotumą iš darbo. Įdomesnė perspektyva yra priešinga. Kruopščiai sukurta sistema gali padaryti organizacinius įsipareigojimus aiškesnius: užduotis turi savininką, delegavimas turi ribą, reikšmingas veiksmas turi autoritetą, peržiūra turi įrodymų, sustojimas turi saugią būseną, o įrašą galima atkurti. Tai nėra kliūtis naudingai automatizacijai. Tai yra tai, kas leidžia automatizacijai imtis prasmingo darbo nereikalaujant, kad žmonės pasitikėtų nematoma grandine.

„Dweve Nexus“ sukūrėme turėdami omenyje būtent šį skirtumą. Jo vietinėje produkto dokumentacijoje aprašomos ilgalaikės užduotys, įgaliojimai, vertinami pagal vykdymo kontekstą prieš veiksmą, aiškios bendradarbiavimo struktūros, įskaitant delegavimą, ir įrašas, kuriamas darbui vykstant. Atitinkamas teiginys sąmoningai kuklus. Tai dizaino savybės, skirtos deleguotam keliui padaryti patikrinamam. Jos nėra įrodymas, kad konkretus diegimas yra teisėtas, saugus ar tinkamas, ir jos nepanaikina organizacijos pareigos pačiai nuspręsti dėl savo tikslo, įgaliojimų ir žmogiškosios priežiūros.

Platesnė pamoka nepriklauso nuo vieno produkto. Modelis gali nuspręsti, kaip padalyti užduotį. Agentas gali paprašyti kito agento darbo. Įrankis gali atlikti veiksmą. Organizacija vis tiek turi nuspręsti, kur glūdi įgaliojimai. Ji turi tai padaryti prieš prasidedant delegavimui, o ne po to, kai galutinis rezultatas buvo nušlifuotas taip, kad jį būtų sunku kvestionuoti.

Tai ir yra atsakymas į pavadinimo klausimą. Sprendimo savininkas nėra agentas, kuriam atsitiktinai teko paskutinis žodis. Tai asmuo arba vaidmuo, kuriam organizacija suteikė įgaliojimus priimti sprendimo pasekmes, turintis pakankamai informacijos ir galios jų atsisakyti. Delegavimas yra naudingas, kai jis padaro tą asmenį pajėgesnį. Jis tampa pavojingas, kai dėl jo tą asmenį tampa neįmanoma rasti.

Kas sprendžia, kai agentas perduoda užduotį?