Por qué se pierden las decisiones tomadas en chats con IA, y dónde guardarlas

Las decisiones tomadas en una conversación con ChatGPT o Claude se pierden porque un chat no tiene estado. Nada en él marca una línea como «esto es lo que decidimos», nada une esa línea al trabajo al que afecta, y un chat nuevo empieza vacío. La solución es que la IA anote la decisión donde vive el trabajo, como un registro breve con sus motivos, y que la siguiente sesión lea esos registros antes de actuar.

Weft lo hacemos nosotros. Los datos sobre otros productos salen de sus páginas oficiales, revisadas el 27 de octubre de 2026. La idea de que un hilo «no tiene estado» viene del artículo de Hypertask sobre los hilos de Slack. Esta guía la aplica a los chats con IA.

¿Por qué desaparecen las decisiones tomadas con ChatGPT o Claude?

Pasas cuarenta minutos con un asistente sopesando dos proveedores de base de datos, dos modelos de precios o dos formas de estructurar una API. Te quedas con una. El razonamiento es bueno, el asistente está de acuerdo y pasas a lo siguiente.

Una semana después, la conclusión sigue en ese chat, en algún punto por encima de otros doscientos mensajes. Un chat nuevo no sabe nada de ella. Un compañero nunca la vio. Y si al día siguiente abres otro cliente de IA, por ejemplo un agente de programación en tu terminal, ese cliente empieza de cero y puede proponerte tan tranquilo la opción que descartaste.

No es un problema de disciplina. Una conversación es una secuencia de mensajes. No tiene un campo de «decidido», ni dueño, ni enlace a una tarea, ni forma de decir «esto sustituye lo que dijimos el martes». Una pregunta decidida y una abandonada se ven igual cuando quedan atrás.

¿No lo resuelve ya la memoria del chat?

No para esto. Muchos asistentes ya pueden recordar cosas sobre ti entre chats, y eso es útil para preferencias y contexto. Pero esa memoria pertenece a un producto y a una cuenta. Está escrita para que la use ese asistente, no como un registro que una persona pueda revisar línea a línea, y otro cliente de IA no puede leerla. Tampoco dice sobre qué tarea era una elección ni qué elección anterior sustituyó.

Un registro de decisiones tiene otros requisitos. Tiene que poder encontrarlo la gente y los agentes que trabajan en el proyecto, tiene que poder leerlo el cliente de IA que coja el trabajo después, tiene que estar unido a ese trabajo y tiene que ser honesto con la historia: cuando una decisión cambia, la antigua debería seguir visible con el motivo por el que se sustituyó.

¿Qué cuenta como una decisión que merece registrarse?

Registra una elección cuando alguien podría razonablemente haber elegido otra cosa y la elección va a condicionar el trabajo posterior. Buenos ejemplos:

• Elegir una herramienta, un proveedor o una librería frente a otra.
• Dejar algo fuera a propósito («este trimestre no hay programa de referidos»).
• Fijar una regla que el trabajo debe seguir («en la UE, todos los precios se muestran con IVA incluido»).
• Cambiar una elección anterior, con el motivo.
• Una lección aprendida a base de golpes («no ejecutar la migración en horario laboral»).

No registres:

• Ideas que lanzaste y no adoptaste.
• Pasos del propio trabajo (eso va en la tarea y en su resultado).
• Nada que la persona aún no haya aceptado, salvo que esté claramente marcado como propuesta.
• Datos que cualquiera puede volver a consultar en un minuto.

Una prueba útil: si una sesión de IA nueva estuviera a punto de deshacer esta elección, ¿querrías que se parase a leer por qué? Si la respuesta es sí, regístrala.

¿Cómo es un buen registro de decisión?

Que sea breve y que conserve los motivos. El formato de abajo es una versión ligera de MADR (Markdown Architectural Decision Records), que es lo que usa la herramienta record_decision de Weft:

Title:        Subida de archivos: almacenamiento de objetos, no la base de datos
Outcome:      Los archivos subidos van al almacenamiento de objetos; la base de
              datos guarda solo la clave del archivo y sus metadatos.
Status:       accepted
Context:      Los usuarios adjuntan archivos de hasta 50 MB. Guardarlos en la
              base de datos haría las copias de seguridad lentas y grandes.
Options:      1. Almacenamiento de objetos  + barato, copias pequeñas
                                            - un servicio más que configurar
              2. Columna en la base de datos + todo en un mismo sitio
                                            - las copias crecen con cada subida
