Delegera arbete till agenter

Den här guiden handlar om att få arbete av ditt bord och över till en agent, och om vad som händer när agenter skickar arbete mellan varandra.

Lämna över ett ärende till en agent

Skapa ärendet med en titel och en beskrivning som är tillräckligt precis för att arbeta utifrån.
Sätt dess Tilldelad till agenten, så att ägandet finns dokumenterat.
Öppna (eller skapa) en yta och @-nämn den agenten.
Referera till ärendet med ett #-omnämnande i ditt meddelande — meddelandefältet autokompletterar arbetsytans ärenden — och berätta vad du vill ska göras.

Agenten plockar upp arbetet från samtalet. Dess framsteg strömmar in i den ytan.

Vad agenten får

Ditt meddelande, inklusive ärendereferensen du taggade.
Ytan att arbeta och rapportera i.
En isolerad worktree från arbetsytans länkade repos.
Ytans läge, som är det som styr körningens verktygsyta.

Läget är en egenskap hos ytan, inte hos ärendet — ett ärende har inget läge. En och samma agent kan därför vara i chat i en yta och plan i en annan. Välj det i meddelandefältets lägesväljare (Agent, Plan eller Orkestrera); review sätts av PR-granskningsytor och går inte att välja. Se Lägen.

Kräv ett strukturerat resultat

Ett utdatakontrakt deklareras på dispatchen, inte på ärendet: expected_output_schema plus output_contract_mode (strikt som standard). Agenten uppfyller det genom att anropa submit_output, som validerar nyttolasten mot schemat och avvisar en som inte följer det.

Både den accepterade utdatan och eventuella avvisningar hamnar i agentens körningslogg. Själva ärendets status påverkas inte av detta — ett misslyckat kontrakt gör inte att ärendet misslyckas.

Följ framstegen

Ytan — agenternas live-aktivitet, huvudvyn.
Ärendet — dess status, så som den som flyttar det sätter den.
Observability → Live (/workspaces/<workspace-id>/observability) — den aktuella agentlistan.
Observability → Insikter — körningsloggen, med kostnad och varaktighet.

Det finns ingen instrumentpanelsvy; en arbetsyte-URL utan underliggande sökväg omdirigeras till inkorgen.

Låt agenter delegera till varandra

En agent som stöter på ett delproblem delegerar med MCP-verktyget delegate_task. Det skapar ett barnärende tilldelat en annan agent och — när du skickar parent_ticket_id — registrerar kedjan så att spärrarna kan se den.

Två strukturella spärrar körs alltid vid ärendenas flaskhals, aldrig via promptinstruktioner:

Djupstak — en kedja djupare än 3 hopp avvisas.
Cykeldetektering — ett hopp tillbaka till en agent som redan finns i kedjan avvisas.

När du skickar from_agent_id körs två spärrar till (produktionen tillhandahåller alltid resolverportarna):

Autonomitak — delegatens effektiva nivå i ytan får inte överskrida delegerarens.
Budgetram — delegering debiterar delegerarens återstående hårdstoppsbudget och kan inte skapa mer. Ingen policy, eller en obegränsad policy, passerar.

En vägran är högljudd: verktyget returnerar spärrens skäl ordagrant, så den delegerande agenten ser exakt varför. Fältet delegatedByAgentId registrerar vem som delegerade och bildar ett delegeringsträd.

Detta delegeringsdjupstak på 3 är en annan gräns än den inbyggda harnessens nästningsgräns på 2 för subagenter — den ena begränsar ärenden mellan agenter, den andra begränsar subagenter inom en enda körning.

Sätt flera agenter på ett ärende

Lägg till dem som medarbetare på ärendet (roller: tilldelad, medarbetare, granskare). Det är en personallista — ett register över vilka som är inblandade — och ger ingenting i sig.

För att faktiskt sätta agenter i samma samtal lägger du till dem som deltagare från ytans sidhuvud. De kan då @-nämna varandra där. Se Använd ytor.

Automatiserad ärendeskapning

Ingen nod i pipelinepaletten skapar ärenden, så en pipeline kan inte sprida ut arbete som tilldelade ärenden.

Vägen som faktiskt finns är orkestrering: att godkänna ett förslag skapar ett projekt och ett team, kompilerar förslagets DAG av underärenden till en pipelinemall (ett promptAgent-steg per underärende, inte en Ticket-rad för varje) och startar den körningen. Se Kör en orkestrering.