Blog

Què ha fet el meu agent d'IA? Quatre preguntes que s'han de respondre amb proves

Per a cada tasca d'un agent d'IA hauries de veure qui l'ha feta, què ha canviat, què s'ha saltat i per què, amb proves que puguis comprovar en lloc d'un comentari que digui «fet».

Weft és el gestor de tasques amb IA per a fundadors en solitari i equips petits.

Tots els articles

Per Andrei Finogeev ·

Per saber què ha fet el teu agent d'IA, no comencis pel seu resum. Comprova quatre coses: quina connexió ha fet la feina, què ha canviat (demostrat amb alguna cosa que puguis obrir tu mateix), què ha quedat per fer i què s'ha decidit i per què. Si alguna de les quatre es basa només en la paraula de l'agent, tens una narració, no un registre.

Weft és nostre. Les dades sobre altres productes provenen de les seves pàgines oficials, consultades el 27 d'octubre de 2026.

Per què no n'hi ha prou amb un comentari que digui «fet»?

Un comentari és l'agent descrivint la seva pròpia feina. Pot ser perfectament exacte, però el comentari no ho pot demostrar, perquè l'autor és precisament qui intentes comprovar. Saber que un agent ha tocat una tasca respon el qui. No respon si la feina és el que et penses.

L'article de Hypertask sobre l'atribució de la feina feta per IA té raó en una cosa: la feina dels agents hauria d'anar al mateix tauler que la feina de les persones, no a un registre de terminal que no llegeix ningú. Hypertask també dona als agents una identitat pròpia com a comptes de servei, de manera que les escriptures s'atribueixen a l'agent i no a tu, i té proves de tasca i arrendaments, tot i que la seva documentació diu que són només endpoints REST, no eines MCP, per disseny. On discrepem és en què ha de contenir el registre. Un fil de comentaris amb la sortida de l'agent és un registre del que ha dit l'agent. Nosaltres volem que el registre contingui proves.

En aquesta guia no hi ha xifres d'enquestes. Pots provar les quatre preguntes al teu propi tauler aquesta mateixa tarda, i això et dirà més que una mitjana del sector.

Quines són les quatre preguntes?

Tria qualsevol tasca que un agent hagi acabat la setmana passada. Hauries de poder respondre cadascuna d'aquestes preguntes en menys d'un minut sense preguntar-ho a l'agent ni obrir el seu xat:

  1. Qui ho ha fet? Quin client, amb quina connexió, ha reclamat i acabat la tasca.
  2. Què ha canviat? El resultat, més artefactes que puguis comprovar sense refiar-te de l'agent: un hash de commit, un URL, un fitxer, un identificador de missatge.
  3. Què no s'ha fet? Les parts que s'ha saltat i les coses de què no estava segur.
  4. Què s'ha decidit, i per què? Qualsevol decisió presa pel camí, amb les opcions que s'han sospesat, i cada vegada que has tornat la feina enrere.