Consequences: Necesitamos URL firmadas para las descargas.
              Borrar una tarea también debe borrar sus archivos.
Revisit when: Necesitemos buscar dentro del contenido de los archivos.
Task:         Subida de archivos

• Title da nombre a la decisión para que puedas encontrarla de un vistazo.
• Outcome es una frase con la que alguien recién llegado puede actuar.
• Context es lo que era cierto en ese momento. Es la parte que antes se borra de la memoria.
• Options enumera solo lo que de verdad se sopesó, no alternativas inventadas a posteriori.
• Consequences incluye los inconvenientes que aceptaste, para que nadie los «descubra» después como bugs.
• Revisit when dice qué haría que la elección fuera incorrecta.

¿Cómo guarda Weft un registro de decisión?

Weft es un tablero de tareas al que tus clientes de IA llegan por MCP en https://letsweft.com/api/mcp. Tres de sus 32 herramientas se ocupan de las decisiones:

• record_decision recibe un título y un resultado, más el contexto, hasta cinco opciones con pros y contras, las consecuencias y la condición bajo la que revisarla. Se puede unir a una tarea (taskId) o a un proyecto. Los registros son inmutables: para cambiar uno, la IA registra una nueva decisión con supersedesId apuntando a la antigua, y el registro antiguo se queda, marcado como sustituido.
• get_context devuelve las decisiones y lecciones vigentes del espacio de trabajo, de la más reciente a la más antigua, ajustadas a un presupuesto de tokens (800 tokens por defecto). Se puede acotar a un proyecto o a una tarea. Cada línea lleva su fecha, una decisión sustituida nunca aparece y las líneas que no cupieron se cuentan en lugar de ocultarse.
• get_task_history en modo decisions enumera todas las decisiones registradas sobre una tarea, incluidos los veredictos de revisión y sus motivos.

record_decision tiene un segundo uso: transmitir un veredicto que la persona dio en la conversación sobre un trabajo pendiente de su revisión (aceptado, rehacer, descartado o pospuesto). La descripción de la herramienta le dice a la IA que aquí es la mensajera, no quien decide, así que nunca debería usarla para aceptar su propio trabajo.

Como los registros nunca se editan en el sitio, la historia sigue siendo honesta. Si cambias de proveedor en marzo, la decisión de enero sigue ahí, marcada como sustituida, y el registro de marzo explica por qué.

¿Cómo le pido a mi IA que registre las decisiones?

Conecta Weft a tu cliente de IA y luego pega una instrucción como esta al principio de un chat, o en las instrucciones personalizadas o el archivo de proyecto del cliente, si lo tiene:

Cuando tomemos una decisión real en este chat (elegimos una opción frente a otra,
dejamos algo fuera o cambiamos una elección anterior), regístrala en Weft con
record_decision antes de seguir:
- title: la decisión, nombrada en pocas palabras
- outcome: la elección en una frase
- context: lo que era cierto y obligó a elegir
- options: solo las opciones que de verdad sopesamos, con pros y contras
- consequences: lo que se deriva, bueno y malo
- confirmation: cuándo deberíamos revisarla
- taskId o project: la tarea o el proyecto al que se refiere
Si cambia una decisión anterior, pasa supersedesId en lugar de editarla.
No registres charla, suposiciones ni cosas que yo no haya aceptado.
Si todavía no me he comprometido, usa el estado "proposed".
Al empezar cualquier trabajo que no sea trivial, llama primero a get_context y dime
qué decisiones anteriores se aplican.

Conectar lleva un minuto. En ChatGPT, Weft es una app publicada en el directorio de plugins, disponible en todos los planes, incluido Free (configuración). En Claude Code es un comando (configuración). Claude.ai y Claude Desktop lo añaden como conector personalizado. El inicio de sesión es OAuth en el navegador, así que no hay clave que copiar, y Weft emite tokens de actualización, así que el cliente renueva la sesión por sí solo. Las páginas de configuración de otros clientes, como Cursor y Codex, están en la documentación.

¿Qué pasa cuando al día siguiente paso de ChatGPT a Claude Code?

Este es el caso para el que está pensada la instrucción.

