Agentin työkalukutsujen parhaat käytännöt: miksi agenttisi valitsee väärän työkalun

Agentin työkalukutsujen parhaat käytännöt: miksi agenttisi valitsee väärän työkalun

Agentin työkalukutsujen parhaat käytännöt erottavat toimivan demon ja agentin, joka kutsuu tuotannossa hiljaisesti väärää työkalua. Anthropicin engineering-tiimi mittasi, kuinka yksi uudelleenkirjoitettu kuvaus pudotti yhden työkalutuloksen 206 tokenista 72:een, ja Claude Code rajoittaa nykyään jokaisen työkaluvastauksen enintään 25 000 tokeniin, koska vuoto on todellinen. Agenttisi epäonnistuu neljällä tavalla: väärä työkalu, väärät argumentit, karkaava silmukka ja tokenvuoto. Jokaiseen on korjaus, jonka voit viedä tuotantoon tämän viikon aikana.

Keskeisimmät opit:

• Agentin työkalukutsut epäonnistuvat täsmälleen neljällä tavalla: väärä työkalu, väärät argumentit, karkaavat silmukat ja tokenvuoto.
• Työkalukuvaukset ovat ainoa ohje, jonka malli näkee valintahetkellä, joten ne korjaavat useimmat väärän työkalun kutsut.
• Litteät, tehtävän muotoiset skeemat ja validoitu syöte poistavat useimmat väärät argumenttivirheet.
• Tiiviit työkaluvastaukset ja jokaisen muutoksen yhteydessä ajettava arviointisilmukka pitävät tokenkustannukset ja regressiot mitattavissa.

Miksi agentin työkalukutsut epäonnistuvat tuotannossa?

Agentin työkalukutsut epäonnistuvat neljällä tavalla: malli valitsee väärän työkalun, kirjoittaa väärät argumentit, pyörii karkaavassa silmukassa tai vuotaa tokeneita lihavien vastausten kautta. Jokainen virhe osuu kutsusilmukan eri vaiheeseen, joten korjausjärjestyksellä on väliä. Aloita valinnasta, sillä väärä työkaluvalinta myrkyttää jokaisen sitä seuraavan askeleen.

Koko hoito-ohje yhdellä silmäyksellä:

Käy ne läpi tässä järjestyksessä. Käytännöt 1 ja 2 vievät yhden iltapäivän ja poistavat suurimman osan väärän työkalun ja väärän argumentin virheistä, joita näet nykyään. Työkalukuvaus ei ole dokumentaatiota. Se on ainoa ohje, jonka malli saa valintahetkellä.

Vaihe 1: Suunnittele työkalut, joita malli pystyy oikeasti käyttämään

Agentin työkalukutsujen halvimmat luotettavuushyödyt piilevät työkalumäärittelyissäsi, eivät prompteissasi tai mallivalinnassasi. Malli ei koskaan lue API-dokumentaatiotasi tai READMEiasi. Se näkee nimen, kuvausmerkkijonon ja JSON-skeeman, ja päättää pelkästään niiden perusteella. Kun saat nämä kolme kuntoon, valintatarkkuus paranee ennen kuin kosket mihinkään muuhun.

Käytäntö 1: Kirjoita kuvaukset, joiden perusteella malli voi toimia

Kirjoita työkalukuvaukset mallille annettuina ohjeina, ei API-dokumentaationa. Kuvaus, joka tyydyttää ihmiskehittäjän ("REST-wrapper users-päätepisteelle"), ei anna mallille mitään päätöksen perustetta. Anthropicin engineering-opas työkalujen kirjoittamisesta ja heidän työkalumäärittelyjen parhaat käytäntönsä ajavat samaa kaavaa: kerro milloin työkalua käytetään, mitä se palauttaa ja milloin sitä EI saa käyttää.

{
  "name": "get_user",
  "description": "Fetches a user profile. Use ONLY when you already have a user_id. Do NOT use to search or list users; call search_users instead. Returns name, email, plan. Errors if user_id is not a valid UUID."
}

verrattuna versioon, jonka useimmat tiimit julkaisevat:

{
  "name": "get_user",
  "description": "Gets a user."
}