PreguntaResposta feble: un comentari que diu «fet»Resposta sòlida: proves que pots comprovar
Qui ho ha fet?«Agent» o el teu propi nom en cada canvi, perquè totes les eines comparteixen una mateixa clauLa connexió que ha reclamat i acabat la tasca, amb el nom que el client ha registrat, i cada esdeveniment del registre etiquetat com a persona o MCP amb l'identificador del client
Què ha canviat?«He refactoritzat el mòdul d'autenticació, els tests passen»Un hash de commit, l'URL d'una PR o d'una pàgina, un fitxer amb el seu sha256, un identificador de missatge: alguna cosa que obres tu mateix
Què no s'ha fet?No es diu res, així que suposes que no s'ha saltat resUna llista notDone («no he executat la migració a staging») i una llista unknowns («no estic segur que l'endpoint antic no tingui altres crides»)
Què s'ha decidit, i per què?Enterrat en un xat que fa estona que ha quedat amunt de totUn registre de decisió amb les opcions sospesades i la condició per revisar-la, més l'historial de decisions de la tasca, incloent-hi per què es va tornar enrere

Com sé quin agent ho ha fet?

Weft es connecta als clients d'IA a través del Model Context Protocol en un sol endpoint, https://letsweft.com/api/mcp. Cada client OAuth i cada token d'accés personal és un actor diferent. Una tasca registra quin client l'ha creada, i el tauler mostra el nom amb què el client es va registrar en iniciar sessió, més una icona. Cada esdeveniment del registre de la tasca desa si prové d'una persona o de MCP, i quin client l'ha enviat.

El registre complet (get_task_history en mode full) mostra l'identificador de client en brut de cada esdeveniment: un identificador de client OAuth, o mcp-token seguit de l'identificador del token. No és un nom amigable, però és exacte, i distingeix dues connexions fins i tot quan provenen del mateix producte.

La propietat durant la feina també és explícita. Un agent crida start_task, que reclama la tasca amb un arrendament de 20 minuts i la mou a Doing. report_progress renova l'arrendament. Un segon agent que provi d'agafar la mateixa tasca rep already_claimed, i un arrendament que caduca allibera la tasca per a algú altre. La guia del cicle de reclamació ho explica pas a pas, i diversos agents en un mateix tauler tracta el cas de diversos clients.

Una norma pràctica: dona a cada eina la seva pròpia connexió. Si dos clients comparteixen un token d'accés, el tauler veu un sol actor, i la pregunta del qui es queda sense resposta.

Què ha canviat, i ho puc comprovar sense preguntar-ho a l'agent?

Quan un agent acaba, crida complete_task. Només és obligatori l'identificador de la tasca; tota la resta és opcional, i la crida no falla mai per falta de proves. És expressament així: perdre feina acabada és pitjor que registrar-la sense verificar. Això és el que pot contenir un comprovant:

  • outcome: fins a 1.000 caràcters sobre què s'ha fet i on és el resultat.
  • artifacts: fins a 20 entrades, cadascuna amb un tipus (url, file, message, commit, etc.), una ubicació i, opcionalment, un resum sha256.
  • claims: el que l'agent afirma que ha fet, desat com a afirmacions i no com a fets verificats.
  • notDone i unknowns: els tractem a la secció següent.
  • nextStep: què faria l'agent a continuació si ho acceptes.
complete_task({
  "id": "<task id>",
  "runId": "<from start_task>",
  "leaseToken": "<from start_task>",
  "outcome": "Rate limiting added to /login; PR open, not merged.",
  "artifacts": [
    { "kind": "commit", "uri": "<repo>/commit/<hash>" },
    { "kind": "url", "uri": "<repo>/pull/<number>" }
  ],
  "notDone": ["Did not change the signup endpoint"],
  "unknowns": ["Limit of 5 per minute is a guess; no traffic data"],
  "nextStep": "Merge the PR to main"
})

La línia del resultat continua sent una narració. Els artefactes són la part que pots comprovar. Un hash de commit o existeix al teu repositori o no hi existeix. Un URL carrega o no carrega. El sha256 d'un fitxer coincideix o no coincideix. Si un comprovant té resultat però cap artefacte, tracta'l com a feina declarada per l'agent, perquè és exactament això. Al web, les targetes de Done mostren si una tasca és Verified o Agent-reported.

Què no ha fet l'agent?

Aquesta és la pregunta que la majoria de registres se salten, i la que et mossega dues setmanes després. complete_task hi dedica dues llistes, cadascuna de fins a 20 entrades de 500 caràcters: notDone per al que l'agent ha deixat fora expressament i unknowns per al que no té clar. La mateixa descripció de l'eina demana als agents que diguin en veu alta què no han fet. Això és el que separa un resultat del qual et pots refiar d'un que has de tornar a deduir.

Llegeix aquestes llistes primer. «No he executat els tests contra la base de dades de staging» canvia el que faràs a continuació. Un comprovant sense cap entrada a notDone en una tasca gran ja és, en si mateix, motiu per fer una pregunta.

Què s'ha decidit, i per què?

Les decisions preses al xat desapareixen quan el xat avança. record_decision les conserva de dues maneres:

  • Un registre de decisió independent: un títol, el resultat, el context, les opcions que realment s'han sospesat, les conseqüències i la condició en què cal revisar-la. Els registres són immutables; per canviar-ne un, es registra una decisió nova que el substitueix, i l'antic es manté, marcat com a substituït.
  • Una transmissió de veredicte: quan dius a un agent en una conversa «acceptat», «torna-ho a fer amb X», «descarta-ho» o «ara no», registra aquest veredicte a la tasca, amb la teva nota.

get_task_history ho torna a llegir en tres modes: summary (la targeta, el seu últim comprovant i els recomptes), decisions (totes les decisions sobre la tasca, incloent-hi per què es va tornar enrere, cosa que es manté fins i tot després d'una acceptació posterior) i full (el registre en brut, amb un màxim de 100 esdeveniments). get_context passa les decisions vigents al següent agent dins d'un pressupost de tokens, de manera que la següent execució comença a partir del que s'ha decidit i no de zero. Més informació a per què es perden les decisions dels xats amb IA.

On ho reviso, i on faig clic?

Per defecte, una tasca completada va directament a Done. S'atura a la teva safata d'entrada quan la tasca necessita revisió o quan falla una comprovació de verificació. Allà hi veus el comprovant i quatre botons: Accept, Rework, Later i Drop. Rework demana una nota, i aquesta nota torna a l'agent.

Si l'agent ha indicat un nextStep, apareix damunt del botó Accept, i acceptar aprova exactament aquell pas. L'aprovació és vàlida durant 72 hores i torna a l'agent a través de get_my_work o start_task com l'únic pas que ha de fer a continuació. Les preguntes que un agent fa amb request_input arriben a la mateixa safata d'entrada, al web i a les aplicacions d'iOS i Android, amb una notificació push al mòbil.

La safata d'entrada té un límit expressament: 5 elements pendents en un espai de treball d'una persona, 10 en un d'equip, o 45 minuts de temps de revisió estimat, el que arribi primer. Quan és plena, start_task es nega amb attention_queue_full, de manera que els agents acaben o aclareixen la feina en lloc d'apilar-te'n més per revisar.

Quines proves hauria de demanar segons el tipus de tasca?

Escriu-les a la descripció de la tasca perquè l'agent sàpiga quines proves esperes:

  • Codi: el hash del commit i l'URL de la PR com a artefactes. notDone hauria d'indicar els tests que no s'han executat, les migracions que no s'han aplicat i els fitxers que s'han deixat expressament sense tocar.
  • Contingut: l'URL publicat, o el fitxer de l'esborrany amb el seu sha256 si encara no és en línia. unknowns hauria de llistar les dades que l'agent no ha pogut confirmar.
  • Recerca: un URL de font per a cada afirmació clau, i el fitxer de notes. unknowns hauria de separar el que diu una font del que ha deduït l'agent.
  • Prospecció: l'identificador de cada missatge enviat i la llista de destinataris com a fitxer. notDone hauria de llistar a qui no s'ha contactat i per què.

Com controlo, d'entrada, què pot fer un agent?

L'atribució a posteriori funciona millor amb límits previs. A Weft, cada connexió OAuth té un de tres nivells de permís, que es defineix a la pantalla de consentiment o més endavant a Settings, Connected AI clients:

  • full (per defecte): les 32 eines.
  • write: tot excepte les tres eines destructives (trash_task, archive_done_tasks, complete_sprint).
  • read: només les 11 eines de lectura.

La comprovació es fa a cada crida. Disconnect revoca els tokens de renovació de la connexió i rebutja, a la crida següent, qualsevol token emès abans del tall. Els tokens d'accés personal, per a clients sense OAuth, no tenen àmbits: un sol token arriba a les 32 eines, i revocar-lo té efecte a la crida següent. Els agents poden moure tasques a una paperera de 30 dies però no les poden eliminar definitivament; restaurar des de la paperera és una funció de Pro.

Què no fa Weft en aquest cas?

  • No té integració amb GitHub ni Slack, així que Weft no et busca els commits ni els missatges. L'artefacte l'obres tu.
  • No té API REST pública, webhooks ni CLI per enviar comprovants a altres sistemes. Hi ha una exportació en JSON i Markdown.
  • No fa el seguiment dels passos del model. Les eines que registren instruccions, tokens i latència a la capa del model fan una altra feina, i potser també en vols una.
  • Els agents escriuen els seus propis comprovants. Weft fa visible la diferència entre afirmació i prova; no pot fer que un agent sigui honest.

Si vols gestionar els agents com a comptes de servei a través d'una API REST, una CLI per a scripts de CI o funcions d'IA integrades com la redacció de tasques i el triatge, Hypertask hi encaixa millor. La nostra pàgina alternativa a Hypertask compara tots dos productes un al costat de l'altre.

No n'hi ha prou amb l'historial de git per saber què ha fet el meu agent?
Git mostra què ha canviat al codi. No mostra què s'ha saltat l'agent, de què no estava segur ni quina opció ha triat entre dues. Fes servir el hash del commit com a artefacte a la tasca, i guarda la resta al comprovant i al registre de decisió.
Un agent no es pot inventar un artefacte?
Pot enviar qualsevol cadena de text. La gràcia d'un artefacte és que el pots obrir: un hash que pots buscar, un URL que pots carregar, un identificador de missatge que pots trobar. Un d'inventat falla en el moment que el comproves, cosa que un comentari no fa mai. Quan una tasca té una comprovació de verificació i una comprovació bloquejant falla, la tasca no entra a Done.
Totes les tasques acabades esperen la meva revisió?
No. Per defecte, una tasca completada va a Done. Només espera a la teva safata d'entrada perquè triïs Accept, Rework, Later o Drop quan la tasca necessita revisió o falla una comprovació de verificació.
Quins clients d'IA poden escriure comprovants a Weft?
Qualsevol client MCP. ChatGPT té Weft com a plugin publicat en tots els plans, inclòs el Free. Claude Code es connecta amb claude mcp add --transport http weft https://letsweft.com/api/mcp. Claude.ai i Claude Desktop fan servir un connector personalitzat. Hi ha pàgines de configuració per a 33 clients, com ara Claude Code, ChatGPT, Cursor i Codex.
Quant costa?
El pla Free inclou 50 tasques i 200 crides d'IA al mes. Pro costa 7,87 € per persona al mes o 66,55 € per persona l'any. Weft no té crèdits d'IA: el raonament passa al teu propi client d'IA. Consulta els preus.