¿Qué hizo mi agente de IA? Cuatro preguntas que responder con pruebas

Para saber qué hizo tu agente de IA, no empieces por su resumen. Comprueba cuatro cosas: qué conexión hizo el trabajo, qué cambió (demostrado con algo que puedas abrir tú), qué quedó sin hacer y qué se decidió y por qué. Si alguna de las cuatro se apoya solo en la palabra del agente, tienes un relato, no un registro.

Weft lo hacemos nosotros. Los datos sobre otros productos salen de sus páginas oficiales, revisadas el 27 de octubre de 2026.

¿Por qué no basta con un comentario que diga «hecho»?

Un comentario es el agente describiendo su propio trabajo. Puede ser perfectamente exacto, pero el comentario no puede demostrarlo, porque su autor es justo la parte a la que intentas comprobar. Saber que un agente tocó una tarea responde a quién. No responde a si el trabajo es lo que crees que es.

El artículo de Hypertask sobre la atribución del trabajo de la IA plantea algo razonable: el trabajo de los agentes debería acabar en el mismo tablero que el de las personas, no en un log de terminal que nadie lee. Hypertask también da a los agentes su propia identidad como cuentas de servicio, para que los cambios se atribuyan al agente y no a ti, y tiene pruebas de tareas y concesiones, aunque su documentación dice que son solo endpoints REST, no herramientas MCP, por diseño. En lo que diferimos es en qué debería contener el registro. Un hilo de comentarios con la salida del agente es un log de lo que dijo el agente. Nosotros queremos que el registro contenga pruebas.

En esta guía no hay cifras de encuestas. Puedes probar las cuatro preguntas en tu propio tablero esta misma tarde, y eso te dirá más que una media del sector.

¿Cuáles son las cuatro preguntas?

Elige cualquier tarea que un agente terminara la semana pasada. Deberías poder responder a cada una de estas preguntas en menos de un minuto, sin preguntar al agente ni abrir su chat:

1. ¿Quién la hizo? Qué cliente, con qué conexión, reclamó y terminó la tarea.
2. ¿Qué cambió? El resultado, más artefactos que puedes comprobar sin fiarte del agente: un hash de commit, una URL, un archivo, un id de mensaje.
3. ¿Qué no se hizo? Las partes que se saltó y las cosas de las que no estaba seguro.
4. ¿Qué se decidió y por qué? Cualquier elección hecha por el camino, con las opciones que se sopesaron, y cada vez que devolviste el trabajo.

¿Cómo sé qué agente lo hizo?

Weft se conecta a los clientes de IA mediante el Model Context Protocol en un único endpoint, https://letsweft.com/api/mcp. Cada cliente OAuth y cada token de acceso personal es su propio actor. Una tarea registra qué cliente la creó, y el tablero muestra el nombre con el que ese cliente se registró al iniciar sesión, más un icono. Cada evento del historial de la tarea guarda si vino de una persona o por MCP, y qué cliente lo envió.

El historial completo (get_task_history en modo full) muestra el id de cliente en bruto de cada evento: un id de cliente OAuth, o mcp-token seguido del id del token. No es un nombre amigable, pero es exacto, y distingue dos conexiones aunque vengan del mismo producto.

La propiedad durante el trabajo también es explícita. Un agente llama a start_task, que reclama la tarea con una concesión de 20 minutos y la mueve a Doing. report_progress renueva la concesión. Un segundo agente que intente la misma tarea recibe already_claimed, y una concesión que caduca deja la tarea libre para otro. La guía del ciclo de reclamación lo explica paso a paso, y varios agentes en un mismo tablero cubre el caso con varios clientes.

Una regla práctica: dale a cada herramienta su propia conexión. Si dos clientes comparten un token de acceso, el tablero ve un solo actor, y la pregunta de quién se queda sin respuesta.

¿Qué cambió, y puedo comprobarlo sin preguntar al agente?

Cuando un agente termina, llama a complete_task. Solo es obligatorio el id de la tarea; todo lo demás es opcional, y la llamada nunca falla por falta de pruebas. Es deliberado: perder trabajo terminado es peor que registrarlo sin verificar. Esto es lo que puede llevar un recibo:

