Hermes Agent kan nu delegere arbejde uden at fryse samtalen. Nous Research har rullet en opdatering ud, der gør subagents asynkrone. Ifølge annonceringen kan forældreagenten fortsætte dialogen, mens delegerede opgaver kører i baggrunden. Eksisterende brugere får funktionen via en enkel opgradering fra kommandolinjen.
Opdateringen blev offentliggjort på X af Nous Research og medstifteren Teknium 15. juni 2026. Kodeændringen er lille; effekten på praksis er stor for teams, der har kæmpet med lange værktøjskald og låste chats.
Hvad der skete
Hermes’ delegate-værktøj kan nu køre subagents asynkront. Delegation blokerer ikke længere forældrechatten, og en ny værktøjspakke håndterer hele livscyklussen for baggrundstasks. Du kan opgradere eksisterende installationer med kommandoen hermes update. Mekanikken er simpel: en baggrundsagent starter, returnerer et task-id med det samme, og resten kan styres uden at stoppe dialogen.
I agent-UI’er er ventetid den stille dræber. Når chatten låser, mister brugeren både overblik og mulighed for at justere kursen midt i et langt løb. Asynkron delegation adresserer netop det.
Hvad er en subagent i Hermes
I Hermes starter forældreagenten en subagent via delegate_task. Barnet får sin egen samtale, sin egen terminalsession og sit eget værktøjssæt. Isolationen er skarp: forælderen ser ikke mellemregninger eller værktøjskald fra barnet – kun den endelige opsummering kommer tilbage. Det holder forælderens kontekst lille og stabil.
Subagents starter uden historik. Al nødvendig information gives eksplicit gennem felterne goal og context. Det gør dataflowet kontrollerbart og mindsker risikoen for utilsigtet læk af historik eller irrelevante hints.
Hvad var problemet før
Før opdateringen var delegate_task synkron. Forælderen sad fast i værktøjskaldet, indtil hvert barn var færdigt. Brugeren så en frossen chat. Det begrænsede lange køringer, status-tjek undervejs og styring mid-flight.
Konsekvensen var arkitektonisk: man endte med at over-optimere prompts eller bygge udenom med egne køer og polling. Den asynkrone bane fjerner en del af den speciallogik.
Hvad ændrer async_delegation
MarkTechPost beskriver nyheden under issue nummer 5586. En baggrundsagent spændes op, et task_id returneres straks, og et sæt kontroller styrer status, kurs og afrunding. Kaldet ligner synkron delegation, men opfører sig ikke-blokerende.
Værktøjerne dækker hele rejsen:
- delegate_task_async – starter en baggrundsagent, returnerer task_id med det samme
- check_task – ikke-blokerende status og seneste output
- steer_task – injicer en besked i en kørende task
- collect_task – blokér indtil færdig, og hent resultatet
- cancel_task – stop en kørende task
- list_tasks – oversigt over alle asynkrone tasks i sessionen
Baggrundsagenter kører som tråde i samme proces. De genbruger den samme AIAgent-motor, credential-pool og værktøjssæt som ved synkron delegation. Det gør integrationen ligetil – med klare arkitekturkonsekvenser.
Isolation, nøgler og routing
Subagents arver forælderens API-nøgle, provider-konfiguration og credential-pool. Det muliggør central key rotation ved rate limits og model-routing via config.yaml – fx at sende underopgaver til billigere eller mere specialiserede modeller.
Isolationen gælder samtale og værktøjer, ikke nødvendigvis ressourcer. Da baggrundsagenter kører som in-process tråde, deler de CPU og RAM med resten af applikationen. Det er hurtigt, men kræver styring af samtidighed og kapacitetsgrænser. Cappen for synkron batch-delegering nævnes i kilden; hvordan mange samtidige asynkrone tråde opfører sig i produktion, er endnu ikke beskrevet i dybden.
Fra blokerende ventetid til løbende styring
Den praktiske forskel: Du kan starte tunge opgaver og blive i samtalen. Tjekke status periodisk. Korrigere halvvejs. Hente delresultater, hvis behovet ændrer sig. Færre mega-prompts – mere løbende styring.
Workflow og arkitektur i praksis
Asynkron delegation åbner nye mønstre:
- Lange job kan køre i baggrunden, mens brugeren eller en overagent arbejder videre.
- Fan-out analyse bliver mere robust, fordi hver gren kan styres eller stoppes individuelt.
- Parallel dataindsamling kan routes til billigere modeller eller specialværktøjer uden at UI’et blokerer.
Det kræver til gengæld bedre observability og logging. Man skal kunne se, hvad hver tråd laver, hvor langt den er, og hvorfor den fejlede. Og når credential-poolen deles, skal governance følge med: hvem må bruge hvad – og hvornår.
Drift og observability
Asynkrone tråde gør systemet mere levende – og sværere at gennemskue, når noget hænger. AWS’ Strands-arbejde peger på automatisk fejldetektion, kategorisering og root cause-analyse på tværs af agentspor. Pointen: det er ikke nok at opdage en fejl; man skal kunne lokalisere og forklare den.
Rådet er at instrumentere de nye livscyklusværktøjer fra dag ét. Log alle delegate_task_async-kald med task_id, starttid og modelrouting. Giv check_task og steer_task meningsfulde spor i loggen. Alert på tasks, der hænger længere end en aftalt SLA. Og hold cost-prioriteterne tæt på, så kørsler ikke løber løbsk sent fredag aften.
Omkostninger og rate limits
Arv af nøgler og provider-konfiguration er både en fordel og en risiko. Fordel, fordi central key rotation og model-routing bliver nemt. Risiko, fordi et ukontrolleret fan-out kan eksplodere forbruget. Styring via config.yaml bliver et reelt ledelsesværktøj, ikke bare en repo-fil.
Næste skridt er cost-awareness i selve agentlogikken: fallback ved rate limits og valg mellem bredde (parallel) og dybde (lag) alt efter budget og SLA.
Sikkerhed og governance
Delte credential-pools gør adgang enkel, men kræver hegnspæle. Afgræns værktøjssæt per subagent. Auditér, hvem der må starte hvilke agenter. Sæt politikker for dataadgang i værktøjskæder, så en web-scraper ikke får adgang til interne dokumenter via arvede nøgler.
Kilderne beskriver credential-arv, men ikke detaljerne for rotation, scoping eller vault-integration. Indtil officielle dokumenter foreligger, bør man antage mindst privilegeret adgang og testet rotation.
Brugsscenarier der flytter sig
Det bliver lettere at:
- køre langvarig research eller dataindsamling med mulighed for spørgsmål undervejs,
- lave fan-out analyser og stoppe irrelevante grene uden at vælte resten,
- genstarte eller styre midt i et løb, hvis input ændrer sig.
Begrænsninger består: Baggrundsagenter er in-process tråde og single-session. De er ikke holdbare på tværs af turns. For cross-turn varighed eller batch-jobs peger omtalen mod ACP-arbejdet; der er ingen fast dato i kilderne.
Risici og ubesvarede spørgsmål
Tre punkter kræver opmærksomhed: Holdbarhed (asynkron er ikke det samme som persistent job-kø; dør processen, dør trådene). Ressourceprofil (RAM/CPU ved mange samtidige baggrundsagenter og performance under tryk). Fejltilstande (baggrundstråde kan fejle stille uden korrekt instrumentation og alarmer).
Kilderne er stort set enige, men der er nuance i holdbarhed: MarkTechPost kalder løsningen single-session, mens ACP omtales som vejen mod cross-turn. Har du behov for holdbare baggrundsopgaver nu, bør du bruge ekstern kø eller job-runner.
Opgradering og tekniske noter
Eksisterende brugere aktiverer funktionen med hermes update som angivet i annonceringen. Verificér altid versionskrav i Hermes’ dokumentation eller changelog, især i låste produktionsmiljøer. Lås dependency-versioner i test og produktion, så en opdatering ikke uforvarende ændrer modelrouting eller credential-håndtering.
Værktøjsnavnene for asynkron delegation er offentliggjort; tjek issue nummer 5586 i repoet for præcis API-signatur, edge cases og fejlmeddelelser før de første POC’er.
Hvad virksomheder bør gøre nu
Start en lille POC og mål tre ting: latens/throughput ved fan-out, cost per task med modelrouting, og pålidelighed ved mid-flight steering. Tallene gør forskellen, når nogen spørger, hvorfor agenterne blev dyrere i uge 32.
Etabler governance og observability: definer værktøjssæt per subagent-type, sæt audit på credential-brug, og byg et let dashboard med aktive tasks, varighed, modelvalg og anslåede omkostninger. Så kan asynkron delegation give værdi uden blinde vinkler.
Implementeringsdetaljer der gør ondt, hvis man springer dem over
Log task_id i alle svar til brugeren, så fejlrapporter kan kobles til en konkret kørsel. Sæt grænser for samtidige asynkrone tasks per bruger eller session. Giv cancel_task en prominent plads i UI’et; det er bedre at stoppe en dårlig kørsel end at vente på en perfekt opsummering.
Indfør timeouts og backoff for check_task, så status-polling ikke bliver en belastning i sig selv. Småt, men vigtigt – især når mange tester funktionen på samme tid.
Blik frem
Brug asynkron delegation til at aflaste brugeren og fordele arbejdet. Dæk af med observability, cost-kontrol og klare adgangsgrænser. Resten finder man først, når det kører i praksis.