Kaksi sääntöä tekee tässä suurimman osan työstä. Ensinnäkin, nimeä parametrit niin, että niiden merkitys on yksiselitteinen: user_id, ei koskaan user tai id, koska user houkuttelee mallia välittämään nimen tai sähköpostiosoitteen sinne, minne kuuluu UUID. Toiseksi, ilmoita poissulkemiset suoraan. "Älä käytä käyttäjien hakuun" estää useamman väärän työkalun kutsun kuin mikään määrä positiivista kuvausta, koska mallit sekoittavat päällekkäisiä työkaluja paljon useammin kuin ne ymmärtävät väärin yksittäisiä, selkeästi rajattuja työkaluja. Jos haluat nähdä, miten nämä määrittelyt päätyvät OpenAI:n, Anthropicin ja Googlen rajapintoihin, lue monen tarjoajan function calling -oppaamme.

Käytäntö 2: Pidä skeemat litteinä ja tehtävän muotoisina

Pidä syöteskeemat litteinä: jokainen kenttä, jonka tehtävä todella tarvitsee, eikä yhtään, jota se ei tarvitse. Sisäkkäiset objektit valinnaisine haaroineen ovat väärän argumentin virheiden kasvualusta: mallin täytyy päätellä rakenne, josta se ei koskaan näe esimerkkejä. OpenAI function calling -opas hyväksyy mielivaltaisen JSON-skeeman, mutta salliva ei tarkoita samaa kuin luotettava.

{
  "name": "create_ticket",
  "parameters": {
    "type": "object",
    "properties": {
      "ticket": {
        "type": "object",
        "properties": {
          "details": {
            "type": "object",
            "properties": {
              "title": { "type": "string" },
              "meta": { "type": "object" }
            }
          }
        }
      }
    }
  }
}

Litistä se tehtävän muotoon:

{
  "name": "create_ticket",
  "parameters": {
    "type": "object",
    "properties": {
      "title": { "type": "string" },
      "priority": { "type": "string", "enum": ["low", "medium", "high"] },
      "assignee_id": { "type": "string" }
    },
    "required": ["title", "priority"]
  }
}

Enumit voittavat vapaan tekstin jokaisessa kentässä, jonka arvot muodostavat rajatun joukon. Required-listat voittavat valinnaisen kaiken. Jos malli tarvitsee kentän lähes aina, tee siitä required työkaluskeemassa, vaikka API kutsuisi sitä valinnaiseksi. Et peilaa APIasi. Suunnittelet pintaa, jonka yksi tietty malli pystyy täyttämään oikein.

Vaihe 2: Hallitse työkaluvalikoimaa, et vain yksittäisiä työkaluja

Yksittäisen työkalun laatu ei enää riitä, kun agentilla on hallussaan käsfullista enemmän työkaluja, koska valintavirheet kasvavat sen listan koon mukana, jonka malli lukee.

Käytäntö 3: Kääri monivaiheiset API-ketjut atomisiksi työkaluiksi

Tiivistä jokainen kiinteä API-kutsujen sarja yhdeksi atomiseksi työkaluksi. Anthropicin engineering-artikkeli käyttää esimerkkeinä schedule_event- ja get_customer_context-työkaluja: yksi kutsu, joka tekee koko työn, voittaa kolme kutsua, jotka agentin täytyy ketjuttaa oikein joka kerta. Jokainen ketjun lenkki on uusi vuoro, jolla malli voi pysähtyä, yrittää uudelleen väärin tai joutua silmukkaan.

# What the agent does WITHOUT an atomic tool: 3 calls, 3 chances to fail
calendar = call_tool("list_calendars", {})
free = call_tool("find_free_slot", {"calendar_id": calendar["items"][0]["id"], "duration": 30})
call_tool("create_event", {"calendar_id": calendar["items"][0]["id"], "start": free["start"]})

# One atomic tool: the sequence lives in your code, not the model's head
call_tool("schedule_event", {"duration": 30, "attendees": ["[email protected]"]})

Nyrkkisääntö: jos mallin täytyy aina kutsua B:tä A:n jälkeen, A ja B ovat yksi työkalu kahdessa asussa.

Käytäntö 4: Käytä nimiavaruuksia, karsi ja suodata työkaluja dynaamisesti

Laita jokaisen työkalun nimi nimiavaruuteen ja näytä kullekin agentille vain sen nykyisen tehtävän tarvitsema osajoukko. Yleiset nimet törmäävät heti, kun liität kaksi integraatiota. Kuvittele agentti, joka on kytketty kahteen MCP-palvelimeen, jotka molemmat tarjoavat search-nimisen työkalun: kaksi samanlaista verbiä, eikä mitään tapaa erottaa niitä. Anthropic dokumentoi mitattavia eval-parannuksia etuliitenimiavaruuksista:

Karsiminen on yhtä tärkeää kuin nimeäminen. Tukipalveluagentti ei tarvitse laskutustyökalujaan ladattuna, kun se vastaa salasanakysymykseen. Planner-worker-malli, jossa suunnittelija reitittää tehtävän toteuttajalle, joka lataa vain asiaankuuluvat työkalut, on vakiokorjaus; LangGraphin opas dynaamiseen työkalujen lataamiseen käy toteutuksen läpi. Kuinka monta työkalua on liikaa? Pidä 5-10 työkalua agenttia kohden työskentelyalueena, ei lakina: tarkkuus heikkenee listan kasvaessa, ja lääke on suodatus, ei isompi malli. Jos olet itse valitsemassa reitys- ja suodatuskerrosta, vertaa vaihtoehtoja parhaiden function calling -kirjastojen vertailussamme.

Vaihe 3: Hallitse sekä tulevat vastaukset että lähtevät kutsut

Silmukka kulkee molempiin suuntiin, ja useimmat tiimit suunnittelevat vain lähtevän puoliskon. Se, mitä työkalusi palauttavat, ratkaisee, kuinka suuri osa konteksti-ikkunasta selviää seuraavalle vuorolle, ja se, mitä validointisi hylkää, ratkaisee, oppiiko malli virheistään vai toistaako se niitä.

Käytäntö 5: Palauta tiiviitä ja signaalipitoisia tuloksia

Palauta pienin tulos, jolla malli voi toimia, ja käytä raakojen ID:iden sijaan ihmisluettavia tunnisteita. Anthropicin engineering-artikkeli dokumentoi työkalun, jonka oletustulos oli 206 tokenia; tiivis response_format-asetus pudotti saman tuloksen 72 tokeniin, suunnilleen kolmasosaan alkuperäisestä. Kerro se kymmenillä kutsuilla tehtävää kohden, ja se ratkaisee, saako agenttisi tehtävän lainkaan valmiiksi.

// Before: 206 tokens (shape per Anthropic's documented example)
{
  "status": "success",
  "data": {
    "id": "8f14e45f-ceea-3f9c-a2f3-90c1b5e0a7d2",
    "object": "task", "created_at": "2026-07-02T09:14:00Z",
    "updated_at": "2026-07-11T16:40:12Z", "completed_at": null,
    "assignee": {"id": "c9a1...f2", "object": "user"},
    "projects": [{"id": "b7d3...91", "object": "project"}],
    "permalink": "https://app.asana.com/0/.../f"
  }
}

// After: 72 tokens
{ "task": "Fix login redirect", "assignee": "Dana Kim", "project": "Web App", "due": "2026-07-20" }

Kaksi lisäyksityiskohtaa samasta lähteestä: Anthropic tukee työkalumäärittelyissä response_format-enumia (detailed vai concise), joten voit ilmoittaa haluamasi muodon sen sijaan, että jäsentäisit paloletkua. Ja Claude Code rajoittaa työkaluvastaukset 25 000 tokeniin, kova katto, joka katkaisee paisuneet tulokset joka tapauksessa. Anthropic raportoi myös omana havaintonaan, että UUID:ien ratkaiseminen semanttisiksi nimiksi vähensi mitattavasti hakuhallusinaatioita, minkä vuoksi yllä oleva "jälkeen"-payload sanoo "Dana Kim" eikä c9a1...f2. Lihavat vastaukset ovat myös kustannusongelma; lue LLM-API-kustannusten pienentämisoppaamme saadaksesi kokonaiskuvan.

Käytäntö 6: Validoi jokainen kutsu ja anna virheiden opettaa mallia

Validoi jokainen työkalukutsu palvelimella ja palauta virheitä, jotka sisältävät korjauksen. Martin Fowlerin artikkeli function callingista muotoilee sen suoraan: älä koskaan luota mallin tulokseen. Se välittää merkkijonoja sinne, minne kuuluu enum, ja keksii ID:itä, joita ei ole olemassa.

def create_ticket(args):
    if args.get("priority") not in {"low", "medium", "high"}:
        return {"error": f"priority must be one of: low, medium, high. Got '{args.get('priority')}'. Pass priority='medium' for normal issues."}
    if not is_valid_uuid(args.get("assignee_id")):
        return {"error": "assignee_id must be a UUID. Call list_team_members to get valid IDs, then retry."}
    return db.create_ticket(**args)

Virhemerkkijono on koko peli. Vertaa:

# Unhelpful: the model retries the same bad call
{"error": "invalid input"}