• outcome: hasta 1.000 caracteres sobre qué se hizo y dónde está el resultado.
• artifacts: hasta 20 entradas, cada una con un tipo (url, file, message, commit, etc.), una ubicación y, opcionalmente, un digest sha256.
• claims: lo que el agente afirma haber hecho, guardado como afirmaciones y no como hechos verificados.
• notDone y unknowns: se tratan en la siguiente sección.
• nextStep: lo que el agente haría a continuación si aceptas.

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ínea del resultado sigue siendo un relato. Los artefactos son la parte que puedes comprobar. Un hash de commit existe en tu repositorio o no existe. Una URL carga o no carga. El sha256 de un archivo coincide o no coincide. Si un recibo tiene resultado y ningún artefacto, trátalo como trabajo según el agente, porque eso es lo que es. En la web, las tarjetas de Done muestran si una tarea está Verificada o es Según el agente.

¿Qué no hizo el agente?

Es la pregunta que se saltan la mayoría de los registros, y la que te muerde dos semanas después. complete_task tiene dos listas para ello, cada una de hasta 20 entradas de 500 caracteres: notDone para lo que el agente dejó fuera a propósito, y unknowns para aquello de lo que no está seguro. La propia descripción de la herramienta pide a los agentes que digan en voz alta lo que no hicieron. Eso es lo que separa un resultado en el que puedes confiar de uno que tienes que volver a deducir.

Lee estas listas primero. «No ejecuté los tests contra la base de datos de staging» cambia lo que haces a continuación. Un recibo sin ninguna entrada en notDone en una tarea grande ya merece una pregunta.

¿Qué se decidió y por qué?

Las decisiones tomadas en el chat desaparecen cuando el chat queda atrás. record_decision las conserva de dos formas:

• Un registro de decisión independiente: un título, el resultado, el contexto, las opciones que de verdad se sopesaron, las consecuencias y la condición bajo la que revisarla. Los registros son inmutables; cambiar uno significa registrar una nueva decisión que lo sustituye, y el antiguo se queda, marcado como sustituido.
• Un relevo de veredicto: cuando le dices a un agente en la conversación «aceptado», «rehazlo con X», «descártalo» o «ahora no», registra ese veredicto en la tarea, con tu nota.

get_task_history lo devuelve en tres modos: summary (la tarjeta, su último recibo y recuentos), decisions (todas las decisiones sobre la tarea, incluido por qué se devolvió, que se conserva incluso tras una aceptación posterior) y full (el historial en bruto, con un máximo de 100 eventos). get_context entrega las decisiones vigentes al siguiente agente dentro de un presupuesto de tokens, así que la siguiente ejecución parte de lo que se decidió y no de cero. Más sobre esto en por qué se pierden las decisiones de los chats con IA.

¿Dónde lo reviso y qué pulso?

Por defecto, una tarea completada va directa a Done. Se para en tu Bandeja de entrada cuando la tarea necesita revisión o cuando falla una comprobación de verificación. Ahí ves el recibo y cuatro botones: Aceptar, Rehacer, Más tarde y Descartar. Rehacer pide una nota, y esa nota vuelve al agente.

Si el agente pasó un nextStep, aparece encima del botón Aceptar, y aceptar aprueba exactamente ese paso. La aprobación vale durante 72 horas y vuelve al agente a través de get_my_work o start_task como el único paso que dar a continuación. Las preguntas que un agente hace con request_input llegan a la misma Bandeja de entrada, en la web y en las apps de iOS y Android, con una notificación push en el móvil.

La Bandeja de entrada tiene un límite a propósito: 5 elementos en espera para un espacio de trabajo de una persona, 10 para un equipo, o 45 minutos de revisión estimada, lo que llegue antes. Cuando está llena, start_task se niega con attention_queue_full, así que los agentes terminan o aclaran trabajo en lugar de amontonar más para que lo revises.

¿Qué pruebas debería pedir según el tipo de tarea?

Escríbelas en la descripción de la tarea para que el agente sepa qué pruebas esperas:

• Código: el hash del commit y la URL de la PR como artefactos. notDone debería nombrar los tests no ejecutados, las migraciones no aplicadas y los archivos que se dejaron sin tocar a propósito.
• Contenido: la URL publicada, o el archivo del borrador con su sha256 si aún no está publicado. unknowns debería enumerar los datos que el agente no pudo confirmar.
• Investigación: una URL de fuente para cada afirmación clave, y el archivo de notas. unknowns debería separar lo que dice una fuente de lo que dedujo el agente.
• Contacto con terceros: el id de cada mensaje enviado, y la lista de destinatarios como archivo. notDone debería enumerar a quién no se contactó y por qué.

¿Cómo controlo de entrada lo que puede hacer un agente?

La atribución a posteriori funciona mejor con límites a priori. En Weft, cada conexión OAuth tiene uno de tres niveles de permisos, que se fija en la pantalla de consentimiento o después en Ajustes, Clientes de IA conectados:

• completo (por defecto): las 32 herramientas.
• escritura: todo menos las tres herramientas destructivas (trash_task, archive_done_tasks, complete_sprint).
• lectura: solo las 11 herramientas de solo lectura.

La comprobación se hace en cada llamada. Desconectar revoca los tokens de actualización de la conexión y rechaza, en su siguiente llamada, cualquier token emitido antes del corte. Los tokens de acceso personales, para clientes sin OAuth, no tienen ámbitos: un token llega a las 32 herramientas, y revocarlo surte efecto en la siguiente llamada. Los agentes pueden mover tareas a una papelera de 30 días, pero no borrarlas definitivamente; restaurar desde la papelera es una función de Pro.

¿Qué no hace Weft aquí?

• No tiene integración con GitHub ni con Slack, así que Weft no busca tus commits ni tus mensajes por ti. El artefacto lo abres tú.
• No tiene API REST pública, ni webhooks, ni CLI para enviar recibos a otros sistemas. Hay exportación a JSON y Markdown.
• No traza los pasos del modelo. Las herramientas que registran prompts, tokens y latencia en la capa del modelo hacen otro trabajo, y puede que también quieras una.
• Los agentes escriben sus propios recibos. Weft hace visible la distancia entre afirmación y prueba; no puede hacer honesto a un agente.

Si quieres agentes gestionados como cuentas de servicio mediante una API REST, una CLI para scripts de CI o funciones de IA integradas como la redacción y el triaje de tareas, Hypertask encaja mejor. Nuestra página alternativa a Hypertask compara los dos lado a lado.

¿No basta con el historial de git para saber qué hizo mi agente?

Git muestra qué cambió en el código. No muestra qué se saltó el agente, de qué no estaba seguro ni qué opción eligió entre dos. Usa el hash del commit como artefacto en la tarea, y deja el resto en el recibo y en el registro de decisión.

¿No puede un agente inventarse un artefacto?

Puede enviar cualquier cadena. La gracia de un artefacto es que puedes abrirlo: un hash que puedes buscar, una URL que puedes cargar, un id de mensaje que puedes encontrar. Uno inventado falla en cuanto lo compruebas, algo que nunca pasa con un comentario. Cuando una tarea lleva una comprobación de verificación y falla una comprobación bloqueante, la tarea no entra en Done.

¿Todas las tareas terminadas esperan a mi revisión?

No. Por defecto, una tarea completada va a Done. Solo espera en tu Bandeja de entrada para Aceptar, Rehacer, Más tarde o Descartar cuando la tarea necesita revisión o falla una comprobación de verificación.

¿Qué clientes de IA pueden escribir recibos en Weft?

Cualquier cliente MCP. ChatGPT tiene Weft como plugin publicado en todos los planes, incluido Free. Claude Code se conecta con claude mcp add --transport http weft https://letsweft.com/api/mcp. Claude.ai y Claude Desktop usan un conector personalizado. Hay páginas de configuración para 33 clientes, como Claude Code, ChatGPT, Cursor y Codex.

¿Cuánto cuesta?

Free cubre 50 tareas y 200 llamadas de IA al mes. Pro cuesta 7,87 € por asiento al mes o 66,55 € por asiento al año, IVA incluido. Weft no tiene créditos de IA: el razonamiento ocurre en tu propio cliente de IA. Consulta los precios.