Opgavestyring for AI-agenter: claim-løkken som kontrakt, ikke som prompt

Opgavestyring for AI-agenter virker, når tavlen og ikke prompten ejer løkken: agenten spørger, hvad den skal lave, gør krav på én opgave med en lease, der udløber, hvis den bliver stille, spørger kun mennesket om beslutninger, der er menneskets, og afslutter med en kvittering, som nogen kan tjekke. I Weft er hvert af de skridt et MCP-værktøj, som serveren kontrollerer, så en agent, der springer et skridt over, får afslag eller mister opgaven i stedet for stille og roligt at glide ud af trit.

Vi laver Weft. Fakta om andre produkter kommer fra deres officielle sider, tjekket 27. oktober 2026.

Hvorfor holder en opgaveliste indsat i chatten op med at virke?

At indsætte opgaver i en chat er det første, alle prøver, og det virker en eftermiddag. Så slutter chatten, og tilstanden slutter med den. Agenten vidste, hvilket punkt den var færdig med, hvilket den opgav, og hvad den var usikker på. Nu er der ingen, der ved det.

Den, der indsatte listen, bliver mellemmand, kopierer resultater tilbage til den rigtige tavle og laver arbejde om, som en anden session tog, fordi intet sagde, at det var taget.

Adgang til tavlen løser problemet med øjebliksbilledet, ikke resten. Er de eneste værktøjer „flyt kort“ og „tilføj kommentar“, afhænger løkken stadig af, at agenten følger en konvention skrevet i dens instruktioner. Konventioner bryder sammen præcis, når noget går galt: agenten går ned midt i en kørsel, eller to agenter starter i samme øjeblik.

Hvordan ser claim-løkken ud som kontrakt?

I Weft har løkken fem skridt, og hvert er et separat værktøj på ét MCP-endpoint, https://letsweft.com/api/mcp. Serveren holder tilstanden mellem dem, så løkken overlever, at en chat slutter.

1. get_my_work: spørg, før du vælger. Svaret dækker, hvad denne klient allerede har, hvad der venter på mennesket, hvad der er forsinket eller snart forfalder, og om der overhovedet er plads til at starte noget.
2. start_task: gør krav med en lease. Kravet holder i 20 minutter og flytter opgaven til Doing. Svaret indeholder et runId, et leaseToken og renewEverySeconds: 300. En anden klient, der prøver den samme opgave, får already_claimed og et hint om ikke at lave arbejdet to gange.
3. report_progress: livstegnet. Hvert kald med kørslens id og lease-token fornyer leasen. Dør agenten, stopper livstegnene, og 20 minutter senere markeres kørslen som forældet, og opgaven går tilbage til ikke-tildelt, så alle kan tage den. En mistet lease svarer lease_lost, så agenten ved, at den ikke længere ejer arbejdet.
4. request_input: kun til beslutninger, der er menneskets. Et spørgsmål på op til 500 tegn med op til 10 valgmuligheder. Kravet bevares, mens agenten venter.
5. complete_task: afslut med en kvittering. outcome, artifacts (dokumentation som en URL, et commit eller en fil-hash), notDone, unknowns og nextStep.

Hvorfor en lease og ikke en status? Fordi stilhed er det eneste signal, en agent, der er gået ned, kan sende. Et kort i Doing siger, at nogen engang arbejdede på det. En lease siger, at nogen arbejder på det nu, og holder selv op med at sige det, når det ikke længere er sandt.

Selve kravet er én indsættelse i databasen beskyttet af et unikt indeks. Når to agenter kappes, afgør databasen, hvem der vinder, så begge kan ikke få opgaven. To „Taget“-kommentarer skrevet med et sekunds mellemrum er derimod begge gyldige kommentarer.

Hvornår skal agenten kalde request_input?

Når den når noget, kun mennesket kan afgøre: alt, der ikke kan gøres om, som penge, udgivelse, produktion eller jura, eller en reel skillevej uden en fornuftig standard. Ikke for at spørge om lov til at fortsætte.