# Helpful: the model knows exactly what to change
{"error": "priority must be one of: low, medium, high. Got 'urgent'. Use 'high'."}

Jokainen validointivirhe, jonka työkalusi palauttaa, on prompti, jonka kirjoitat mallin seuraavaa yritystä varten. Virheet, jotka nimeävät rajoitteen ja osoittavat korjaavan työkalun, muuttavat uudelleenyrityssilmukan kerralla onnistuvaksi palautukseksi. Tämä on myös ensimmäinen turvallisuuspuolustuksesi; LLM-guardrails-oppaamme käsittelee aihetta syvällisesti.

Vaihe 4: Miten teet agentista turvallisen ja sitten mitattavan?

Turvallisuus ja mittaaminen ovat sama vaihe, koska vartioimaton tuhoava toiminto ja mittaamaton regressio päätyvät molemmat tapauksiksi, joita et nähnyt tulevan. Aseta portti toiminnoille, joita ei voi perua, ja mittaroi sitten kaikki, jotta seuraava työkalumuutos on päätös, jonka takana on näyttöä, ei toive.

Käytäntö 7: Aseta tuhoavat toiminnot ihmisen hyväksynnän taakse

Erota lukutyökalut kirjoitustyökaluista ja aseta ihmisen vahvistusportti kaikelle tuhoavalle. MCP-spesifikaation työkaluannotaatiot ovat olemassa juuri tätä varten: destructiveHint merkitsee tuhoavia päivityksiä tekevät työkalut, ja openWorldHint liputtaa ulkoisia järjestelmiä koskettavat työkalut, jotta asiakasohjelmat voivat kysyä vahvistusta ennen suoritusta. Käytä niitä.

Virhetila ei ole hypoteettinen. Laurent Kubaski dokumentoi tapauksen heinäkuun 2025 työkalukutsukatsauksessaan, johon alkuperäinen raportti on linkitetty: käyttäjä pyysi Excelin Copilotia toimimaan rivillä 4, ja agentti toimikin rivillä 8. Väärän rivin ja kirjoituksen välissä ei ollut vahvistusporttia. Korjaus on malli, jonka AWS dokumentoi Bedrock Agenteille: agentti valmistelee toiminnon, palauttaa sen hyväksyttäväksi ja suorittaa vasta, kun ihminen vahvistaa. Cursor tekee saman tiedostomuokkauksille. Rajaa tunnukset vain luku -oikeuksiin, kun tehtävä tarvitsee pelkkää lukemista, ja käsittele vahvistusportteja osana injektioaltista pintaasi, jota prompt injection -torjuntaoppaamme käsittelee.

Käytäntö 8: Aja arviointisilmukka jokaisen työkalumuutoksen yhteydessä

Aja pieni arviointisarja ennen jokaista työkalumuutosta ja sen jälkeen, ja lue mittarit kiinteässä järjestyksessä. Paragonin optimointiopas ehdottaa neljän mittarin kehystä, joka kannattaa omaksua:

Anthropicin tool evaluation cookbook, joka perustuu todellisiin Slack- ja Asana-MCP-arviointeihin, näyttää, miltä hyvät ja huonot eval-tehtävät näyttävät:

# Weak: vague, many valid paths, impossible to score
"Use the Asana tools to organize some work."

# Strong: one correct tool, checkable arguments, binary outcome
"Create a task titled 'Renew TLS cert' in project 'Infra' assigned to [email protected], due 2026-08-15. Expect exactly one create_task call with those four fields."

Tulkintamme, sellaiseksi merkittynä: julkaistut luvut antavat sinulle työskentelyjärjestyksen. Tarkista työkaluoikeellisuus ensin, koska Anthropicin omat mittaukset osoittavat kuvaus- ja nimeämismuutosten vaikuttavan siihen suoraan (206:sta 72:een tokeniin -uudelleenkirjoitus, UUID:n nimi-hallusinaatiohavainto), ja jätä tehtävän tehokkuus viimeiseksi, koska se heijastaa lähinnä virheitä, jotka kolme ensimmäistä mittaria ovat jo paljastaneet. Aloitusarvioinniksi suunnittele 15-30 tehtävää, kaksi tai kolme työkalua kohden, jokaisella yksi odotettu kutsu ja binäärinen läpäisyehto. Se koko riittää paljastamaan regression kuvausten uudelleenkirjoituksesta ilman viikon merkkaustyötä, ja luemme cookbookin Slack- ja Asana-asetelman näytöksi siitä, että näin pieni sarja on tarkoitettu lähtökohdaksi, ei oikotieksi. Syvemmät mekaniikat löytyvät AI-agenttien tuotantoarvioinnin oppaastamme, ja jos eval-tuloksesi kertovat työkalujen olevan kunnossa mutta orkestroinnin eivät, silloin on aika arvioida kehysvalintasi uudelleen parhaiden AI-agenttikehysten vertailua vasten.

