Tapaus taikaorkestrointia vastaan
Kaavio, joka näytti älykkäältä
Orkestrointikaavio oli kaunis sillä tavalla kuin vaaralliset kaaviot usein ovat. Pyöristetyt laatikot, sulavat nuolet, suunnittelija, tutkija, varmistaja, työkalun suorittaja, muistikerros, ihmisen hyväksyntäsolmu ja lopullinen vastaus. Demo eteni teatraalisella varmuudella. Käyttäjä pyysi analyysiä, suunnittelija jakoi tehtävän osiin, työkaluja kutsuttiin, välivaiheen muistiinpanot ilmestyivät, ja lopullinen vastaus saapui sellaisen järjestelmän tyyneydellä, joka ei ollut koskaan kohdannut tuotantoliikennettä.
Sitten ensimmäiset oikeat poikkeukset saapuivat. Työkalu palautti osittaisen tuloksen. Suunnittelija yritti uudelleen eri kyselyllä ja menetti aiemman syyn. Varmistaja tarkisti tyylin mutta ei lähdekonfliktia. Muisti toi takaisin vanhan oletuksen, koska se näytti osuvalta. Ihmisen hyväksyntävaihe hyväksyi lopullisen tekstin näkemättä epäonnistunutta haaraa. Jälki oli olemassa, mutta sen lukeminen tuntui siltä kuin tutkisi komitean paloharjoituksen aikana pakkaamaa matkalaukkua. Kaavio ei ollut epäonnistunut dramaattisesti. Se oli piilottanut vastuun muodon.
Tämä on argumentti maagista orkestrointia vastaan. Ei orkestrointia itseään vastaan. Monimutkaiset tekoälyjärjestelmät tarvitsevat koordinointia. Niiden on kutsuttava työkaluja, reititettävä tehtäviä, hallittava kontekstia, kysyttävä ihmisiltä, toivuttava virheistä, jaettava työtä ja yhdistettävä todisteita. Argumentti kohdistuu sellaiseen orkestrointityyliin, joka kohtelee näppärää kaaviota tai agenttisilmukkaa korvikkeena eksplisiittiselle tilalle, sopimuksille, omistajuudelle, rajoille ja tallenteille. Taika on vaikuttavaa demossa, koska se piilottaa mekanismin. Suunnittelu on hyödyllistä tuotannossa, koska se paljastaa mekanismin riittävästi korjaamista varten.
Tekoälyn orkestrointi on paikka, jossa todennäköisyys kohtaa työnkulun. Tämä risteys ei anna armoa. Malli voi valita suunnitelman. Työkalu voi palauttaa tuloksen. Käytäntö voi sallia toiminnon. Uudelleenyritys voi muuttaa kontekstia. Ihminen voi hyväksyä. Alavirran järjestelmä voi toimia. Jos näitä siirtymiä ei nimetä, rajata ja tallenneta, organisaatio saa älykkään näköisen järjestelmän, jonka käyttäytymistä on vaikea toistaa ja vielä vaikeampi hallita. Se ei ole autonominen. Se on vain välttelevä paremmalla brändäyksellä.
Orkestrointi ei ole älykkyyden taikapölyä
Sana orkestrointi voi saada tavallisen suunnittelun kuulostamaan vastikään lumotulta. Sekvenssistä tulee ketju. Ehdosta tulee reititin. Funktiokutsusta tulee työkalu. While-silmukasta tulee agentti. Jonosta tulee muisti, jos valaistus on oikea. Osa tästä sanastosta on hyödyllistä, koska tekoälyjärjestelmät tuovat mukanaan uusia koordinointiongelmia. Osa on paketointia. Paketointi ei ole pahasta. Siitä tulee kallista, kun tiimit unohtavat, mitä laatikon sisällä on.
Pohjimmiltaan orkestrointi on tilan, päätösten, resurssien ja siirtymien hallintaa. Mikä on tehtävä. Mikä on nykyinen tila. Mitkä syötteet ovat sallittuja. Mitä työkalua saa kutsua. Mikä tulostemuoto on odotettu. Mitä tapahtuu virheen sattuessa. Mitkä uudelleenyritykset ovat sallittuja. Mitkä toimet vaativat hyväksynnän. Mitä todisteita on säilytettävä. Mikä vaihe voidaan toistaa. Mikä vaihe on peruuttamaton. Nämä kysymykset olivat olemassa ennen generatiivista tekoälyä. Mallit tekevät niistä tärkeämpiä, eivät vanhentuneita.
Maaginen orkestrointi välttelee näitä kysymyksiä antamalla mallin tai kehyksen päätellä liikaa ajonaikaisesti. Suunnittelija päättää hajottelusta. Malli valitsee työkalut. Työkalun tulos muuttuu kontekstiksi. Seuraava vaihe tulkitsee sen. Muisti lisää historiaa. Varmistaja nyökkää. Lopullinen vastaus ilmestyy. Tämä voi toimia vähäriskisissä tutkivissa tehtävissä. Se on hauras, kun työnkulku koskettaa tietueita, rahaa, turvallisuutta, vaatimustenmukaisuutta, asiakassitoumuksia, infrastruktuuria tai muita järjestelmiä, jotka eivät arvosta improvisaatioteatteria.
Kurinalainen orkestrointisuunnittelu ei poista joustavuutta. Se asettaa joustavuuden raiteille. Malli saa ehdottaa suunnitelmaa, mutta suunnittelijan tuloksella on skeema. Järjestelmä saa kutsua työkaluja, mutta työkaluilla on laajuudet ja budjetit. Työnkulku saa yrittää uudelleen, mutta uudelleenyritysten syyt luokitellaan. Muisti saa auttaa, mutta virallinen tila asuu muualla. Ihminen saa hyväksyä, mutta hyväksyntä näkee olennaiset haarat ja todisteet. Joustavuus säilyy. Mysteeri ei pääse ohjaamaan.
Piilotetun tilan ongelma
Yleisin orkestroinnin epäonnistuminen on piilotettu tila. Tila esiintyy kehotteissa, luonnospohjissa, muistivarastoissa, työkalujen tulosteissa, väliviesteissä, mallin yhteenvedoissa, välimuistin tuloksissa, ihmisten kommenteissa ja kehyksen sisäisissä osissa. Jokainen kerros sisältää osatotuuden. Mikään niistä ei ole pysyvä tietue. Kun jotain menee pieleen, tiimi kysyy, mitä järjestelmä uskoi vaiheessa seitsemän. Vastaus on kollaasi.
Piilotettu tila tekee virheenjäljityksestä kurjaa. Malli valitsi eri työkalun, koska aiempi yhteenveto käytti vahvempaa verbiä. Uudelleenyritys jätti rajoitteen pois. Aiemman tehtävän muistikohta vaikutti suunnitelmaan. Työkalun tulos katkaistiin. Varmistaja näki lopullisen vastauksen mutta ei hylättyä haaraa. Järjestelmä käyttäytyi uskottavasti, ja uskottava käytös on ärsyttävin tutkittava, koska se ei suostu näyttämään rikkinäiseltä ennen kuin tiedät puuttuvan tosiasian.
Pysyvän tehtävän tilan tulisi olla eksplisiittinen. Sen tulisi sisältää tehtävän tarkoitus, sallittu laajuus, lähdejoukko, suunnitelman versio, työkalujen kutsut, työkalujen tulosteet, uudelleenyritysten syyt, ihmisten päätökset, käytäntötarkistukset, kustannukset, aikakatkaisut ja sovelletut toimet. Kaikki vähäriskiset vuorovaikutukset eivät tarvitse raskasta lokikirjaa, mutta mikä tahansa orkestrointi, joka voi vaikuttaa oikeaan työhön, tarvitsee tilamallin transkriptin lisäksi. Transkripti on hyödyllinen kertomus. Se ei ole käyttöjärjestelmä.
Eksplisiittinen tila parantaa myös tuotesuunnittelua. Käyttäjät näkevät, suunnitteleeko järjestelmä, odottaako se työkalua, onko se käytännön estämä, pyytääkö se tarkistusta, yrittääkö se uudelleen ohimenevän virheen jälkeen vai onko se valmis soveltamaan muutoksia. Operaattorit voivat keskeyttää tai jatkaa. Kehittäjät voivat testata siirtymiä. Auditoijat voivat toistaa. Järjestelmästä tulee vähemmän maaginen ja hyödyllisempi, mikä on vaihtokauppa, jota jotkut demot vastustavat ja jota useimmat operaatiotiimit arvostavat syvästi.
Työkalujen kutsut eivät ole viattomia
Työkalujen käyttö antaa tekoälyjärjestelmille kädet. Se on hyödyllistä ja vaarallista. Kalenterin lukeminen, asiakirjojen hakeminen, tietokannan kysely, sähköpostin lähettäminen, lipun avaaminen, tietueen muuttaminen, koodin käyttöönotto tai rahan siirtäminen eivät ole samanarvoisia toimia. Maaginen orkestroija voi kohdella niitä työkaluina listassa. Vakava järjestelmä kohtelee niitä ominaisuuksina, joilla on laajuudet, sivuvaikutukset, käyttöoikeudet, budjetit ja todistevaatimukset.
Jokainen työkalu kutsu tarvitsee sopimuksen. Syötteet on tyypitettävä ja validoitava. Tulosteet on tarkistettava. Virheet on luokiteltava. Sivuvaikutukset on ilmoitettava. Idempotenssi on ymmärrettävä. Aikakatkaisut on rajattava. Uudelleenyritysten on oltava turvallisia. Käyttöoikeudet on johdettava käyttäjästä, tehtävästä ja käytännöstä, ei mallin innokkuudesta. Järjestelmän tulisi tietää, lukeeko työkalu vain tietoja, kirjoittaako se luonnoksen, muuttaako se tietuetta, ilmoittaako se henkilölle vai käynnistääkö se ulkoisen velvoitteen. Vasara ja pankkisiirto eivät saa tuntua samalta.
Työkalun tuloste on myös käsiteltävä syötteenä. Se voi olla osittainen, vanhentunut, luvaton, epäselvä tai vihamielinen. Hakutulos ei ole todiste, ennen kuin järjestelmä tietää lähteen, tuoreuden ja käyttöoikeuden. Tietokantatuloksesta voi puuttua rivejä käyttöoikeuksien vuoksi. API-virhe voi palauttaa viestin, josta ei saa tulla ohjetta. Työkalu voi epäonnistua kohteliaasti ja silti epäonnistua. Orkestroijan ei pidä syöttää jokaista työkalun vastausta takaisin malliin ikään kuin tekstin palauttaminen olisi sama asia kuin totuuden kertominen.
Sivuvaikutukset ansaitsevat erityistä varovaisuutta. Mallin tuottaman suunnitelman voi heittää pois. Lähetettyä sähköpostia ei voi lähettää takaisin yhtä varmasti. Muutettu tietue voi käynnistää alavirran järjestelmiä. Käyttöönotto voi vaikuttaa käyttäjiin. Hyvitys voi siirtää rahaa. Orkestroinnin tulisi erottaa ehdotus toteutuksesta ja vaatia selkeitä portteja peruuttamattomille tai merkittäville vaiheille. Jos järjestelmä voi tehdä oikeita asioita, se tarvitsee enemmän kuin agenttisilmukan. Se tarvitsee jarrut, avaimet ja jonkun, joka tietää, missä varakappale on.
Uudelleenyritykset ovat käytäntöä valepuvussa
Uudelleenyritykset näyttävät tekniseltä liimalta, kunnes tekoälyorkestroija alkaa tehdä valintoja. Jos työkalu epäonnistuu, yritä uudelleen. Jos mallin tuloste on virheellinen, kysy uudelleen. Jos varmistaja hylkää vastauksen, tarkista. Jos suunnitelma pysähtyy, suunnittele uudelleen. Tämä voi olla järkevää. Se voi myös muuttaa lopputulosta, piilottaa epävarmuuden, kasvattaa kustannuksia tai pyyhkiä pois todisteet siitä, miksi ensimmäinen polku epäonnistui. Uudelleenyritys ei ole pelkkä toinen yritys. Se on päätös siitä, minkälaisen epäonnistumisen järjestelmä saa siloitella.
Uudelleenyrityskäytännön on oltava selkeä. Väliaikaisiin infrastruktuurivirheisiin voi suhtautua eri tavalla kuin käytäntöristiriitoihin. Virheellisen JSONin voi korjata eri tavalla kuin puuttuvan todisteen. Matala luottamus voi käynnistää tarkistuksen toisen otoksen sijaan. Lähderistiriitaa ei pidä ratkaista pyytämällä mallia kuulostamaan päättäväisemmältä. Työkalun aikakatkaisu ei saa olla lupa käyttää heikompaa lähdettä merkitsemättä muutosta. Järjestelmän on tiedettävä, miksi se yrittää uudelleen, mikä säilyy, mikä muuttuu ja milloin lopettaa.
Ilman tätä kuria orkestrointi luo kohteliaita silmukoita. Järjestelmä jatkaa yrittämistä, koska yrittäminen on koodissa halpaa. Se voi polttaa budjettia, täyttää lokit, hämmentää käyttäjiä ja lopulta tuottaa vastauksen, joka näyttää paremmalta lähinnä siksi, että aiemmat epävakauden todisteet on piilotettu. Tuotannossa silmukka, joka piilottaa omat epäonnistuneet yrityksensä, ei ole sinnikkyyttä. Se on muistinmenetys edistymispalkilla.
Uudelleenyrityksistä on tuotettava tietueita. Yritysten määrä, syy, muutetut syötteet, muutettu suunnitelma, säilytetyt todisteet, kustannus, viive ja lopullinen lopputulos. Tämä antaa operaattoreille keinon nähdä, onko työnkulku terve vai vain sinnikäs. Se auttaa myös päättämään, korjataanko syötteen laatua, työkalun luotettavuutta, mallin muotoilua, käytännön selkeyttä vai käyttäjien odotuksia. Uudelleenyritys ilman luokittelua on kohautus suoritettavassa muodossa.
Varmistus ei ole koristeellinen solmu
Monissa orkestrointikaavioissa on varmennin. Hyvä. Sitten varmenninta pyydetään tarkistamaan, onko vastaus uskottava, hyvin muotoiltu tai ohjeiden mukainen. Vähemmän hyvä. Varmennin, joka lukee vain lopullisen vastauksen, voi jättää huomaamatta olennaiset virheet: heikon lähteen, kielletyn syötteen, epäonnistuneen työkalun, käytäntöristiriidan, vaarallisen toiminnon tai suunnitelman, joka on muuttunut ilman hyväksyntää. Se voi kiillottaa etuovea, kun keittiö on tulessa.
Varmentamisen pitäisi kytkeytyä sopimuksiin ja seurauksiin. Jos tehtävä on poiminta, varmenna lähdeosuuksia vasten. Jos tehtävä on luokittelu, varmenna sallitut tunnisteet ja todisteet. Jos tehtävä on työkalun suoritus, varmenna käyttöoikeudet, argumentit, sivuvaiikutukset ja palautus. Jos tehtävä on päätöksenteon tuki, varmenna käytännöt, lähteen ajantasaisuus, epävarmuus ja tarkistusvaatimukset. Jos tehtävä on viestintä, varmenna yleisö, väitteet, sävy ja ilmoitusvelvollisuus. Yleiskäyttöinen varmennin on parempi kuin ei mitään. Tehtäväkohtainen varmennin on parempi kuin teatteri.
Osa varmentamisesta pitäisi olla determinististä. Skeemat, sallitut arvot, käyttöoikeudet, budjetit, kynnykset, lähteen ajantasaisuus ja pakolliset kentät eivät tarvitse mallin runollista harkintaa. Käytä sääntöjä, kun säännöt ovat selkeitä. Käytä malleja, kun epäselvyys on todellista. Käytä ihmisiä, kun seuraukset ja kiistetyt merkitykset vaativat vastuunkantoa. Maaginen orkestrointi pyytää usein mallia varmentamaan toista mallia, koska se tuntuu symmetriseltä. Symmetria on miellyttävää arkkitehtuurikaavioissa. Se ei automaattisesti ole valvontaa.
Varmentimen pitäisi nähdä tarvitsemansa jälki. Pelkkä lopullinen teksti ei harvoin riitä. Se tarvitsee syötteet, lähdejoukon, työkalujen tulokset, epäonnistuneet yritykset, muunnokset, käytäntötarkistukset ja suunnitellun toiminnon. Sillä pitäisi myös olla valtuudet estää, pyytää lisää todisteita, ohjata ihmisen tarkistettavaksi tai merkitä rajoitteet. Varmennin, joka ei voi pysäyttää työnkulkua, on arvostelija juhlapuvussa.
Muisti ei saa esiintyä auktoriteettina
Agenttimuisti on hyödyllistä, kun se kantaa mieltymyksiä, aiempaa kontekstia ja toistuvien tehtävien tietoa. Se on vaarallista, kun se esiintyy auktoritatiivisena tilana. Muistettu mieltymys ei ole käytäntö. Aiempi vastaus ei ole tietue. Yhteenveto tapauksesta ei ole tapaus. Onnistunut aiempi suunnitelma ei ole todiste siitä, että seuraava tehtävä sallii samat työkalut. Muisti auttaa jatkuvuudessa. Sitä ei saa antaa salakuljettaa eilisen auktoriteettia tähän päivään.
Muisti tarvitsee tyypit. Henkilökohtainen mieltymys, tehtävän tila, organisaation käytäntö, lähdetodiste, opittu kaava, välimuistiin tallennettu työkalun tulos ja historiallinen päätös ovat eri asioita. Ne tarvitsevat eri laajuudet, vanhenemisajat, käyttöoikeudet ja näytön. Jos orkestroija vain hakee olennaiset muistot ja lisää ne kontekstiin, relevanssista tulee ainoa portti. Relevanssi ei ole lupa. Yksityinen muistiinpano voi olla olennainen. Se voi silti olla kielletty.
Muisti tarvitsee myös poistoa ja korjausta. Väärä oletus ei saa jäädä voimaan, koska se oli kerran hyödyllinen. Väliaikainen projektiehto pitäisi vanhentaa. Käyttäjän korjaus pitäisi soveltaa määritellyssä laajuudessa. Käytännön muutos pitäisi mitätöidä vanha muisti. Mallin tuottama yhteenveto ei saa tulla oikotieksi, joka korvaa ensisijaisen lähteen. Järjestelmän pitäisi näyttää, mikä muisti vaikutti suunnitelmaan, ja antaa käyttäjien haastaa se. Muuten muistista tulee kohtelias kummitus.
Sääntö on yksinkertainen: auktoritatiivinen tila elää hallituissa säilytyspaikoissa. Muisti voi auttaa suunnittelua, mutta sen ei pitäisi päättää hiljaa. Jos orkestroija käyttää muistia, kirjaa, mikä muisti, miksi se sallittiin ja miten se vaikutti suunnitelmaan. Tämä tuntuu raskaalta vain, jos muisti tekee seurauksellista työtä. Jos muisti tekee seurauksellista työtä, raskaus on juuri se pointti.
Yksinkertainen voittaa maagisen useammin kuin tiimit odottavat
Kaikki tekoälytyönkulut eivät tarvitse agentteja. Jotkut tarvitsevat deterministisen putken, jossa on yksi mallivaihe. Jotkut tarvitsevat haun, luokittelijan ja ihmisen tarkistusjonon. Jotkut tarvitsevat lomakkeen, joka kutsuu mallia luonnostelua varten. Jotkut tarvitsevat eräarvioinnin. Jotkut tarvitsevat suunnittelijan. Jotkut tarvitsevat monivaiheisen työkalukäytön. Arkkitehtuurin tulisi seurata tehtävää, ei nykyistä innostusta agentinmuotoisista kaavioista.
Tylsä vaihtoehto voittaa usein. Kiinteä järjestys on helpompi testata kuin avoin silmukka. Tyypitetty työkaluyhdyskäytävä on turvallisempi kuin vapaa työkalunvalinta. Jono, jossa on selkeät tilat, on helpompi operoida kuin rekursiivinen agentti. Sääntöpohjainen vartija on halvempi kuin mallipohjainen arvioija, kun sääntö on selkeä. Ihmisen eskalointipolku on parempi kuin uusi yritys, kun seuraukset ovat suuret. Nämä eivät ole tekoälyvastaisia kantoja. Ne ovat järjestelmämyönteisiä kantoja.
Tässä on kompromissi. Joustavampi orkestrointi voi käsitellä epäselvyyksiä ja odottamattomia reittejä. Se myös lisää vaihtelua, todistustaakkaa, kustannuksia ja virheenjäljityksen monimutkaisuutta. Eksplisiittisempi orkestrointi voi tuntua jäykältä. Se myös parantaa toistettavuutta, omistajuutta ja palautumista. Oikea piste riippuu tehtävän epäselvyydestä, seurauksista, volyymista ja sietokyvystä epäonnistumisille. Taikauskoinen ajattelu väittää, että joustava pää antaa kaiken ilmaiseksi. Tuotanto lähettää laskun myöhemmin, riveittäin.
Hyödyllinen suunnittelukysymys on: mitä mallin ei pitäisi koskaan valita. Lähdeauktoriteetti. Käyttäjän käyttöoikeudet. Budjettirajat. Peruuttamattomat toimet. Säilytysvelvoitteet. Oikeusperusta. Turvallisuuskynnykset. Osa näistä voi olla mallien ehdottamia tai selittämiä. Niitä ei pitäisi antaa mallien hiljaa asettaa. Malli voi auttaa navigoimaan työnkulussa. Siitä ei pitäisi tulla perustuslakia vain siksi, että oli kätevää laittaa kaikki kontekstiin.
Suunnittele orkestrointi toimintamallina
Vakava orkestrointi alkaa tehtäväsopimuksesta. Mikä on tavoite. Mitä dataa on sallittua käyttää. Mitkä tuotokset ovat hyväksyttäviä. Mitä työkaluja saa käyttää. Mitkä toimet ovat kiellettyjä. Mikä budjetti pätee. Mikä viive on siedettävä. Mitä todisteita on säilytettävä. Mitä ihmisen rooleja on olemassa. Mitkä epäonnistumistilat ovat mahdollisia. Mitä palautumispolkuja on olemassa. Jos tiimi ei pysty vastaamaan näihin kysymyksiin, se ei tarvitse taianomaisempaa graafia. Se tarvitsee selkeämmän tehtävän.
Määrittele sitten tilasiirtymät. Suunniteltu, odottaa syötettä, hakee, työkalu odottaa, työkalu epäonnistui, todisteiden ristiriita, käytännön estämä, ihmisen tarkistus, hyväksytty, sovellettu, kompensoitu, peruutettu. Nämä tilat voivat kuulostaa arkisilta, koska ne ovat. Ne mahdollistavat järjestelmän operoinnin. Ne kertovat ihmiselle, pitääkö odottaa, puuttua, hyväksyä vai korjata. Ne mahdollistavat testien vahvistaa käyttäytymisen. Ne mahdollistavat häiriöiden alkavan tosiasioista eikä tunnelmista.
Määrittele sitten rajat. Mallit luonnostelevat suunnitelmia. Yhdyskäytävät suorittavat työkaluja. Säännöt valvovat täsmällisiä rajoitteita. Varmistimet tarkistavat sopimukset. Ihmiset päättävät kiistellyistä seurauksista. Lokit säilyttävät todisteet. Jonot käsittelevät viivettä. Tallennus pitää pysyvän tilan. Jokaisen rajan tulisi olla tarpeeksi tylsä selitettäväksi. Jos malli tekee useita näistä, koska se oli helpompaa, nimeä riski ja päätä, onko tehtävä tarpeeksi matalan panoksen sietääkseen sen. Joskus se on. Monet sisäiset avustajat voivat olla kevyitä. Ongelma on teeskennellä, että kevyt suunnittelu on perusta korkean seurauksen automatisoinnille.
Lopulta testi epäonnistuu. Työkalu palauttaa osittaista dataa. Lähde on ristiriidassa. Malli tuottaa virheellistä tulosta. Muisti on vanhentunutta. Käyttäjältä puuttuu oikeus. Kustannusraja ylittyy. Ihmisen tekemää tarkistusta ei ole saatavilla. Verkko on hidas. Suunnitelma muuttuu hyväksynnän jälkeen. Toiminto onnistuu osittain. Jos orkestraattori ei pysty kertomaan, mitä näissä tapauksissa tapahtuu, graafi on vain koriste. Se voi silti olla kaunis graafi. Aseta se kasvin viereen, älä tuotantoon.
Opetus
Taikuuteen nojaava orkestrointi vastustaa insinöörin kurinalaisuutta. AI-järjestelmät tarvitsevat koordinointia, ja mallit voivat tehdä koordinoinnista mukautuvampaa. Mutta mukautuminen ilman eksplisiittistä tilaa, työkalujen sopimuksia, uudelleenyrityskäytäntöä, varmennusta, muistin rajoja, toimintojen portteja ja palautuspolkuja ei ole älykkyyttä. Se on järjestelmä, joka pyytää tulevia ylläpitäjiä selvittämään sen suunnittelun lukemalla jälkiä sen jälkeen, kun jotain kallista on tapahtunut.
Hyvä orkestrointi on vähemmän mystistä ja hyödyllisempää. Se nimeää tilat. Se rajoittaa työkaluja. Se tallentaa todisteet. Se erottaa ehdotuksen toiminnasta. Se luokittelee uudelleenyritykset. Se varmistaa tehtäväsopimuksia vasten. Se kohtelee muistia avustavana, ei auktoritatiivisena. Se antaa ihmisille tarkistettavat tilat läpinäkymättömien transkriptioiden sijaan. Se valitsee yksinkertaiset putkistot, kun yksinkertaiset putkistot riittävät. Se lisää agentteja, kun monitulkintaisuus oikeuttaa operatiivisen hinnan.
Taikuus piilottaa mekanismin. Vakava AI tarvitsee mekanismeja, joita voidaan tarkastaa, pysäyttää, korjata ja parantaa. Tavoitteena ei ole poistaa ihmettä ohjelmistosta. Tavoitteena on pitää ihme poissa vikatilanneraportista.