Under de senaste två åren har karriärråden kring AI-agenter mestadels handlat om att lära sig prompta dem väl. Det är inte längre den knappa kompetensen. Den knappa kompetensen är att bygga den ställning som en agent verkar inom — det som alltmer kallas en harness — och det är tillräckligt specifikt, och tillräckligt svårt, för att det håller på att bli en egen jobbeskrivning snarare än ett sidoansvar för "AI-personen" i ett team.

Den tydligaste offentliga genomgången av vad detta faktiskt innebär kommer från Lenny's Newsletter, som dokumenterar hur produkthanteringsverktyget ChatPRD byggde en harness för att automatiskt felsöka Sentry-buggar. Texten är värd att läsa i sin helhet om du överväger att specialisera dig inom detta, eftersom den lyfter fram en poäng som är lätt att missa: modellen var aldrig flaskhalsen. Teamet använde Claude Agent SDK som grund och lade sedan merparten av sitt ingenjörsarbete på ett skräddarsytt terminalgränssnitt och en uppsättning adaptrar som kopplade agenten till Sentry, Linear, GitHub och Vercel. Det är jobbet, i miniatyr. Fyra system, fyra olika autentiseringsscheman, fyra olika dataformat, och ett gränssnitt som låter en människa observera och ingripa utan att behöva vakta varje steg.

Vad "harness" faktiskt bryts ner i

Om du försöker avgöra om detta är en kompetens värd att bygga upp, hjälper det att dela upp den i delar som anställs för separat, eller åtminstone utvärderas separat i en intervju:

  • Design av behörigheter. Att avgöra vad en agent får göra utan tillsyn (läsa ett ärende, utkasta en PR) jämfört med vad som kräver en människa i loopen (merga, driftsätta, radera, spendera pengar) — och koda detta som faktisk policy i kod, inte som en promptinstruktion som modellen kan ignorera under press. Detta ligger närmare åtkomstkontrollteknik än promptskrivning.
  • Verktygsadaptrar. Tunna, väl testade omslag kring varje externt system (Sentry, Linear, GitHub, Vercel, eller vad ditt företags stack nu består av) som översätter agentens avsikt till ett säkert, validerat API-anrop och översätter svaret tillbaka till något modellen kan resonera kring. Detta är vanlig mjukvaruutveckling — felhantering, återförsök, schemavalidering — tillämpad på en ny konsument.
  • Terminal- eller konsolgränssnitt. Ett sätt för en människa att se vad agenten gör, godkänna eller avvisa åtgärder, och ingripa när den fastnar. ChatPRD byggde ett eget; många team kommer istället att använda färdiga agentkonsoler, men någon måste ändå bestämma vad som visas, vad som döljs, och vad som kräver ett klick innan det sker.
  • Verktygsval i stor skala. En artikel från Machine Learning Mastery pekar på något värt att veta om du bygger något som går utöver en demo: agenters träffsäkerhet vid verktygsanrop tenderar att försämras när verktygskatalogen passerar ungefär ett tiotal alternativ — modellen börjar anropa fel verktyg, hallucinera parametrar, eller fastna på dåliga anrop. Motåtgärderna som listas (att styra vilka verktyg som ens är synliga i en given kontext, sökbaserad verktygsuppslagning, routning till specialiserade underagenter, explicita planeringssteg, reservlogik, och benchmark-harnesses för att fånga regressioner) är i sig en checklista över saker en harness-ingenjör måste kunna implementera, inte bara känna till.
  • Kontext- och minnesteknik. Samma källa gör en åtskillnad värd att ta till sig: kontextteknik (vad som ingår i ett enskilt inferensanrop, och var) och minnesteknik (vad som består mellan sessioner, hur det lagras, hur det hämtas) är olika discipliner med olika typer av felsätt. Dess påstående är att de flesta sammanbrott hos långvariga agenter som körs över flera sessioner går tillbaka till att man blandar ihop de två — att behandla sessionsminne som om det bara vore mer kontext, eller tvärtom — särskilt vid den punkt där systemet bestämmer vad som ska hämtas.