Agentin työkalukutsut vs. MCP: mikä on ero?

MCP on kuljetus- ja rekisteristandardi, ei luotettavuuskerros, joten samat kahdeksan käytäntöä pätevät riippumatta siitä, saapuvatko työkalusi MCP:n yli vai määritelläänkö ne inline. Natiivi työkalukutsu on mallintarjoajan sopimus: miten malli lähettää tool_call-viestin ja lukee tool_result-viestin. MCP standardoi, miten työkalut saavuttavat mallin; se ei tee mitään sen eteen, valitseeko malli oikean.

MCP-palvelin, joka tarjoaa search-nimisen työkalun kuvauksella "searches things", epäonnistuu täsmälleen samalla tavalla kuin samoin määritelty inline-funktio. Korjaa määrittely, ja murehdi sitten kuljetuksesta. Model Context Protocol -oppaamme kattaa protokollapuolen alusta loppuun.

Miten Techsy soveltaa näitä kahdeksaa käytäntöä

Jokaisessa asiakasagenttiprojektissa pakotamme kolme näistä käyttöön ennen kuin mitään muuta julkaistaan: ohjeina kirjoitetut kuvaukset (käytäntö 1), validointiportit jokaisessa kirjoitustyökalussa (käytäntö 6) ja ennen julkaisua ajettava eval-sarja, ei vasta tapauksen jälkeen (käytäntö 8). Nämä kolme kattavat väärän työkalun kutsut, väärän argumentin kutsut ja molemmat uudelleen käyttöönottavat regressiot, mistä jokainen debuggaamamme tuotantoagenttitapaus on alkanut. Muut viisi käytäntöä seuraavat agentin kasvaessa. Jos agenttisi on edennyt demoa pidemmälle ja valitsee vääriä työkaluja, ota maksuton konsultaatio, niin kerromme, minkä kahdeksikosta kannattaa korjata ensin.

Tietoja kirjoittajasta

Mert Batur on Techsy.io:n perustajaosakas, ja hänen tiiminsä toimittaa tekoälyagentteja, automaatiojärjestelmiä ja voice/SDR-putkia B2B-asiakkaille. Hän kirjoittaa LLM-työkalupinosta, jonka Techsy-tiimi todella käyttää tuotannossa. Yhdistä LinkedInissä.

Usein kysytyt kysymykset

Mitä ovat agentin työkalukutsut?

Agentin työkalukutsut ovat mekanismi, jossa LLM päättää kutsua ulkoista funktiota, lähettää jäsennellyn tool_call-viestin ja odottaa koodisi palauttavan tool_result-viestin, jonka perusteella se voi päätellä. Sen ansiosta keskustelumallista tulee agentti, joka voi kysellä tietokantoja, kutsua rajapintoja ja tehdä toimia: malli valitsee työkalun ja argumentit, sinun suorittajasi ajaa ne.

Miten agentin työkalukutsusilmukka toimii?

Silmukassa on viisi vaihetta: käyttäjän pyyntö saavuttaa mallin, malli valitsee työkalun ja kirjoittaa tool_call-viestin, suorittajasi ajaa sen, tool_result palautuu mallille, ja malli joko vastaa tai tekee uuden kutsun. Tämä sykli toistuu, kunnes tehtävä on valmis. Tämän oppaan neljä virhetilaa elävät kukin tämän silmukan tietyssä vaiheessa.

Miksi agenttini valitsee väärän työkalun?

Yleensä siksi, että kaksi työkalua ovat päällekkäisiä eikä niiden kuvauksissa sanota, kumpi on kumpi. Malli valitsee pelkästään nimen ja kuvauksen perusteella, joten "gets a user" ja "finds users" näyttävät vaihdettavissa olevilta. Korjaa se poissulkuriveillä ("do NOT use to search"), nimiavaruuksilla ja pienemmällä työkalumäärällä kontekstissa. Kubaskin neljän mallin testi osoitti, että jopa vahvat mallit reitittävät väärin moniselitteisillä listoilla.

Miten pakotan työkaluja kutsuvan agentin jäsentämään tuloksensa?

