Uppgiftshantering för AI-agenter: anspråksloopen som ett kontrakt, inte en prompt

Uppgiftshantering för AI-agenter fungerar när tavlan, inte prompten, äger loopen: agenten frågar vad den ska göra, tar en uppgift med en lease som löper ut om den tystnar, frågar personen bara om beslut som är personens, och avslutar med ett kvitto som någon kan kontrollera. I Weft är vart och ett av de stegen ett MCP-verktyg som servern kontrollerar, så en agent som hoppar över ett steg nekas eller förlorar uppgiften i stället för att tyst glida ur synk.

Vi gör Weft. Fakta om andra produkter kommer från deras officiella sidor och kontrollerades den 27 oktober 2026.

Varför slutar en uppgiftslista inklistrad i chatten att fungera?

Att klistra in uppgifter i en chatt är det första alla provar, och det fungerar en eftermiddag. Sedan tar chatten slut, och tillståndet tar slut med den. Agenten visste vilken punkt den hade avslutat, vilken den gav upp och vad den var osäker på. Nu vet ingen det.

Den som klistrade in listan blir stafettlöparen, som kopierar tillbaka resultat till den riktiga tavlan och gör om arbete som en andra session plockade upp eftersom ingenting sa att det var taget.

Åtkomst till tavlan löser problemet med ögonblicksbilden, inte resten. Om de enda verktygen är ”flytta kort” och ”lägg till kommentar” beror loopen fortfarande på att agenten följer en konvention som står i dess instruktioner. Konventioner går sönder precis när något går fel: agenten kraschar mitt i en körning, eller två agenter börjar i samma ögonblick.

Hur ser anspråksloopen ut som ett kontrakt?

I Weft har loopen fem steg, och vart och ett är ett separat verktyg på en och samma MCP-slutpunkt, https://letsweft.com/api/mcp. Servern håller tillståndet mellan dem, så loopen överlever att en chatt tar slut.

1. get_my_work: fråga innan du väljer. Svaret täcker vad den här klienten redan har, vad som väntar på personen, vad som är försenat eller snart ska vara klart, och om det alls finns utrymme att starta något.
2. start_task: ta med en lease. Anspråket gäller i 20 minuter och flyttar uppgiften till Doing. Svaret innehåller ett runId, en leaseToken och renewEverySeconds: 300. En andra klient som försöker ta samma uppgift får already_claimed och en uppmaning att inte göra samma arbete.
3. report_progress: livstecknet. Varje anrop med körnings-id och lease-token förnyar leasen. Om agenten dör upphör livstecknen, och 20 minuter senare markeras körningen som inaktuell och uppgiften blir otilldelad igen så att vem som helst kan ta den. En förlorad lease svarar lease_lost, så att agenten vet att den inte längre äger arbetet.
4. request_input: bara för beslut som är personens. En fråga på upp till 500 tecken, med upp till 10 alternativ. Anspråket behålls medan agenten väntar.
5. complete_task: avsluta med ett kvitto. outcome, artifacts (belägg som en URL, en commit eller en filhash), notDone, unknowns och nextStep.

Varför en lease och inte en status? Därför att tystnad är den enda signal en kraschad agent kan skicka. Ett kort i Doing säger att någon jobbade med det en gång. En lease säger att någon jobbar med det nu, och slutar säga det av sig själv när det inte längre stämmer.

Själva anspråket är en enda databasinsättning som skyddas av ett unikt index. När två agenter tävlar avgör databasen vem som vinner, så båda kan inte få uppgiften. Två kommentarer med ”Taget” som postas med en sekunds mellanrum är däremot båda giltiga kommentarer.

När ska agenten anropa request_input?

När den når något som bara personen kan avgöra: allt som är oåterkalleligt, som pengar, publicering, produktion eller juridik, eller ett verkligt vägval utan rimligt standardval. Inte för att be om lov att fortsätta.

Den återhållsamheten spelar roll eftersom en fråga kostar personen lika mycket uppmärksamhet som en färdig uppgift, och i Weft räknas den mot samma gräns. Frågan hamnar i Inkorgen, med en push-notis i mobilen och, för poster som har väntat i 20 minuter eller mer, en påminnelse via e-post. Weft ringer aldrig tillbaka till agenten: svaret kommer vid dess nästa start_task eller get_my_work. Medan frågan är öppen behåller agenten uppgiften i 60 minuter; därefter släpps leasen men frågan ligger kvar.

