De siste to årene har karriererådene rundt AI-agenter for det meste handlet om å lære å gi dem gode prompter. Det er ikke lenger den knappe ferdigheten. Den knappe ferdigheten er å bygge stillaset en agent opererer innenfor — det som i økende grad kalles en harness — og det er spesifikt nok, og vanskelig nok, til at det er i ferd med å bli en egen stillingsbeskrivelse i stedet for et sideansvar for «AI-personen» i et team.

Den klareste offentlige gjennomgangen av hva dette faktisk innebærer, kommer fra Lenny's Newsletter, som dokumenterer hvordan produktledelsesverktøyet ChatPRD bygde en harness for å feilsøke Sentry-feil automatisk. Artikkelen er verdt å lese i sin helhet hvis du vurderer å spesialisere deg på dette, fordi den peker på noe som er lett å overse: modellen var aldri flaskehalsen. Teamet brukte Claude Agent SDK som grunnmur, og brukte deretter mesteparten av ingeniørinnsatsen på et skreddersydd terminalgrensesnitt og et sett med adaptere som kobler agenten til Sentry, Linear, GitHub og Vercel. Det er jobben, i miniatyr. Fire systemer, fire ulike autentiseringsordninger, fire ulike dataformater, og et grensesnitt som lar et menneske følge med og gripe inn uten å måtte overvåke hvert eneste steg.

Hva «harness» faktisk består av

Hvis du prøver å finne ut om dette er en kompetanse verdt å bygge, hjelper det å dele den opp i biter som blir ansatt for hver for seg, eller i det minste vurdert hver for seg i et intervju:

  • Tillatelsesdesign. Å bestemme hva en agent har lov til å gjøre uten tilsyn (lese en sak, utkaste en PR) versus hva som krever et menneske i løkken (slå sammen, deploye, slette, bruke penger) — og å kode dette som faktisk policy, ikke som en promptinstruksjon modellen kan ignorere under press. Dette ligner mer på tilgangskontroll-ingeniørarbeid enn på promptskriving.
  • Verktøyadaptere. Tynne, godt testede omslag rundt hvert eksternt system (Sentry, Linear, GitHub, Vercel, eller hva enn selskapets stack består av) som oversetter agentens hensikt til et trygt, validert API-kall og oversetter svaret tilbake til noe modellen kan resonnere rundt. Dette er ordinært programvareutviklingsarbeid — feilhåndtering, gjenforsøk, skjemavalidering — anvendt på en ny konsument.
  • Terminal- eller konsollgrensesnitt. En måte for et menneske å se hva agenten gjør, godkjenne eller avvise handlinger, og gripe inn når den sitter fast. ChatPRD bygde et skreddersydd et; mange team vil bruke ferdige agentkonsoller i stedet, men noen må likevel bestemme hva som vises, hva som skjules, og hva som krever et klikk før det skjer.
  • Verktøyvalg i stor skala. En artikkel fra Machine Learning Mastery peker på noe som er verdt å vite hvis du bygger noe utover en demo: agenters nøyaktighet i verktøykall har en tendens til å svekkes så snart verktøykatalogen passerer omtrent et dusin alternativer — modellen begynner å kalle feil verktøy, hallusinere parametre, eller kjøre seg fast på dårlige kall. Tiltakene som listes opp (å styre hvilke verktøy som i det hele tatt er synlige i en gitt kontekst, gjenfinningsbasert verktøyoppslag, ruting til spesialiserte underagenter, eksplisitte planleggingssteg, reserveløsninger, og benchmark-harnesser som fanger opp regresjoner) er i seg selv en sjekkliste over ting en harness-ingeniør må vite hvordan man implementerer, ikke bare vite om.
  • Kontekst- og minneteknikk. Den samme kilden trekker et skille som er verdt å ta innover seg: kontekstteknikk (hva som går inn i et enkelt inferenskall, og hvor) og minneteknikk (hva som består på tvers av økter, hvordan det lagres, hvordan det hentes fram) er ulike disipliner med ulike feilmodus. Påstanden er at de fleste sammenbrudd i langvarige agenter med flere økter kan spores tilbake til at man blander de to sammen — behandler øktminne som om det bare er mer kontekst, eller omvendt — særlig i det punktet hvor systemet bestemmer hva som skal hentes fram.