Beviset för att detta är en verklig, finansieringsbar roll — inte bara en hobbynisch

Skeptiker kommer rimligen att fråga om "harness-ingenjör" är ett jobb eller bara en uppgift inom någon annans jobb. Två datapunkter från sammanställningen tyder på att det rör sig mot det förra. För det första använde Microsofts Aspire-team — en grupp på tio personer — GitHubs Agentic Workflows för att automatisera dokumentations-PR:ar över flera repon, och över två releaser mergade de 82 PR:ar med en medianfördröjning på 44,8 timmar efter att motsvarande produkt-PR skeppats, utan ny personal och utan processomskolning. Det är ett litet team som får oproportionerligt stor hävstång specifikt för att någon investerade i ställningen (definitionerna av arbetsflödena, granskningsroutningen, triggerlogiken) istället för att låta ingenjörer skriva dokumentations-PR:ar för hand. För det andra behandlar Microsoft Researchs SkillOpt-projekt agenters "skill"-filer — instruktionerna och begränsningarna som formar hur en agent beter sig i sin harness — som något som ska optimeras systematiskt snarare än redigeras för hand, och rapporterar att det var bäst eller delat bäst i samtliga 52 celler i ett benchmark-rutnät (sex benchmarks, sju modeller, tre körlägen), där de optimerade skills-filerna gick att överföra mellan olika modeller och olika harnesses. Oavsett om just det verktyget blir standard eller inte, signalerar det att branschen börjar behandla harness-konfiguration som en ingenjörsartefakt med egna verktyg och benchmarks — samma utveckling som förvandlade "DevOps" från en samling ad hoc-skript till en disciplin.

Det byggs nu också infrastruktur uttryckligen för detta lager. Googles nyligen tillkännagivna "Managed Agents"-funktioner i Gemini API:et — bakgrunds- och asynkron körning, integration med fjärranslutna MCP-servrar, anpassad funktionsanrop, uppdatering av autentiseringsuppgifter mellan interaktioner — är i praktiken färdigbyggd rörledning för exakt de problem som ChatPRD-teamet löste för hand. Det är ett normalt mönster: det ett team bygger skräddarsytt i år produktifierar en plattformsleverantör nästa år. Det eliminerar inte rollen som harness-ingenjör; det höjer golvet och flyttar jobbet mot att integrera och konfigurera hanterade byggstenar istället för att skriva varje adapter från grunden, ungefär som hur molninfrastruktur inte eliminerade driftsingenjörer utan förändrade vad de lade sin tid på.

Vad detta innebär om du siktar på denna roll

Några konkreta, kontrollerbara saker att sätta i en portfölj eller ett CV om du vill vara trovärdig för det här arbetet: bygg en adapter från början till slut mot ett verkligt API du inte kontrollerar (autentisering, felhantering, hastighetsbegränsningar inkluderat, inte en demo som bara följer den lyckliga vägen); designa och dokumentera en behörighetsmodell för en agent som skiljer på läsa/föreslå/agera-åtgärder och visar varför varje gräns ligger just där den ligger; och bygg eller konfigurera ett granskningsgränssnitt där en människa godkänner agentens åtgärder innan de exekveras, eftersom det är den del de flesta företag kommer att insistera på innan de låter en agent röra vid produktion. Om du utvärderar ett jobberbjudande inom harness-teknik eller avgränsar dina egna ansvarsområden, fråga specifikt vem som äger behörighetsmodellen, vem som äger adaptrarna, och vem som äger ytan för mänsklig granskning — i många team just nu saknar dessa tre saker en tydlig ägare, vilket är precis den lucka som denna roll håller på att bildas för att fylla.

En reservation värd att uttrycka rakt på sak: ingen av källorna ovan fastställer någon siffra för anställningsmarknaden för just denna titel, och "harness-ingenjör" är inte en jobbtitel du kommer att se i annonser ännu — den dyker upp inom titlar som "AI-infrastrukturingenjör", "agentplattformsingenjör", eller helt enkelt "senior backend-ingenjör, AI-system". Betrakta detta som en kompetens att bygga upp och beskriva korrekt, inte en titel att söka efter på LinkedIn.