Vad ska ingå i ett complete_task-anrop?

Ett kort resultat, belägg och en ärlig redovisning av kanterna. Här är ett realistiskt exempel för en buggfix:

{
  "id": "9b2f6c1e-4d7a-4c3b-8e21-5a0f3d9c7b14",
  "runId": "d41e8a90-2f6b-4e17-9c3a-71b5e0a4c8f2",
  "leaseToken": "lt_3f9a…",
  "outcome": "Fixed the 500 on /api/invoices when the customer has no billing address. Fix is in PR #418; the route now returns 422 with a field error.",
  "artifacts": [
    { "kind": "url", "uri": "https://github.com/acme/app/pull/418" },
    { "kind": "commit", "uri": "a1c9e07" },
    { "kind": "url", "uri": "https://preview-418.acme.dev/api/invoices/health", "httpStatus": 200 }
  ],
  "claims": [
    "Added a test for an empty billing address; the invoices test file passes locally"
  ],
  "notDone": [
    "Did not merge the PR",
    "Did not backfill the 14 invoices that failed last week"
  ],
  "unknowns": [
    "Whether the mobile app shows the 422 message or a generic error"
  ],
  "nextStep": "Merge PR #418 to main"
}

Artefakter är saker som personen kan kontrollera utan att ta agentens ord för det. notDone och unknowns är inga bekännelser; de skiljer ett resultat du kan lita på från ett som du får återskapa ur diffen. Anropet misslyckas aldrig på grund av saknade belägg, eftersom det är värre att förlora färdigt arbete än att registrera det overifierat. Mer om hur man läser de här kvittona i vad gjorde min AI-agent.

Hur skiljer sig det här från att flytta ett kort och skriva en kommentar?

Hypertasks guide till samma loop (ta, uppdatera, rapportera, stäng) är en bra beskrivning av vanan. Deras MCP-version av ett anspråk är att ladda uppgiften, flytta den till arbetssektionen och posta en anspråkskommentar, styrt av en prompt som teamet skriver in i agentens instruktioner. Här är samma loop steg för steg:

För att vara rättvis mot Hypertask: de har verklig leasing. Deras dokumentation listar slutpunkter för att ta, förnya och släppa leases, och tabellen Known limitations säger att leasing av uppgifter, belägg och eskalering bara finns som REST-slutpunkter, med avsikt (Hypertasks MCP-översikt). Deras verktygsreferens har inget lease-verktyg bland de 21 MCP-verktygen (verktygsreferens). Deras CLI kan också ta uppgifter, som ett valfritt kommando (ändringslogg, CLI-referens). En skriptad agent på Hypertask kan alltså hålla en lease; en agent som jobbar via MCP i Claude Code eller Cursor får versionen med kort och kommentar, om inte någon kopplar in REST-anropen.

Om dina agenter körs som skript och CI-jobb är Hypertasks CLI och REST-API en verklig fördel, och Weft har inget av dem: inget CLI, inget publikt REST-API, inga webhooks. Weft är för agenter som lever i en MCP-klient och behöver att loopen håller där.

Vad ser personen?

För det mesta ett kort i Done: som standard går en avslutad uppgift direkt dit med resultat och belägg bifogade.

En uppgift stannar i personens Inkorg när den har markerats som att den behöver granskas, eller när en verifieringskontroll misslyckas. Där väljer personen ett av fyra svar:

• Godkänn: arbetet står sig. Om agenten skickade med ett nextStep ser personen det ovanför knappen (”Om du godkänner kommer agenten att …”), och att godkänna godkänner exakt det steget, inget bredare. Godkännandet gäller i 72 timmar och går tillbaka till agenten via get_my_work eller start_task.
• Omarbeta: skicka tillbaka, med en notering om vad som är fel.
• Senare: inte nu. Slopa: sluta arbeta med den.

Inkorgen finns på webben, och när något hamnar där får personen också en push-notis i Wefts mobilapp. Handslaget kring nextStep hindrar en agent från att tolka ”ser bra ut” som tillstånd att merga, driftsätta och skicka: den får göra det enda godkända steget och sedan avsluta uppgiften igen.

