Kallis tuotantotekoälyn virhe voi näyttää tältä: asiakaspalveluagentti kutsuu samaa työkalua, saa saman virheen, muuttaa merkityksetöntä parametria ja yrittää uudelleen. Ajo jatkuu, kunnes alustan raja, operaattori tai budjetti pysäyttää sen. Kustannus riippuu mallin hinnasta, tokenmäärästä, työkalumaksuista ja kutsutiheydestä. Laske se jäljityksestä äläkä oleta dramaattista laskua.
Virhe voi näyttää työltä, koska agentti jatkaa toimintojen tekemistä. Jäljitys tuo toistuvan tilan ja samat työkalutulokset näkyviin. Käsittele silmukkaa tunnettuna virhetilana, mutta mittaa sen yleisyys omassa järjestelmässäsi äläkä väitä yleispätevää esiintyvyyttä.
Ikuiset silmukat estävien agenttien rakentaminen vaatii tietoisia arkkitehtuurivalintoja. Useimmat agenttivirheet ovat ennakoitavia, ja niiden torjuntamallit tunnetaan. Anthropicin opas tehokkaiden agenttien rakentamiseen suosittelee samasta syystä lopetusehtoja, kuten iteraatioiden enimmäismäärää ja ihmisen tarkistuspisteitä. Luotettavia agentteja julkaisevat tiimit toteuttavat nämä mallit kurinalaisesti.
Tässä artikkelissa käsitellään silmukoiden syyt, ne estävät arkkitehtuurimallit sekä silmukan läpi päästessä sen havaitsevat operatiiviset suojamekanismit.
Miksi agentit jäävät silmukkaan
Silmukoiden taustalla on useita mekanismeja:
1. Epäselvyys edistymisestä
Agentilla ei ole selvää käsitystä siitä, onko se edistynyt. Se kokeilee jotain, tarkastelee tulosta ja päättää kokeilla muuta. Ilman eksplisiittistä seurantaa ”kokeile muuta” voi tarkoittaa samaa asiaa hieman eri tavalla.
2. Lopetusehtojen puute
Agentin kehote käskee auttamaan käyttäjää mutta ei lopettamaan, kun X toteutuu. Ilman selvää lopetusta agentti jatkaa auttamista: etsii vielä yhden tiedon, kokeilee vielä yhtä työkalua ja tarkentaa lisää.
3. Uudelleenyritysten häiriö
Virheen jälkeen agentti yrittää luontevasti uudelleen. Ilman uudelleenyritysbudjettia samaa virhettä voidaan yrittää loputtomasti. Agentti tulkitsee tilanteen muodossa ”en ole vielä onnistunut”, ei ”olen jo kokeillut tätä 10 kertaa”.
4. Tilan unohtaminen
Agentin työmuisti sisältää vain viimeisimmät vuorot. Jos silmukassa on ollut 20 yritystä, agentti voi nähdä kontekstissa vain viimeiset 5 eikä ulkopuoliselle jo selvää mallia.
5. Työkalun epäjohdonmukaisuus
Työkalu palauttaa epäselviä tai ristiriitaisia tuloksia. Agentti yrittää uudelleen, saa edelleen epäselvän tuloksen, epäilee aiempaa tulkintaansa ja kokeilee toisin. Tulos pysyy epäselvänä. Silmukka jatkuu.
6. Liiallinen optimismi
Agentin koulutus tekee siitä sinnikkään. Se jatkaa yrittämistä tilanteessa, jossa pitäisi pysähtyä ja pyytää apua. Ongelma korostuu pitkissä tehtävissä, joissa pienet epäselvyydet kertautuvat.
7. Tavoitteen ajautuminen
Agentti kadottaa vähitellen alkuperäisen tavoitteensa. Se haarautuu alitehtäviin ja niiden alitehtäviin sekä tutkii sivuavia aiheita palaamatta päätavoitteeseen.
Eri agentit epäonnistuvat eri tavoin. Puolustuskeinot ovat osittain samoja.
Malli 1: tiukat vaihebudjetit
Yksinkertaisin ja tärkein suoja on vaiheiden enimmäismäärä. Agentilla on esimerkiksi 20 työkalukutsua. Vaiheita on 20, ja sen jälkeen agentin on tuotettava lopullinen vastaus tai eskaloitava. Kypsissä kehyksissä tämä on ensisijainen hallintakeino: esimerkiksi OpenAI Agents SDK toteuttaa max_turns-rajan ja nostaa oman poikkeuksen, kun ajo ylittää sen.
Toteutus:
def agent_loop(query, max_steps=20):
messages = [{"role": "user", "content": query}]
for step in range(max_steps):
response = call_llm(messages, tools=available_tools)
if response.is_final_answer:
return response.content
result = execute_tool(response.tool_call)
messages.append(response)
messages.append({"role": "tool", "content": result})
# Hit budget — force final answer
return force_final_answer(messages)
Budjetti on kalibroitava tehtävään. Aloita onnistuneiden ajojen havaitusta jakaumasta, lisää katselmoitu marginaali ja säilytä ehdoton yläraja. Viisivaiheisen poiminnan ja tutkimustyönkulun ei pidä periä samaa rajaa.
Budjetin täyttyessä agentti tuottaa parhaan mahdollisen vastauksen nykyisillä tiedoilla tai eskaloi ihmiselle.
Tämä malli rajaa silmukan iteraatioiden enimmäismäärän. Se ei estä toistuvia sivuvaikutuksia, joten yhdistä siihen idempotenssi, valtuutus ja työkalukohtaiset rajat.
Muunnelmat
Tokenbudjetti. Rajoita vaiheiden lisäksi tai sijasta tokenien kokonaismäärää. Tämä estää agenttia käyttämästä harvoja mutta 50K tokenin päättelyvaiheita.
Kustannusbudjetti. Muunna vaihe- tai tokenbudjetti euroiksi. Näin budjetin ylitys ei jää abstraktiksi.
Aikabudjetti. Seinäaikaraja sopii käyttäjäpolkuihin, kuten ”vastaa 30 sekunnissa”.
Pakota seurauksellisille agenteille vaihe-, token-, kustannus- ja seinäaikabudjetit mallin ulkopuolella. Minkä tahansa rajan täyttymisen on siirrettävä ajo määriteltyyn lopetus- tai eskalointitilaan.
Malli 2: edistymisen seuranta
Pelkkä budjetti ei kerro agentille, että se on jumissa. Se vain pysäyttää agentin lopulta. Edistymisen seuranta auttaa agenttia tunnistamaan silmukan ja poistumaan siitä.
Yksinkertaisessa toteutuksessa agentti ylläpitää eksplisiittistä edistymislokia. Jokaisessa vaiheessa se kirjaa saamansa uuden tiedon tai tapahtuneen muutoksen.
Vaihe 1: Haettiin asiakasta "Smith". Löytyi 12 osumaa.
Vaihe 2: Rajattiin aktiivisiin tileihin. Jäljellä 4.
Vaihe 3: Tarkistettiin viimeaikainen toiminta. Asiakkaalla 234 oli tuore hinnoittelua koskeva tukipyyntö.
Vaihe 4: Haettiin tukipyynnön tiedot. Valitus koski äskettäistä hinnanmuutosta.
Vaihe 5: Luonnosteltiin vastaus. Valmis lähetettäväksi.
Jokainen vaihe lisää uutta tietoa. Jos agentti tekee vaiheen 6 eikä edistymisloki muutu — sama haku, samat tulokset ja sama johtopäätös — se polkee paikallaan.
Kehotteeseen voidaan lisätä:
Ennen kuin päätät seuraavasta toiminnosta, tiivistä, mitä olet oppinut viime vaiheissa. Jos et ole saanut uutta tietoa viimeisen 3 vaiheen aikana, pysähdy ja tee jompikumpi:
- Tuota paras mahdollinen vastaus nykyisillä tiedoilla.
- Eskaloi asia: kerro, mitä olet kokeillut ja mitä puuttuu.
Näin edistymisen puute tulee agentille näkyväksi, jotta se voi reagoida.
Malli 3: toiston tunnistus
Joskus agentti toistaa täsmälleen saman työkalukutsun. Tämä on helppo havaita ohjelmallisesti.
def detect_repeat(history):
recent_calls = [c for c in history[-5:] if c.is_tool_call]
if len(recent_calls) < 3:
return False
call_signatures = [(c.tool, json.dumps(c.args, sort_keys=True)) for c in recent_calls]
return len(set(call_signatures)) < len(call_signatures) / 2
Kun toisto havaitaan, puutu siihen:
- Lisää viesti: ”Olet kutsunut tätä työkalua näillä parametreilla äskettäin. Tulokset eivät ole muuttuneet. Kokeile toista lähestymistapaa tai lopeta.”
- Tai pakota lopetus.
Tämä tunnistaa ilmeisimmät silmukat automaattisesti.
Malli 4: jumittumisen tunnistus
Täsmällisen toiston lisäksi voit tunnistaa hienovaraisempia jumitiloja:
Mallintunnistus. Arvioi erillisellä LLM-kutsulla: ”Edistyykö tämä agentti viimeisten 5 vaiheen perusteella?” Jos ei, katkaise ajo.
def is_stuck(history):
recent = format_history(history[-5:])
response = call_llm(
system="You are evaluating whether an agent is making progress.",
user=f"Recent agent steps:\n{recent}\n\nIs the agent making meaningful progress or stuck in a loop? Answer: progressing | stuck."
)
return response.content.strip() == "stuck"
Aja tarkistus muutaman vaiheen välein. Jos tulos on ”stuck”, puutu ajoon.
Työkalujen monipuolisuus. Jos agentti on kutsunut vain 1 työkalua 5+ vaiheessa, tilanne on epäilyttävä. Pakota se kokeilemaan muuta tai lopettamaan.
Virhemallit. Jos sama työkalu on palauttanut saman virheen 3+ kertaa, lopeta sen käyttö. Uudet yritykset eivät auta agenttia selvittämään puuttuvaa syötettä.
Malli 5: reflektointipisteet
Pakota agentti reflektoimaan eksplisiittisesti tietyissä ajon kohdissa.
Agentin on tuotettava reflektio joka 5. vaiheen jälkeen:
1. Mikä oli alkuperäinen tavoitteeni?
2. Mitä olen oppinut tähän mennessä?
3. Mitä minun pitää vielä tietää?
4. Edistynkö vai toistanko itseäni?
5. Pitäisikö minun jatkaa vai lopettaa?
Reflektointi pakottaa agentin irtautumaan seuraavan välittömän toiminnon pohdinnasta ja arvioimaan kokonaisuutta.
Tämä on erityisen tehokasta pitkissä tehtävissä. Ilman pakotettua reflektointia agentit ajautuvat sivuun, mutta sen avulla ne tunnistavat ajautumisensa.
Malli 6: tavoitteen ankkurointi
Pitkissä agenttiajoissa alkuperäinen tavoite katoaa. Agentin konteksti-ikkuna täyttyy välivaiheista, ja alkuperäinen kysymys jää pieneksi osaksi suurta kontekstia.
Torju tätä ankkuroimalla tavoite toistuvasti:
- Lisää alkuperäinen tavoite jokaisen järjestelmäviestin alkuun.
- Pyydä agenttia toistamaan tavoite N vaiheen välein.
- Käytä erillistä tavoiteseurantaa, joka vahvistaa jokaisen vaiheen vastaavan tavoitetta.
Esimerkki kehotteen lisäyksestä:
Alkuperäinen tavoite: [käyttäjän pyyntö sanatarkasti]
Vahvista ennen jokaista toimintoa:
- Vieekö tämä toiminto minua kohti alkuperäistä tavoitetta?
- Jos vie, jatka.
- Jos ei, palaa suoraan tavoitteeseen.
Malli 7: alitehtävien rajaaminen
Pitkät agenttiajot jakautuvat luontevasti alitehtäviin. Ilman rakennetta alitehtävät voivat synnyttää omia alitehtäviään rekursiivisesti, kunnes agentti eksyy.
Määritä rakenne:
- Agentti tunnistaa alitehtävät eksplisiittisesti.
- Jokaisella alitehtävällä on oma budjetti.
- Alitehtävän valmistuttua tai epäonnistuttua agentti palaa päätehtävään.
- Alitehtävät eivät saa synnyttää rajattomasti uusia alitehtäviä.
LangGraphin kaltaiset kehykset pyrkivät formalisoimaan tämän tilakoneeksi, jossa jokainen solmu on selvä vaihe ja siirtymät ovat eksplisiittisiä.
Monimutkaisille agenteille rakenne on välttämätön. Yksinkertaisille se on ylimitoitettu.
Malli 8: poistumistiet
Jumittunut agentti tarvitsee eksplisiittisiä tapoja lopettaa:
Eskalointi. ”En pysty suorittamaan tehtävää. Tässä ovat kokeilemani asiat ja puuttuvat tiedot.” Agentti lopettaa ja tuo ongelman näkyviin.
Osittainen valmistuminen. ”Olen tehnyt osat A ja B. X estää osan C.” Agentin ei tarvitse onnistua kokonaan, vaan se voi tuottaa hyödyllisen osatuloksen.
Tarkennus. ”Tarvitsen käyttäjältä lisätietoa: …” Agentti pysähtyy ja kysyy.
Näiden pitää olla agentin ensisijaisia vaihtoehtoja, ei viimeisiä keinoja. Kehotteen pitää mainita ne ja kannustaa käyttämään niitä jumitilanteessa.
Hyödyllinen lisäys kehotteeseen:
Jos kohtaat jonkin näistä tilanteista, lopeta yrittäminen ja vastaa tilanteen mukaisesti:
- Työkalu palauttaa toistuvasti saman virheen.
- Olet kokeillut 3 eri lähestymistapaa ilman edistystä.
- Tarvitset tietoa, jonka vain käyttäjä voi antaa.
- Tehtävä on monimutkaisempi kuin mitä työkalusi tukevat.
Näissä tapauksissa:
- Työkaluvirheissä: selitä ongelma ja ehdota, että käyttäjä ottaa yhteyttä tukeen.
- Edistyksen puuttuessa: kerro, mitä olet kokeillut, ja pyydä ohjeita.
- Tiedon puuttuessa: esitä käyttäjälle täsmällinen kysymys.
- Monimutkaisuudessa: eskaloi ihmisen hoidettavaksi ja liitä mukaan tiivistelmä.
Malli 9: luottamuksen huomioivat toiminnot
Agentin pitäisi tunnistaa, milloin se on varma ja milloin ei. Toimiminen pienellä luottamuksella käynnistää silmukoita.
Yksi malli vaatii eksplisiittisen luottamusarvion ennen jokaista seurauksellista toimintoa.
Ennen kuin kutsut delete_record-työkalua, ilmoita asteikolla 1-5, kuinka varma olet siitä, että tämä on oikea toiminto. Jos arvio on <4, älä kutsu sitä. Pyydä sen sijaan ihmiseltä vahvistus.
Tämä toimii erityisen hyvin tuhoisissa tai kalliissa toiminnoissa. Agentin on sitouduttava suureen luottamukseen ennen niiden tekemistä.
Reflektointiin yhdistettynä malli tunnistaa tilanteet, joissa agentti vain kokeilee asioita suunnitelman toteuttamisen sijasta.
Malli 10: työkalutason suojaukset
Agenttitason mallien lisäksi itse työkaluissa voi olla suojauksia:
Istuntokohtainen nopeusrajoitus. Työkalua voi kutsua istunnossa vain N kertaa. Sen jälkeen se palauttaa nopeusrajoituksen ja pakottaa agentin toimimaan toisin.
Idempotenssi. Toistuvat identtiset kutsut palauttavat välimuistituloksen suorittamatta toimintoa uudelleen. Tämä estää työkalua kuormittavat silmukat.
Kustannusrajat. Kalliilla työkaluilla, kuten raskailla tietokantakyselyillä ja maksullisilla kolmannen osapuolen API:illa, on istuntokohtaiset rajat.
Virheiden katkaisijat. Istunnossa 3 kertaa epäonnistunut työkalu poistetaan käytöstä. Agentti ei voi enää kutsua sitä.
Nämä täydentävät agenttitason malleja. Agentti voi yrittää jäädä silmukkaan, mutta työkalu estää sen.
Malli 11: ulkoinen seuranta
Agentin sisäisten mallien lisäksi ulkoinen valvonta tunnistaa läpi pääsevät ongelmat.
Valvontaprosessi seuraa kaikkia käynnissä olevia agentteja. Se tarkistaa:
- Agenttikohtaisen vaihemäärän.
- Agenttikohtaisen tokenien käytön.
- Agenttikohtaisen kustannuksen.
- Agenttikohtaisen keston.
- Työkalukutsujen mallit.
Kun agentti ylittää jonkin rajan, lopeta se ja lähetä hälytys.
Toteutuksessa:
- Aikasarjatietokanta seuraa agenttimittareita.
- Säännöt käynnistävät lopetuskäskyjä, kuten ”jos agentti on ollut käynnissä > 5 minuuttia, lopeta”.
- Pieni palvelu valvoo ja pakottaa säännöt.
Tämä on välttämätöntä järjestelmissä, joissa ajetaan samanaikaisesti paljon agentteja.
Malli 12: ihminen osana valvontaa
Lisää suuren riskin agenteille ihmisen tarkistuspisteitä. Agentti etenee tarkistuspisteeseen ja odottaa ihmisen hyväksyntää.
Tyypillisiä tarkistuspisteitä:
- Ennen tuhoisia toimintoja.
- Päätöksen jälkeen, jos sitä ei voi perua.
- Pitkän tehtävän tärkeissä virstanpylväissä.
- Luottamuksen heiketessä.
Kyse ei ole epäluottamuksesta vaan virheiden havaitsemisesta silloin, kun niiden korjaaminen on edullista.
Käytännöllisessä työnkulussa agentti tekee valmistelun itsenäisesti, esittää yhteenvedon ja ehdotetut toimet, ihminen hyväksyy ja agentti suorittaa. Ihminen osallistuu päätöksiin, ei jokaiseen vaiheeseen.
Kalibrointiesimerkki: pitkään toimiva tutkimusagentti
Tämä on suunnitteluesimerkki, ei mitattu käyttöönottotulos. Korvaa jokainen luku omista varjoajoistasi johdetulla rajalla:
Tehtävä: tutki kilpailijaa ja laadi muistio.
Arvioitu työ: 10-30 verkkohakua, 20-50 sivun lukeminen ja synteesi 1000 sanan muistioksi.
Käytetyt mallit:
-
Vaihebudjetti: yhteensä 60 vaihetta.
-
Tokenbudjetti: 300K tokenia kontekstiin ja toimintoihin. Jos raja ylittyy, tiivistä nykyiset löydökset ja jatka.
-
Kustannusbudjetti: €2 ajoa kohti. Jos raja ylittyy, lopeta ja palauta osittainen muistio.
-
Aikabudjetti: 5 minuuttia seinäaikaa.
-
Edistymisen seuranta: agentti päivittää jokaisessa vaiheessa löydöslokia uudella tiedolla. Jos 3 vaihetta kuluu ilman uusia löydöksiä, poistu.
-
Toiston tunnistus: jos sama hakukysely ajetaan kahdesti samankaltaisin tuloksin, pakota toinen lähestymistapa.
-
Reflektointipisteet: agentti arvioi edistymistä ja jäljellä olevaa työtä 10 vaiheen välein.
-
Tavoitteen ankkurointi: alkuperäinen muistion tavoite jokaisen järjestelmäviestin alussa.
-
Poistumistiet: sekä ”minulla on tarpeeksi tietoa” että ”en löydä riittävästi tietoa” lopettavat agentin hallitusti.
-
Ulkoinen valvonta: riippumaton valvoja lopettaa budjetit ylittävät agentit.
Kerättävä hyväksymisnäyttö: valmistumis- ja eskalointiosuudet, keston mediaani ja jakauman häntä, valmiin muistion kustannus, toistuvien kutsujen osuus, viittausten oikeellisuus ja katselmoijien hyväksyntä. Vertaa rajattua suunnitelmaa nykyiseen perustasoon samalla tehtäväjoukolla. Älä julkaise säästö- tai luotettavuusväitteitä ennen tulosten saamista.
Tunnistus tuotannossa
Malleista huolimatta ongelmia pääsee joskus läpi. Tunnista ne:
Hälytykset pitkistä agenttiajoista. Hälytä kaikista agenteista, joiden kesto on > 2x mediaani.
Hälytykset kustannuspiikeistä. Agenttikohtainen tai yhteenlaskettu kustannus ylittää rajan.
Hälytykset toistomalleista. Työkalukutsujen mallit viittaavat silmukkaan.
Pitkien jälkien päivittäinen tarkastus. Ihminen vilkaisee päivän 10 pisintä jälkeä. Näin löytyvät arvioinneilta huomaamatta jäävät ongelmat.
Koostemittarit: silmukoiden osuus ajan mittaan. Tämä paljastaa mallipäivityksen tai kehotemuutoksen kaltaisen muutoksen, joka lisää silmukoita.
Hyödyllinen hallintapaneeli näyttää agenttiajojen pituusjakauman. Jakauman häntä kertoo silmukoiden yleisyydestä.
Yleiset virheet
Muutamia toistuvasti havaitsemiamme malleja:
Virhe 1: ei vaihebudjettia. ”Lisäämme sen tarvittaessa.” Sitten agentti jää silmukkaan kello 3 AM, ja toivot lisänneesi sen. Lisää se aina ensimmäisestä päivästä lähtien.
Virhe 2: liian suuret budjetit. ”100 vaihetta varmasti riittää”, mutta silmukka täyttää ne. Aseta budjetti arvoon 2-3x mediaani, älä pahimman tapauksen mukaan.
Virhe 3: ei ulkoista valvontaa. Agentin luotetaan lopettavan itse. Joskus se ei lopeta. Ulkoinen valvonta on tuotannossa välttämätön.
Virhe 4: silmukat tunnistetaan mutta niitä ei analysoida. Valvonta lopettaa silmukan ja tiimi jatkaa eteenpäin. Sama silmukka toistuu seuraavalla viikolla. Tee aina jälkianalyysi: mikä käynnisti silmukan, mikä muuttui ja voidaanko koko virheluokka estää?
Virhe 5: liiallinen reflektointi yksinkertaisissa tehtävissä. Reflektointi 5 vaiheen välein 5-vaiheisessa tehtävässä lisää työtä ilman hyötyä. Sovita se tehtävän monimutkaisuuteen.
Virhe 6: tavoite katoaa pitkässä kontekstissa. Vaiheessa 1 kerran mainittu tavoite ei säily vaiheeseen 50. Ankkuroi se säännöllisesti uudelleen.
Virhe 7: agentin omiin edistymisraportteihin luotetaan. Agentit ilmoittavat edistyvänsä silloinkin, kun eivät edisty. Varmenna ulkoisesti mahdollisuuksien mukaan.
Virhe 8: agenttien sallitaan kutsua itseään rekursiivisesti. ”Jaa tehtävä aliagenteille” voi synnyttää eksponentiaalisesti agentteja. Jos sallit tämän, budjetoi se tiukasti.
Milloin silmukat ovat hyväksyttäviä
Kaikki silmukat eivät ole huonoja. Jotkin tehtävät vaativat perustellusti useita iteraatioita:
- Koodin iteratiivinen kehitys: kirjoita, testaa, korjaa ja toista.
- Haarautuva monivaiheinen tutkimus.
- Optimointitehtävät: kokeile muunnelmia, arvioi ja paranna.
Näissä silmukka on työtä eikä virhe. Mallit muuttuvat:
- Väljät vaihebudjetit (50-200 vaihetta).
- Eksplisiittinen kehystys iteraatioksi, ei silmukaksi.
- Laadun parantumisen seuranta: jokaisen iteraation pitäisi parantaa mittaria.
- Tiukka lopetus parannuksen tasaantuessa.
Periaate on erottaa tarkoituksellinen iteratiivinen työ tahattomista silmukoista ja soveltaa malleja tilanteen mukaan.
Tuotannon tarkistuslista
Ikuiseen silmukkaan jäävät agentit ovat ennakoitavia, yleisiä ja estettävissä. Mallit tunnetaan: vaihebudjetit, edistymisen seuranta, toiston tunnistus, reflektointi, tavoitteen ankkurointi, poistumistiet, työkalujen suojaukset ja ulkoinen valvonta.
Nämä hallintakeinot kuuluvat valvomattoman suorituksen turvallisuusrajaan. Ne rajaavat virhettä, mutta eivät todista agenttia muuten oikeaksi tai turvalliseksi.
Jokaisen tuotantoagentin tarkistuslista:
- Vaiheiden enimmäisbudjetti.
- Tokenien enimmäisbudjetti.
- Kustannusten enimmäisbudjetti.
- Ajan enimmäisbudjetti.
- Toistuvien kutsujen tunnistus.
- Edistymisen seuranta.
- Säännöllinen reflektointi.
- Tavoitteen ankkurointi.
- Useita poistumisteitä.
- Lopetuskykyinen ulkoinen valvonta.
Jokainen niistä vaatii työkuormakohtaisen toteutuksen ja testauksen. Yhdessä ne pienentävät jumittuneen ajon vaikutusaluetta, kun taas valtuutus, validointi, idempotenssi ja ihmisen hyväksyntä hallitsevat muita virheluokkia.
Rakenna mallit sisään ja testaa ne. Kalliin jakauman hännän leikkaaminen on työn arvoista.
