Oppgavestyring for KI-agenter: oppgavesløyfen som kontrakt, ikke prompt

Oppgavestyring for KI-agenter fungerer når det er tavla, ikke prompten, som eier sløyfen: agenten spør hva den skal gjøre, tar én oppgave med en leieavtale som løper ut hvis den blir stille, spør personen bare om beslutninger som er personens, og avslutter med en kvittering noen kan sjekke. I Weft er hvert av disse stegene et MCP-verktøy som serveren kontrollerer, så en agent som hopper over et steg, får avslag eller mister oppgaven i stedet for å gli ut av takt i det stille.

Vi lager Weft. Fakta om andre produkter er hentet fra deres offisielle sider, kontrollert 27. oktober 2026.

Hvorfor slutter en oppgaveliste limt inn i chatten å virke?

Å lime oppgaver inn i en chat er det første alle prøver, og det fungerer en ettermiddag. Så tar chatten slutt, og tilstanden tar slutt med den. Agenten visste hvilket punkt den var ferdig med, hvilket den ga opp, og hva den var usikker på. Nå vet ingen det.

Personen som limte inn lista, blir stafettløperen som kopierer resultater tilbake til den ekte tavla og gjør om igjen arbeid som en annen økt tok, fordi ingenting sa at det var tatt.

Tilgang til tavla løser problemet med øyeblikksbildet, ikke resten. Er de eneste verktøyene «flytt kort» og «legg til kommentar», avhenger sløyfen fortsatt av at agenten følger en konvensjon som står i instruksjonene. Konvensjoner bryter sammen akkurat når noe går galt: agenten krasjer midt i en kjøring, eller to agenter starter i samme øyeblikk.

Hvordan ser oppgavesløyfen ut som en kontrakt?

I Weft har sløyfen fem steg, og hvert av dem er et eget verktøy på ett MCP-endepunkt, https://letsweft.com/api/mcp. Serveren holder tilstanden mellom dem, så sløyfen overlever at en chat tar slutt.

1. get_my_work: spør før du velger. Svaret dekker hva denne klienten allerede holder, hva som venter på personen, hva som er forfalt eller snart forfaller, og om det i det hele tatt er plass til å starte noe.
2. start_task: ta oppgaven med en leieavtale. Leieavtalen varer i 20 minutter og flytter oppgaven til Doing. Svaret har med en runId, en leaseToken og renewEverySeconds: 300. En annen klient som prøver den samme oppgaven, får already_claimed og et hint om ikke å gjøre arbeidet to ganger.
3. report_progress: livstegnet. Hvert kall med kjørings-id og leietoken fornyer leieavtalen. Dør agenten, stopper livstegnene, og 20 minutter senere merkes kjøringen som foreldet og oppgaven går tilbake til ikke tildelt, så hvem som helst kan ta den. En tapt leieavtale svarer lease_lost, så agenten vet at den ikke lenger eier arbeidet.
4. request_input: bare for beslutninger som er personens. Et spørsmål på opptil 500 tegn, med opptil 10 alternativer. Agenten beholder oppgaven mens den venter.
5. complete_task: avslutt med en kvittering. outcome, artifacts (bevis som en URL, en commit eller en filhash), notDone, unknowns og nextStep.

Hvorfor en leieavtale og ikke en status? Fordi stillhet er det eneste signalet en agent som har krasjet, kan sende. Et kort i Doing sier at noen jobbet med det en gang. En leieavtale sier at noen jobber med det nå, og slutter å si det av seg selv når det ikke lenger er sant.

Selve det å ta oppgaven er én enkelt innsetting i databasen, beskyttet av en unik indeks. Når to agenter kappes, avgjør databasen hvem som vinner, så begge kan ikke få oppgaven. To «Tatt»-kommentarer postet med ett sekunds mellomrom er derimot begge gyldige kommentarer.

Når bør agenten kalle request_input?

Når den kommer til noe bare personen kan avgjøre: alt som ikke kan angres, som penger, publisering, produksjon eller juss, eller et reelt veivalg uten et rimelig standardvalg. Ikke for å be om lov til å fortsette.

