"Prompt engineer" ei koskaan ollut täsmällinen ammattinimike, mutta hetken aikaa sen ei tarvinnutkaan olla. Jos koko työsi oli saada yksi hyvä vastaus yhdestä päättelykutsusta, yksi taitokokonaisuus riitti kattamaan sen: muotoile ohje hyvin, anna pari esimerkkiä, ehkä lisää haettua tekstiä, ja valmista tuli. Tuo taitokokonaisuus on yhä tärkeä. Mutta se ei enää kata sitä, mitä "agentin rakentaminen" tarkoittaa vuoden 2026 puolivälissä, ja kuilu näkyy tietynlaisena, tunnistettavana vikatilana: agentteina, jotka toimivat loistavasti demossa ja sitten hiljalleen rapistuvat, ovat ristiriidassa itsensä kanssa tai unohtavat, mitä käyttäjä kertoi niille kaksi istuntoa sitten.

Machine Learning Masteryn tuore artikkeli nimeää tämän kuilun suoraan, ja siihen kannattaa pysähtyä, koska se osuu siististi yhteen kahden eri työn kanssa, joihin sinut voisi todellisuudessa palkata. Context engineering eli kontekstin suunnittelu on sitä, mitä tapahtuu yhden päättelykutsun sisällä: päättämistä siitä, mitä kontekstin ikkunaan laitetaan, mihin kohtaan rakenteellisesti se sijoitetaan, ja mitä tiivistetään tai jätetään pois, jotta malli ei huku epäolennaisiin tokeneihin. Memory engineering eli muistin suunnittelu on eri ongelma, joka on olemassa vain kutsujen välillä: mitä kirjataan ylös istunnon päätyttyä, mihin se tallennetaan, miten se haetaan seuraavalla kerralla, ja miten sitä ylläpidetään (päivitetään, poistetaan duplikaatit, vanhennetaan), jottei se mätäne. Kyseisen artikkelin mukaan viat, jotka ilmenevät pitkissä, useita istuntoja kattavissa agenttityönkuluissa, johtuvat useimmiten näiden kahden työn sekoittamisesta tai jommankumman ohittamisesta - erityisesti sillä, mitä he kutsuvat "hakurajaksi", eli hetkeksi, jolloin agentin on päätettävä, onko sen tarvitsema asia jo sen edessä vai onko se haettava tallennuksesta.

Miksi niiden sekoittaminen on itse asiassa vika, ei yksityiskohta

Ajattele, mitä kumpikin oppiala pyrkii optimoimaan. Kontekstin suunnittelu optimoi yksittäistä, rajattua, kertakäyttöistä ikkunaa - saa oikean tietopalan mallin eteen juuri nyt, tätä yhtä vaihtoa varten, ja heittää sitten loput pois. Muistin suunnittelu optimoi pysyvää varastoa, jonka on säilyttävä istuntojen yli, pysyttävä johdonmukaisena uuden tiedon saapuessa, ja vastattava paljon vaikeampaan kysymykseen: ei "mikä on olennaista tälle kehotteelle" vaan "mikä on ylipäätään säilyttämisen arvoista, ja kuinka kauan".

Nämä ovat erilaisia suunnitteluongelmia, joilla on erilaiset vikatilat. Kontekstin suunnittelun virhe huonontaa yhtä vastausta. Muistin suunnittelun virhe kasautuu - huonot kirjoitukset kertyvät, vanhentuneita faktoja haetaan ikään kuin ne olisivat ajantasaisia, eikä kukaan huomaa ennen kuin agentti itsevarmasti toistaa jotain, mikä korjattiin kolme istuntoa sitten. Jos yksi henkilö (tai yksi kehotepohja) tekee hiljaa molempia töitä erottelematta niitä, muistikerros taipuu perimään kontekstin suunnittelun tapoja, joita sen ei pitäisi: varaston ylitäyttämistä samaan tapaan kuin ikkunan ylitäyttäisi, tai hakemisen kohtelemista relevanssin luokittelun ongelmana, vaikka se on todellisuudessa kuratoinnin ja ylläpidon ongelma. Juuri tähän sekoittumiseen tutkimuskooste viittaa, ja se osuu yhteen sen kanssa, mitä käytännön tekijät jo kuvaavat kokemusperäisesti: agentteja, jotka ovat vaikuttavia yhden istunnon aikana ja epäluotettavia viidenteen istuntoon mennessä.

Miltä kumpikin työ käytännössä näyttää päivittäin

Jos yrität selvittää, kumpaa näistä jo teet, tai kumpaa kohti haluaisit rakentaa, päivittäinen työ näyttää tarpeeksi erilaiselta erottaakseen ne toisistaan:

Kontekstin suunnittelu käytännössä: sen päättämistä, mikä osajoukko saatavilla olevasta tiedosta (dokumentit, työkalujen tulosteet, aiemmat vuorot) todella kuuluu tähän kutsuun; sen valitsemista, mihin kohtaan kehotetta se sijoitetaan, koska sijainti vaikuttaa siihen, miten mallit painottavat sitä; tiivistys- tai yhteenvetovaiheiden kirjoittamista, jottei pitkä työkalujälki syö koko budjettia; ja tämän hienosäätämistä tehtäväkohtaisesti, koska virheenkorjausagentti ja kirjoitusagentti haluavat erilaiset konteksti­muodot jopa samalla taustamallilla.