Bevisene på at dette er en reell, finansierbar rolle — ikke bare en hobbynisje

Skeptikere vil med rette spørre om «harness-ingeniør» er en jobb eller bare en oppgave inne i noen andres jobb. To datapunkter fra sammendraget tyder på at det beveger seg mot det første. For det første brukte Microsofts Aspire-team — en gruppe på 10 personer — GitHubs Agentic Workflows til å automatisere dokumentasjons-PR-er på tvers av repoer, og over to utgivelser slo de sammen 82 PR-er med en median på 44,8 timer etter at den tilhørende produkt-PR-en ble sluppet, uten nye ansettelser og uten omopplæring av prosesser. Det er et lite team som får uforholdsmessig stor gevinst spesifikt fordi noen investerte i stillaset (workflow-definisjonene, gjennomgangsrutingen, utløserlogikken) i stedet for å la ingeniører skrive dokumentasjons-PR-er for hånd. For det andre behandler Microsoft Researchs SkillOpt-prosjekt agenters «skill»-filer — instruksjonene og begrensningene som former hvordan en agent oppfører seg i sin harness — som noe som skal optimaliseres systematisk snarere enn redigeres for hånd, og rapporterer at det var best eller delt best i alle 52 cellene i et benchmark-rutenett (seks benchmarker, sju modeller, tre kjøremodus), der de optimaliserte skillsene overførte seg på tvers av ulike modeller og ulike harnesser. Uansett om akkurat det verktøyet blir standard eller ikke, signaliserer det at bransjen begynner å behandle harness-konfigurasjon som et ingeniørartefakt med sine egne verktøy og benchmarker — samme utvikling som gjorde «DevOps» fra et sett ad hoc-skript til en disiplin.

Det bygges nå også infrastruktur eksplisitt for dette laget. Googles nylig annonserte «Managed Agents»-funksjoner i Gemini API-et — bakgrunns- og asynkron kjøring, integrasjon med eksterne MCP-servere, egendefinerte funksjonskall, fornyelse av legitimasjon på tvers av interaksjoner — er i praksis ferdigbygde rørsystemer for akkurat de problemene ChatPRD-teamet løste for hånd. Det er et vanlig mønster: det ett team bygger skreddersydd i år, produktiviserer en plattformleverandør neste år. Det fjerner ikke rollen som harness-ingeniør; det hever gulvet og flytter jobben mot å integrere og konfigurere administrerte byggeklosser i stedet for å skrive hver adapter fra bunnen av, på samme måte som skyinfrastruktur ikke fjernet driftsingeniører, men endret hva de brukte tiden sin på.

Hva dette betyr hvis du sikter deg inn mot denne rollen

Noen konkrete, sjekkbare ting å ha i en portefølje eller CV hvis du vil være troverdig for denne typen arbeid: bygg én adapter fra ende til annen mot et reelt API du ikke kontrollerer (inkludert autentisering, feilhåndtering, hastighetsbegrensninger, ikke bare en happy-path-demo); design og dokumenter en tillatelsesmodell for en agent som skiller mellom lese-/foreslå-/utføre-handlinger og som viser hvorfor hver grense ligger der den ligger; og bygg eller konfigurer et gjennomgangsgrensesnitt der et menneske godkjenner agenthandlinger før de utføres, siden det er delen de fleste selskaper vil insistere på før de lar en agent røre produksjon. Hvis du vurderer et jobbtilbud innen harness-ingeniørarbeid eller kartlegger ditt eget ansvarsområde, spør spesifikt hvem som eier tillatelsesmodellen, hvem som eier adapterne, og hvem som eier grensesnittet for menneskelig gjennomgang — i mange team akkurat nå har disse tre tingene ingen klar eier, noe som er nøyaktig det gapet denne rollen holder på å oppstå for å fylle.

Ett forbehold som er verdt å si rett ut: ingen av kildene over fastslår noe tall for arbeidsmarkedet for akkurat denne tittelen, og «harness-ingeniør» er ikke en stillingstittel du vil se i utlysninger ennå — den dukker opp inni titler som «AI infrastructure engineer», «agent platform engineer», eller bare «senior backend engineer, AI systems». Behandle dette som en kompetanse å bygge og beskrive nøyaktig, ikke en tittel å søke etter på LinkedIn.