Varför nekas agenten i stället för att starta mer arbete?

För att det är uppmärksamheten, inte arbetet, som är den knappa resursen. En agent kan starta tio saker på den tid det tar en person att granska en.

Weft räknar det som väntar på människor: uppgifter som väntar på granskning plus öppna frågor. När det når 5 poster i en arbetsyta för en person, 10 i ett team, eller ungefär 45 minuters uppskattad granskningstid, det som kommer först, nekar start_task med attention_queue_full. Gränsen beror på hur många personer som finns i arbetsytan, inte på planen.

Nekandet är en instruktion, inte en återvändsgränd. Det rapporterar köns storlek, den äldsta postens ålder och vilka anrop som fortfarande är tillåtna: report_progress, get_my_work, get_board_state och search. Ett steg som personen redan har godkänt på det kortet är undantaget, så ett godkänt ”merga PR #418” blockeras inte av kön.

Hur sätter jag upp det här?

Anslut din klient och logga in via webbläsaren; det finns ingen nyckel att kopiera. Weft utfärdar refresh-token, så klienten förnyar inloggningen själv. I Claude Code är det ett kommando, claude mcp add --transport http weft https://letsweft.com/api/mcp (uppsättningssida). Cursor har installation med ett klick (Cursor), Codex behöver en konfigurationspost och codex mcp login weft (Codex), och ChatGPT har en publicerad Weft-app på alla planer inklusive Free (ChatGPT). Servern beskriver själv loopen för agenten, så ingen livscykelprompt behövs.

För en genomgång i Claude Code, se en uppgiftstavla för Claude Code. För flera agenter på en tavla, där leasing och already_claimed spelar störst roll, se flera AI-agenter, en tavla. Själva protokollet dokumenteras på modelcontextprotocol.io, och andra MCP-tavlor jämförs på MCP-uppgiftshanterare.

Vad gör Weft inte här?

• Inget CLI, publikt REST-API eller webhooks, så cron-jobb och CI-pipelines kan inte driva loopen utanför en MCP-klient.
• Ingen integration med GitHub eller Slack. Belägg är det agenten länkar i artifacts.
• Ingen inbyggd AI. Tänkandet sker i din egen AI-klient, och det är också därför Weft inte behöver några AI-krediter.

Free täcker 50 uppgifter och 200 AI-anrop i månaden. Pro kostar $7 per plats i månaden eller $60 per plats om året (priser).

Räcker det inte med en bra prompt för att få agenter att följa loopen?

En prompt beskriver loopen; den kan inte upprätthålla den. Den hindrar inte två agenter från att ta samma uppgift, och den kan inte frigöra en uppgift som hålls av en agent som har kraschat. I Weft är anspråket en lease som servern äger, så de fallen hanteras oavsett om agenten kom ihåg sina instruktioner eller inte.

Vad händer om min agent kraschar halvvägs?

Dess livstecken upphör. Tjugo minuter efter senaste report_progress markeras körningen som inaktuell, lease-token rensas och uppgiften blir otilldelad igen, så att en annan agent eller en person kan ta den. Kortet blir inte liggande i Doing i en vecka.

Väntar varje färdig uppgift på att jag ska granska den?

Nej. Som standard går en avslutad uppgift direkt till Done med resultat och belägg. Den stannar i din Inkorg för Godkänn, Omarbeta, Senare eller Slopa bara när uppgiften behöver granskas eller en verifieringskontroll misslyckas.

Varför skulle jag vilja att min agent nekas arbete?

För att den annars fortsätter producera saker som du inte har tid att kontrollera. När 5 poster (10 för ett team) eller ungefär 45 minuters granskning väntar på människor returnerar start_task attention_queue_full och pekar agenten mot det den fortfarande kan göra. Att tömma kön låser upp den.

Hypertask har också leasing. Varför spelar MCP roll?

Hypertasks leasing är REST-slutpunkter, enligt deras egen dokumentation (MCP-översikt), och deras CLI kan också ta uppgifter. Det passar skriptade agenter. En agent som jobbar via MCP-verktyg i en editor eller chatt får dem inte där, men i Weft gör den det: start_task, report_progress och complete_task är MCP-verktyg.