Muistin suunnittelu käytännössä: kirjoituskäytännön määrittelyä (mikä on säilyttämisen arvoista istunnon jälkeen - ei kaikki ole); tallennuskerroksen valitsemista (vektorivarasto, jäsennelty tietokanta, tavalliset tiedostot, jokin hybridi) ja rehellisyyttä kunkin kompromisseista; hakustrategian rakentamista, joka päättää, mitä palautetaan ja milloin; ja jatkuvaa ylläpitoa - karsimista, päällekkäisten faktojen yhdistämistä, ristiriitojen käsittelyä, kun käyttäjä muuttaa mieltään. Tuo viimeinen osa, ylläpito, on se, joka useimmin jätetään väliin, koska se ei näy ennen kuin agentti on ollut käynnissä viikkoja.

Voi nähdä, että ala alkaa erottaa näitä huolenaiheita rakenteellisesti, ei vain käsitteellisesti. Lenny's Newsletterin läpikäynti virheenkorjausvaljaan rakentamisesta Claude Agent SDK:n päälle kohtelee oikeuksia, työkalusovittimia ja ympäröivää "valjasta" omana suunnittelupintanaan, erillisenä sen sisällä olevasta kehottamisesta - sama vaisto, sovellettuna eri saumaan. Ja Googlen uudemmat Gemini API:n "Managed Agents" -ominaisuudet - taustasuoritus, tunnistetietojen päivitys vuorovaikutusten välillä - ovat käytännössä alustatoimittajan myöntämistä, että istunnon ylittävä pysyvä tila on nyt infrastruktuuria, joka on suunniteltava, ei sivuvaikutus riittävän pitkästä kontekstin ikkunasta. Jonkun on omistettava tuo suunnittelu. Juuri nyt, monissa tiimeissä, kukaan ei nimenomaisesti omista.

Miksi tämä on tärkeää ammattinimikkeellesi, ei vain koodillesi

Jos olet ura-alkuvaiheessa tai keskiuralla ja "prompt engineer" tai "AI engineer" on ansioluettelossasi, kannattaa kysyä, kummasta näistä kahdesta työstä voit oikeasti osoittaa näyttöä - koska yleisagentti-tekoälyroolit alkavat pirstoutua tarkemmiksi rooleiksi, samalla tavalla kuin "webmaster" lopulta jakautui frontendiksi, backendiksi ja DevOpsiksi. Se on varovainen arvio, ei otsikko: en ole nähnyt kovaa rekrytointidataa, joka vahvistaisi "memory engineer" -nimikkeen omaksi ammattinimikkeekseen vielä, joten pidä tätä lukemana siitä, mihin suuntaan työ on menossa, ei väitteenä, että työpaikkailmoitukset olisivat jo järjestyneet näin. Mutta taustalla oleva paine on todellinen ja jäljitettävissä yllä olevaan koosteeseen: agenttitiimit törmäävät tiettyyn, nimettävissä olevaan vikaan (useiden istuntojen rapistuminen), jolla on tietty, nimettävissä oleva syy (kahden oppialan sekoittaminen), ja tuo yhdistelmä on yleensä se, mikä muuttaa epämääräisen roolin kahdeksi teräväksi rooliksi.

Käytännön siirto ei ole keksiä itselleen nimikettä. Se on kyetä vastaamaan konkreettisesti, minkä ongelman olet oikeasti ratkaissut. Oletko toimittanut jotain, jossa suunnittelit kirjoituskäytännön - säännön siitä, mitä agentti tallentaa muistiin ja mitä se hylkää? Oletko korjannut hakurajan vian, jossa agentti tarvitsi jotain varastosta ja joko ei hakenut sitä tai haki väärän version? Nämä ovat tarkistettavissa olevia väitteitä, joita voit esittää haastattelussa, tuettuna repolla tai jälkiraportilla, ja ne kertovat jotain, mitä yleinen "kirjoitan hyviä kehotteita" ei kerro: että ymmärrät eron yhden vastauksen parantamisen ja agentin ajan mittaan luotettavaksi tekemisen välillä.

Varoituksen sana

Älä nimeä itseäsi uudelleen "memory engineeriksi" sen perusteella, että olet kerran lisännyt vektoritietokannan projektiin. Oppiala, johon tutkimus viittaa, sisältää sen epäglamouroisen puolikkaan - ylläpidon, vanhentumisen, ristiriitojen käsittelyn - ja juuri se puoli itse asiassa estää yllä kuvatun vikatilan. Jos portfoliosi näyteprojekti on järjestelmä, joka kirjoittaa muistiin, mutta mitään ei koskaan karsita tai korjata, olet rakentanut vain puolet muistiinsuunnittelijan työstä, ja kolmannen istunnon jälkeen ilmenevä ongelma odottaa sinua yhä sillä toisella puoliskolla.