Rajoita skeemaa, älä promptia. Käytä enumeja rajatuille kentille, required-listoja kaikelle, mitä tehtävä tarvitsee, ja litteitä objekteja sisäkkäisten sijaan. Lopulliselle vastaukselle työkalukutsun sijaan tarjoajien ominaisuudet, kuten OpenAI:n structured outputs ja Anthropicin tool-choice-tilat, pakottavat tietyn muodon. Structured outputs -oppaamme kattaa molemmat polut koodiesimerkkeineen.

Agentin työkalukutsut vs. MCP: mikä on ero?

Natiivi työkalukutsu on sopimus koodisi ja yhden mallintarjoajan välillä: tool_call- ja tool_result-viestimuoto. MCP on protokollakerros, joka standardoi, miten työkalut löydetään ja toimitetaan mille tahansa yhteensopivalle asiakkaalle. MCP muuttaa putkistoa, ei luotettavuutta. Huonosti kuvattu työkalu epäonnistuu samalla tavalla kummallakin polulla, kuten Model Context Protocol -oppaamme selittää.

Kuinka monta työkalua on liikaa LLM-agentille?

Pidä 5-10 työkalua agenttia kohden työskentelyalueena, ei lakina. Valintatarkkuus heikkenee näkyvän listan kasvaessa, erityisesti kun nimet tai kuvaukset menevät päällekkäin. Korjaus ei ole isompi malli vaan suodatus: lataa vain nykyisen tehtävän tarvitsema osajoukko planner-worker-jaolla. Laita kaikki nimiavaruuksiin, jotta kaksi integraatiota ei koskaan tarjoa molemmat paljasta search-työkalua.

Mikä on paras malli työkalukutsuihin?

Yhtä ainoaa vastausta ei ole, ja julkaistut benchmarkit vanhenevat tällä alalla huonosti. OpenAI:n, Anthropicin ja Googlen kärkimallit selvittävät perustyökalutehtävät kaikki, kun taas pienemmät mallit yhdistettynä hyvin suunniteltuihin työkaluihin saavat tehtävät usein lähes yhtä usein valmiiksi murto-osalla tokenkustannuksista. Rakenna käytännön 8 mukainen 15-30 tehtävän eval-sarja ja testaa ehdokkaat omia työkalujasi vasten.

Miten pienennän työkalukutsuista aiheutuvia tokenkustannuksia?

Karsi sitä, mitä takaisin tulee. Palauta tiiviitä, signaalipitoisia tuloksia raakojen API-payloadien sijaan: Anthropic dokumentoi 206:sta 72:een tokeniin pudotuksen yhdestä response_format-muutoksesta. Ratkaise UUID:t nimiksi, pudota kentät, joita malli ei koskaan käytä, ja muista, että jokainen työkalutulos palaa konteksti-ikkunaan jokaisella seuraavalla vuorolla. Harvemmat kutsut atomisilla työkaluilla poistavat kokonaisia tuloksia laskulta.

Miten arvioin työkalukutsujen laatua?

Pisteytä neljä mittaria järjestyksessä: työkaluoikeellisuus (oikea työkalu?), syötteen tarkkuus (kelvolliset argumentit?), tehtävän suoritus (tavoite saavutettu?) ja tehtävän tehokkuus (tokenien ja kutsujen määrä?). Kirjoita 15-30 tehtävää, joista kukin odottaa yhtä tiettyä kutsua tarkistettavilla argumenteilla ja binäärisellä läpäisyehdolla. Aja sarja ennen jokaista työkalumuutosta ja sen jälkeen, jotta kuvausten uudelleenkirjoitus ei koskaan mene tuotantoon mittaamatta.

Yhteenveto

Diagnosoi ennen kuin optimoit. Agenttisi valitsee väärän työkalun yhdestä neljästä syystä, ja kolme yllä olevista kahdeksasta käytännöstä, kuvaukset, litteät skeemat ja suodatus, korjaavat valintavirheet, jotka aiheuttavat useimmat tuotantotapaukset. Aloita niistä, koska ne maksavat yhden iltapäivän ja niiden ansiosta tämä ongelma on ylipäätään korjattavissa. Pidä validointivirheet informatiivisina, aseta kaikki tuhoava ihmisen hyväksynnän taakse ja aja arviointisilmukka jokaisen muutoksen yhteydessä, jotta mittaat ennen kuin vaihdat mallia. Väärän työkalun ongelma ei ole malliongelma. Se on työkalusuunnitteluongelma, ja suunnittelu on sinun käsissäsi.