1. El lunes planificas una funcionalidad en ChatGPT. Decides guardar las subidas en almacenamiento de objetos y no en la base de datos, y ChatGPT llama a record_decision con el contexto, las dos opciones y las consecuencias, unido a la tarea «Subida de archivos».
2. El martes abres Claude Code en el repositorio. Si aún no lo has conectado: claude mcp add --transport http weft https://letsweft.com/api/mcp.
3. Le pides que coja la tarea de las subidas. Antes de escribir código, llama a get_context para esa tarea, o a get_task_history en modo decisions, y recupera el registro del lunes.
4. Construye sobre el almacenamiento de objetos en lugar de reabrir la cuestión. Si encuentra un motivo real por el que la elección es incorrecta, puede proponer una nueva decisión que sustituya a la del lunes, y decides tú.

Los dos clientes leen el mismo tablero y las mismas decisiones, porque el registro vive en Weft, no en ninguno de los chats. Cada conexión OAuth es su propio actor, y el tablero muestra el nombre con el que se registró cada cliente, así que puedes ver qué conexión creó cada tarea. Para usar varios agentes en un mismo tablero sin choques, consulta varios agentes de IA, un tablero.

¿Dónde deberían acabar las decisiones tomadas en ChatGPT?

Cuatro sitios habituales, comparados según lo que necesita un registro de decisiones:

No se trata de que el chat o los documentos sean malos. El chat es donde piensas. La decisión tiene que copiarse del chat a algo con estado en el momento en que se toma, y debe hacerlo quien ya está en la conversación: la IA.

¿Sustituye esto a nuestros documentos o a nuestra wiki?

No. Weft no tiene documentos ni wiki, y no pretende serlo. Las explicaciones largas, las guías de onboarding y los documentos de diseño van en tu herramienta de documentación. Un registro de decisión es pequeño a propósito: una elección, sus motivos y qué la sustituyó. Si tu equipo ya guarda registros de decisiones en una wiki y todos los clientes de IA que usáis pueden leerla, puede que baste. Weft es útil cuando las decisiones se toman en chats con IA y el siguiente lector suele ser otra IA. Si estás valorando Notion para esto, consulta alternativas a Notion para tareas con IA.

Otros dos límites, con honestidad. Weft no lee tus chats: una decisión solo se registra cuando la IA llama a record_decision, y por eso importa la instrucción de arriba. Y la IA puede equivocarse sobre qué cuenta como decisión, así que lee get_context de vez en cuando y sustituye lo que haya registrado mal.

¿Cuánto cuesta?

Registrar y leer decisiones funciona en el plan Free, que incluye 50 tareas activas y 200 llamadas a herramientas de IA al mes. Cada llamada a record_decision o get_context cuenta como una. Pro cuesta 7,87 € por asiento al mes o 66,55 € por asiento al año, IVA incluido, con tareas y llamadas ilimitadas (precios). Weft no tiene créditos de IA: el razonamiento ocurre en tu propio cliente de IA, y Weft solo guarda el tablero y sus registros.

¿No puedo pedirle a ChatGPT que resuma las decisiones al final del chat y ya está?

Puedes, y ayuda. Pero el resumen sigue viviendo en ese chat o donde lo pegues. No está unido a la tarea, otro cliente de IA no puede leerlo y, cuando la decisión cambia, no queda constancia de lo que sustituyó. Registrar cada decisión en el momento en que se toma evita las tres cosas.

¿Registrará la IA las decisiones sin que se lo pida?

La descripción de la herramienta record_decision le dice a la IA que la use siempre que el usuario tome una decisión real en la conversación, así que algunos clientes lo harán. No cuentes con ello. La instrucción pegada lo deja explícito, y siempre puedes decir «registra esa decisión».

¿Se puede editar una decisión si se registró mal?

No en el sitio. Los registros son inmutables. Registra una decisión corregida con supersedesId apuntando a la errónea. El registro antiguo se queda, marcado como sustituido, y get_context deja de mostrarlo.

¿Las decisiones necesitan una tarea?

No. Una decisión puede estar unida a una tarea, a un proyecto o a ninguno. Unirla a una tarea hace que get_task_history la muestre junto a ese trabajo, y que get_context pueda acotarse a ella.

¿Es lo mismo que la memoria de trabajo de Weft?

No. La memoria de trabajo (notas breves aprendidas) es una función aparte de Pro. Los registros de decisiones salen de record_decision, y el código no los restringe a Pro.

¿Y si uso más de un cliente de IA?

Ese es el motivo principal para hacerlo. ChatGPT, Claude Code, Cursor o Codex conectados al mismo espacio de trabajo de Weft leen todos las mismas decisiones mediante get_context, así que el segundo cliente no reabre cuestiones que el primero ya cerró.