Den tilbakeholdenheten betyr noe fordi et spørsmål koster personen den samme oppmerksomheten som en ferdig oppgave, og i Weft teller det mot den samme grensen. Spørsmålet havner i innboksen, med et push-varsel på mobilen og, for elementer som har ventet i 20 minutter eller mer, en påminnelse på e-post. Weft ringer aldri agenten tilbake: svaret kommer ved neste start_task eller get_my_work. Mens spørsmålet er åpent, beholder agenten oppgaven i 60 minutter; etter det faller leieavtalen bort, men spørsmålet blir stående.

Hva hører hjemme i et complete_task-kall?

Et kort resultat, bevis og en ærlig redegjørelse for kantene. Her er en realistisk payload for en feilretting:

{
  "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 personen kan sjekke uten å ta agenten på ordet. notDone og unknowns er ikke tilståelser; de skiller et resultat du kan stole på, fra et du må bygge opp igjen fra diffen. Kallet feiler aldri på grunn av manglende bevis, fordi det er verre å miste ferdig arbeid enn å registrere det uverifisert. Mer om å lese disse kvitteringene i hva gjorde KI-agenten min.

Hvordan skiller dette seg fra å flytte et kort og skrive en kommentar?

Hypertasks guide til den samme sløyfen (ta, oppdatere, rapportere, lukke) er en god beskrivelse av vanen. MCP-versjonen deres av å ta en oppgave er å laste oppgaven, flytte den til arbeidsseksjonen og skrive en kommentar om at den er tatt, styrt av en prompt teamet skriver inn i agentens instruksjoner. Her er den samme sløyfen steg for steg:

For å være rettferdig mot Hypertask: de har ekte leieavtaler. Dokumentasjonen lister endepunkter for å ta, sende livstegn og frigi leieavtaler, og tabellen over kjente begrensninger sier at leieavtaler på oppgaver, bevis og eskalering bare er REST-endepunkter, med vilje (Hypertasks MCP-oversikt). Verktøyreferansen har ikke noe leieverktøy blant de 21 MCP-verktøyene (verktøyreferanse). CLI-en kan også ta oppgaver, som en valgfri kommando (endringslogg, CLI-referanse). En skriptet agent på Hypertask kan altså holde en leieavtale; en agent som jobber gjennom MCP i Claude Code eller Cursor, får kort-og-kommentar-versjonen med mindre noen kobler inn REST-kallene.

Kjører agentene dine som skript og CI-jobber, er Hypertasks CLI og REST-API en reell fordel, og Weft har ingen av delene: ingen CLI, ikke noe offentlig REST-API, ingen webhooks. Weft er for agenter som bor inne i en MCP-klient og trenger at sløyfen holder der.

Hva ser personen?

Som oftest et kort i Done: som standard går en fullført oppgave rett dit med resultatet og bevisene vedlagt.

En oppgave stopper i personens innboks når den er merket som at den trenger gjennomgang, eller når en verifiseringssjekk feiler. Der velger personen ett av fire svar:

• Godta: arbeidet står seg. Har agenten sendt med et nextStep, ser personen det over knappen («Hvis du godtar, vil agenten …»), og å godta godkjenner akkurat det steget, ikke noe bredere. Godkjenningen gjelder i 72 timer og går tilbake til agenten via get_my_work eller start_task.
• Omarbeid: send det tilbake, med en merknad om hva som er galt.
• Senere: ikke nå. Forkast: slutt å jobbe med det.

Innboksen finnes på nettet, og når noe havner der, får personen også et push-varsel i Weft-mobilappen. Håndtrykket med nextStep hindrer at en agent behandler «ser greit ut» som lov til å merge, deploye og sende: den kan gjøre det ene godkjente steget og så fullføre oppgaven på nytt.

Hvorfor får agenten avslag i stedet for å starte mer arbeid?

Fordi det er oppmerksomhet, ikke arbeid, som er knapphetsressursen. En agent kan starte ti ting på den tiden en person går gjennom én.

Weft teller det som venter på folk: oppgaver som venter på gjennomgang, pluss åpne spørsmål. Når det når 5 elementer i et arbeidsområde for én person, 10 i et team, eller rundt 45 minutter med beregnet gjennomgangstid, det som kommer først, avviser start_task med attention_queue_full. Grensen avhenger av hvor mange personer som er i arbeidsområdet, ikke av planen.

Avslaget er en instruks, ikke en blindvei. Det oppgir køens størrelse, alderen på det eldste elementet og kallene som fortsatt er tillatt: report_progress, get_my_work, get_board_state og search. Et steg personen allerede har godkjent på det kortet, er unntatt, så en godtatt «merge PR #418» blir ikke blokkert av køen.

Hvordan setter jeg opp dette?

Koble til klienten din og logg inn via nettleseren; det er ingen nøkkel å kopiere. Weft utsteder oppdateringstokener, så klienten fornyer innloggingen selv. I Claude Code er det én kommando, claude mcp add --transport http weft https://letsweft.com/api/mcp (oppsettside). Cursor har installasjon med ett klikk (Cursor), Codex trenger en konfigurasjonsoppføring og codex mcp login weft (Codex), og ChatGPT har en publisert Weft-app på alle planer, inkludert Free (ChatGPT). Serveren beskriver selv sløyfen for agenten, så du trenger ingen livssyklusprompt.

For en gjennomgang med Claude Code, se en oppgavetavle for Claude Code. For flere agenter på én tavle, der leieavtaler og already_claimed betyr mest, se flere KI-agenter, én tavle. Selve protokollen er dokumentert på modelcontextprotocol.io, og andre MCP-tavler er sammenlignet på MCP-oppgavestyrere.

Hva gjør ikke Weft her?

• Ingen CLI, ikke noe offentlig REST-API og ingen webhooks, så cron-jobber og CI-pipelines kan ikke drive sløyfen utenfor en MCP-klient.
• Ingen GitHub- eller Slack-integrasjon. Bevis er det agenten lenker til i artifacts.
• Ingen innebygd KI. Tenkingen skjer i din egen KI-klient, og det er også grunnen til at Weft ikke trenger KI-kreditter.

Free dekker 50 oppgaver og 200 KI-kall i måneden. Pro koster 72 kr per plass i måneden eller 620 kr per plass i året (priser).

Holder det ikke med en god prompt for å få agentene til å følge sløyfen?

En prompt beskriver sløyfen; den kan ikke håndheve den. Den hindrer ikke to agenter i å ta den samme oppgaven, og den kan ikke frigjøre en oppgave som holdes av en agent som har krasjet. I Weft er det å ta oppgaven en leieavtale som serveren eier, så de tilfellene håndteres uansett om agenten husket instruksjonene sine.

Hva skjer hvis agenten min krasjer halvveis?

Livstegnene stopper. Tjue minutter etter siste report_progress merkes kjøringen som foreldet, leietokenet slettes og oppgaven er ikke tildelt igjen, så en annen agent eller en person kan ta den. Kortet blir ikke liggende i Doing i en uke.

Venter hver ferdige oppgave på at jeg skal gå gjennom den?

Nei. Som standard går en fullført oppgave rett til Done med resultatet og bevisene. Den stopper i innboksen din for Godta, Omarbeid, Senere eller Forkast bare når oppgaven trenger gjennomgang eller en verifiseringssjekk feiler.

Hvorfor skulle jeg ønske at agenten min får avslag på arbeid?

Fordi den ellers fortsetter å produsere ting du ikke har tid til å sjekke. Så snart 5 elementer (10 for et team) eller rundt 45 minutter med gjennomgang venter på folk, returnerer start_task attention_queue_full og viser agenten hva den fortsatt kan gjøre. Å tømme køen låser den opp.

Hypertask har også leieavtaler. Hvorfor betyr MCP noe?

Hypertasks leieavtaler er REST-endepunkter, ifølge deres egen dokumentasjon (MCP-oversikt), og CLI-en deres kan også ta oppgaver. Det passer skriptede agenter. En agent som jobber gjennom MCP-verktøy i en editor eller en chat, får dem ikke der, og i Weft gjør den det: start_task, report_progress og complete_task er MCP-verktøy.