Den tilbageholdenhed betyder noget, fordi et spørgsmål koster mennesket den samme opmærksomhed som en færdig opgave, og i Weft tæller det mod den samme grænse. Spørgsmålet lander i Inbox med en push-besked på mobilen og, for punkter, der har ventet 20 minutter eller mere, en påmindelse på e-mail. Weft kalder aldrig agenten tilbage: svaret kommer ved dens næste start_task eller get_my_work. Mens spørgsmålet er åbent, beholder agenten opgaven i 60 minutter; derefter falder leasen, men spørgsmålet bliver.

Hvad skal med i et complete_task-kald?

Et kort resultat, dokumentation og en ærlig beretning om kanterne. Her er en realistisk payload for en fejlrettelse:

{
  "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 er ting, mennesket kan tjekke uden at tage agenten på ordet. notDone og unknowns er ikke tilståelser; de skiller et resultat, du kan stole på, fra et, du må genopbygge ud fra diffen. Kaldet fejler aldrig på grund af manglende dokumentation, for at miste færdigt arbejde er værre end at registrere det uverificeret. Mere om at læse disse kvitteringer i hvad lavede min AI-agent.

Hvordan adskiller det sig fra at flytte et kort og skrive en kommentar?

Hypertasks guide til den samme løkke (gør krav, opdatér, rapportér, luk) er en god beskrivelse af vanen. Dens MCP-version af et krav er at indlæse opgaven, flytte den til arbejdssektionen og skrive en krav-kommentar, styret af en prompt, som teamet skriver ind i agentens instruktioner. Her er den samme løkke skridt for skridt:

For at være fair over for Hypertask: den har rigtige leases. Dens dokumentation lister endpoints til at gøre krav på, sende livstegn for og frigive en lease, og dens tabel over kendte begrænsninger siger, at opgave-leases, dokumentation og eskalering kun er REST-endpoints, by design (Hypertask MCP-oversigt). Dens værktøjsreference har intet lease-værktøj blandt sine 21 MCP-værktøjer (værktøjsreference). Dens CLI kan også gøre krav, som en valgfri kommando (changelog, CLI-reference). Så en scriptet agent på Hypertask kan have en lease; en agent, der arbejder via MCP i Claude Code eller Cursor, får kort-og-kommentar-versionen, medmindre nogen kobler REST-kaldene på.

Kører dine agenter som scripts og CI-jobs, er Hypertasks CLI og REST API en reel fordel, og Weft har ingen af dem: ingen CLI, intet offentligt REST API, ingen webhooks. Weft er til agenter, der bor inde i en MCP-klient og har brug for, at løkken holder dér.

Hvad ser mennesket?

For det meste et kort i Done: som standard går en afsluttet opgave direkte derhen med resultat og dokumentation vedhæftet.

En opgave stopper i menneskets Inbox, når den er markeret som en, der skal gennemgås, eller når en verifikation fejler. Dér vælger mennesket ét af fire svar:

• Godkend: arbejdet står ved magt. Har agenten givet et nextStep, ser mennesket det over knappen („Hvis du godkender, vil agenten …“), og godkendelsen gælder præcis det skridt, intet bredere. Godkendelsen gælder i 72 timer og vender tilbage til agenten via get_my_work eller start_task.
• Omarbejd: send det tilbage med en note om, hvad der er galt.
• Senere: ikke nu. Drop: hold op med at arbejde på det.

Inbox findes på nettet, og når noget lander dér, får mennesket også en push-besked i Wefts mobilapp. nextStep-håndtrykket forhindrer en agent i at tage „ser fint ud“ som tilladelse til at merge, deploye og sende: den må udføre det ene godkendte skridt og så afslutte opgaven igen.

Hvorfor får agenten afslag i stedet for at starte mere arbejde?

Fordi opmærksomhed, ikke arbejde, er den knappe ressource. En agent kan starte ti ting i den tid, det tager et menneske at gennemgå én.

Weft tæller, hvad der venter på mennesker: opgaver, der venter på gennemgang, plus åbne spørgsmål. Når det når 5 punkter i et arbejdsområde med én person, 10 i et team eller omkring 45 minutters anslået gennemgangstid, alt efter hvad der kommer først, afviser start_task med attention_queue_full. Grænsen afhænger af, hvor mange mennesker der er i arbejdsområdet, ikke af planen.

Afslaget er en instruktion, ikke en blindgyde. Det oplyser køens størrelse, alderen på det ældste punkt og de kald, der stadig er tilladt: report_progress, get_my_work, get_board_state og search. Et skridt, mennesket allerede har godkendt på det kort, er undtaget, så et godkendt „merge PR #418“ blokeres ikke af køen.

Hvordan sætter jeg det op?

Forbind din klient, og log ind gennem browseren; der er ingen nøgle at kopiere. Weft udsteder refresh tokens, så klienten fornyer selv login. I Claude Code er det én kommando, claude mcp add --transport http weft https://letsweft.com/api/mcp (opsætningsside). Cursor har installation med ét klik (Cursor), Codex kræver en konfigurationspost og codex mcp login weft (Codex), og ChatGPT har en udgivet Weft-app på alle planer, også Free (ChatGPT). Serveren beskriver selv løkken for agenten, så der er ikke brug for nogen livscyklus-prompt.

En gennemgang til Claude Code finder du i en opgavetavle til Claude Code. For flere agenter på én tavle, hvor leases og already_claimed betyder mest, se flere AI-agenter, én tavle. Selve protokollen er dokumenteret på modelcontextprotocol.io, og andre MCP-tavler sammenlignes under MCP-opgavestyring.

Hvad gør Weft ikke her?

• Ingen CLI, intet offentligt REST API og ingen webhooks, så cron-jobs og CI-pipelines kan ikke drive løkken uden for en MCP-klient.
• Ingen GitHub- eller Slack-integration. Dokumentationen er det, agenten linker til i artifacts.
• Ingen indbygget AI. Tænkningen sker i din egen AI-klient, og det er også derfor, Weft ikke kræver AI-kreditter.

Free dækker 50 opgaver og 200 AI-kald om måneden. Pro koster 8,13 € pr. plads om måneden eller 68,75 € pr. plads om året (priser).

Er en god prompt ikke nok til at få agenterne til at følge løkken?

En prompt beskriver løkken; den kan ikke håndhæve den. Den forhindrer ikke to agenter i at gøre krav på den samme opgave, og den kan ikke frigive en opgave, som en agent, der er gået ned, holder fast i. I Weft er kravet en lease, som serveren ejer, så de tilfælde håndteres, uanset om agenten huskede sine instruktioner.

Hvad sker der, hvis min agent går ned halvvejs?

Dens livstegn stopper. Tyve minutter efter det sidste report_progress markeres kørslen som forældet, lease-tokenet ryddes, og opgaven er ikke-tildelt igen, så en anden agent eller et menneske kan tage den. Kortet bliver ikke liggende i Doing i en uge.

Venter hver færdig opgave på, at jeg gennemgår den?

Nej. Som standard går en afsluttet opgave direkte til Done med resultat og dokumentation. Den stopper kun i din Inbox til Godkend, Omarbejd, Senere eller Drop, når opgaven skal gennemgås, eller en verifikation fejler.

Hvorfor skulle jeg ønske, at min agent får afslag på arbejde?

Fordi den ellers bliver ved med at producere ting, du ikke har tid til at tjekke. Når 5 punkter (10 for et team) eller omkring 45 minutters gennemgang venter på mennesker, returnerer start_task attention_queue_full og peger agenten mod det, den stadig kan gøre. At rydde køen åbner igen.

Hypertask har også leases. Hvorfor betyder MCP noget?

Hypertasks leases er REST-endpoints ifølge dens egen dokumentation (MCP-oversigt), og dens CLI kan også gøre krav. Det passer til scriptede agenter. En agent, der arbejder via MCP-værktøjer i en editor eller en chat, får dem ikke dér, og i Weft gør den: start_task, report_progress og complete_task er MCP-værktøjer.