Porque se perdem as decisões tomadas em conversas com a IA, e onde as guardar

As decisões tomadas numa conversa com o ChatGPT ou com o Claude perdem-se porque uma conversa não tem estado. Nada nela marca uma linha como "foi isto que decidimos", nada liga essa linha ao trabalho que afeta, e uma conversa nova começa vazia. A solução é pôr a IA a escrever a decisão onde o trabalho vive, como um registo curto com as suas razões, e pôr a sessão seguinte a ler esses registos antes de agir.

Nós fazemos o Weft. Os factos sobre outros produtos vêm das respetivas páginas oficiais, verificadas a 27 de outubro de 2026. A ideia de que uma thread "não tem estado" vem do artigo do Hypertask sobre threads no Slack. Este guia aplica-a às conversas com a IA.

Porque desaparecem as decisões tomadas com o ChatGPT ou o Claude?

Passa quarenta minutos com um assistente a ponderar dois fornecedores de base de dados, dois modelos de preços ou duas formas de estruturar uma API. Fica-se por um. O raciocínio é bom, o assistente concorda, e passa à coisa seguinte.

Uma semana depois, a conclusão continua nessa conversa, algures por cima de duzentas outras mensagens. Uma conversa nova não sabe nada dela. Um colega nunca a viu. E se no dia seguinte abrir outro cliente de IA, por exemplo um agente de programação no terminal, esse cliente começa do zero e pode muito bem propor alegremente a opção que rejeitou.

Não é um problema de disciplina. Uma conversa é uma sequência de mensagens. Não tem um campo para "decidido", nem dono, nem ligação a uma tarefa, nem forma de dizer "isto substituiu o que dissemos na terça-feira". Uma questão decidida e uma questão abandonada ficam iguais quando desaparecem lá para cima.

A memória do chat não resolve já isto?

Não para este fim. Muitos assistentes já conseguem lembrar-se de coisas sobre si entre conversas, e isso é útil para preferências e contexto. Mas essa memória pertence a um produto e a uma conta. É escrita para esse assistente a usar, não como um registo que uma pessoa possa rever linha a linha, e outro cliente de IA não a consegue ler. Também não diz a que tarefa dizia respeito uma escolha, nem que escolha anterior substituiu.

Um registo de decisões tem requisitos diferentes. Tem de poder ser encontrado pelas pessoas e pelos agentes que trabalham no projeto, de poder ser lido pelo cliente de IA que pegar no trabalho a seguir, de estar ligado a esse trabalho e de ser honesto quanto ao histórico: quando uma decisão muda, a antiga deve continuar visível, com a razão por que foi substituída.

O que conta como uma decisão que vale a pena registar?

Registe uma escolha quando alguém pudesse razoavelmente ter escolhido outra coisa e a escolha vá moldar trabalho futuro. Bons exemplos:

• Escolher uma ferramenta, um fornecedor ou uma biblioteca em vez de outra.
• Pôr algo de lado de propósito ("sem programa de referências este trimestre").
• Definir uma regra que o trabalho tem de seguir ("todos os preços mostrados com IVA incluído na UE").
• Alterar uma escolha anterior, com a razão.
• Uma lição aprendida da pior maneira ("não correr a migração em horário de expediente").

Não registe:

• Ideias que lançou e não adotou.
• Passos do próprio trabalho (isso pertence à tarefa e ao seu resultado).
• Qualquer coisa com que a pessoa ainda não concordou, a menos que esteja claramente marcada como proposta.
• Factos que qualquer pessoa consegue voltar a consultar num minuto.

Um teste útil: se uma nova sessão de IA estivesse prestes a desfazer esta escolha, quereria que ela parasse e lesse porquê? Se sim, registe-a.

Como é um bom registo de decisão?

Mantenha-o curto e guarde as razões. O formato abaixo é uma versão leve do MADR (Markdown Architectural Decision Records), que é o que a ferramenta record_decision do Weft usa:

Título:        Carregamento de ficheiros: armazenamento de objetos, não a base de dados
Resultado:     Os ficheiros carregados vão para o armazenamento de objetos; a base
               de dados guarda só a chave do ficheiro e os metadados.
Estado:        accepted
Contexto:      Os utilizadores anexam ficheiros até 50 MB. Guardá-los na base de
               dados tornaria as cópias de segurança lentas e grandes.
Opções:        1. Armazenamento de objetos  + barato, cópias de segurança pequenas
                                            - mais um serviço para configurar
               2. Coluna na base de dados   + tudo num só sítio
                                            - as cópias crescem a cada carregamento
Consequências: Precisamos de URLs assinados para os downloads.
               Eliminar uma tarefa também tem de eliminar os seus ficheiros.
Rever quando:  Precisarmos de pesquisar dentro do conteúdo dos ficheiros.
Tarefa:        Carregamento de ficheiros

• Título dá nome à decisão, para que a encontre de relance.
• Resultado é uma frase com que alguém que acabou de chegar consegue agir.
• Contexto é o que era verdade na altura. É a parte que primeiro desaparece da memória.
• Opções lista só o que foi realmente ponderado, não alternativas inventadas depois.
• Consequências inclui as desvantagens que aceitou, para que ninguém as "descubra" mais tarde como bugs.
• Rever quando diz o que tornaria a escolha errada.

Como guarda o Weft um registo de decisão?

O Weft é um quadro de tarefas a que os seus clientes de IA chegam por MCP, em https://letsweft.com/api/mcp. Três das suas 32 ferramentas tratam das decisões:

• record_decision recebe um título e um resultado, mais o contexto, até cinco opções com prós e contras, as consequências e a condição para a rever. Pode ser ligada a uma tarefa (taskId) ou a um projeto. Os registos são imutáveis: para alterar um, a IA regista uma nova decisão com supersedesId a apontar para a antiga, e o registo antigo fica, marcado como substituído.
• get_context devolve as decisões e lições em vigor no workspace, das mais recentes para as mais antigas, arrumadas dentro de um orçamento de tokens (800 tokens por omissão). Pode ser restringido a um projeto ou a uma tarefa. Cada linha traz a sua data, uma decisão substituída nunca aparece, e as linhas que não couberam são contadas em vez de escondidas.
• get_task_history no modo decisions lista todas as decisões registadas sobre uma tarefa, incluindo os veredictos de revisão e as suas razões.

record_decision tem um segundo uso: transmitir um veredicto que a pessoa deu na conversa sobre trabalho à espera da sua revisão (aceite, retrabalho, descartado ou adiado). A descrição da ferramenta diz à IA que aqui é a mensageira, não quem decide, por isso nunca a deve usar para aceitar o seu próprio trabalho.

Como os registos nunca são editados no lugar, o histórico mantém-se honesto. Se mudar de fornecedor em março, a decisão de janeiro continua lá, marcada como substituída, e o registo de março diz porquê.

Como peço à minha IA que registe decisões?

Ligue o Weft ao seu cliente de IA e depois cole uma instrução como esta no início de uma conversa, ou nas instruções personalizadas do cliente ou no ficheiro do projeto, se houver:

Quando fizermos uma escolha a sério nesta conversa (escolhemos uma opção em vez
de outra, pomos algo de lado, ou mudamos uma escolha anterior), regista-a no Weft
com record_decision antes de avançarmos:
- title: a decisão, nomeada em poucas palavras
- outcome: a escolha numa frase
- context: o que era verdade e obrigou à escolha
- options: só as opções que ponderámos de facto, com prós e contras
- consequences: o que daí resulta, de bom e de mau
- confirmation: quando devemos revê-la
- taskId ou project: a tarefa ou o projeto a que diz respeito
Se alterar uma decisão anterior, passa supersedesId em vez de editar.
Não registes conversa de circunstância, palpites nem coisas com que eu não concordei.
Se eu ainda não me tiver comprometido, usa o status "proposed".
No início de qualquer trabalho que não seja trivial, chama primeiro get_context e
diz-me que decisões passadas se aplicam.

Ligar demora um minuto. No ChatGPT, o Weft é uma app publicada no diretório de plugins, disponível em todos os planos, incluindo o Free (configuração). No Claude Code é um só comando (configuração). O claude.ai e o Claude Desktop adicionam-no como conector personalizado. O início de sessão é por OAuth no navegador, por isso não há nenhuma chave para copiar, e o Weft emite refresh tokens, por isso o cliente renova a sessão sozinho. As páginas de configuração de outros clientes, incluindo o Cursor e o Codex, estão na documentação.

O que acontece quando, no dia seguinte, passo do ChatGPT para o Claude Code?

Eis o caso para o qual a instrução foi pensada.

1. Na segunda-feira planeia uma funcionalidade no ChatGPT. Decide guardar os ficheiros carregados num armazenamento de objetos em vez da base de dados, e o ChatGPT chama record_decision com o contexto, as duas opções e as consequências, ligada à tarefa "Carregamento de ficheiros".
2. Na terça-feira abre o Claude Code no repositório. Se ainda não o ligou: claude mcp add --transport http weft https://letsweft.com/api/mcp.
3. Pede-lhe que pegue na tarefa dos carregamentos. Antes de escrever código, ele chama get_context para essa tarefa, ou get_task_history no modo decisions, e recebe o registo de segunda-feira.
4. Constrói com armazenamento de objetos em vez de reabrir a questão. Se encontrar uma razão real para a escolha estar errada, pode propor uma nova decisão que substitua a de segunda-feira, e é o utilizador que decide.

Os dois clientes leem o mesmo quadro e as mesmas decisões, porque o registo vive no Weft, não em nenhuma das conversas. Cada ligação OAuth é um ator próprio, e o quadro mostra o nome com que cada cliente se registou, por isso consegue ver que ligação criou que tarefa. Para pôr vários agentes num só quadro sem colisões, veja vários agentes de IA, um só quadro.

Onde devem ir parar as decisões tomadas no ChatGPT?

Quatro sítios habituais, comparados segundo o que um registo de decisões precisa:

A questão não é que o chat ou os documentos sejam maus. O chat é onde pensa. A decisão tem de ser copiada para fora do chat, para algo com estado, no momento em que é tomada, por quem já está na conversa: a IA.

Isto substitui a nossa documentação ou wiki?

Não. O Weft não tem documentos nem wiki, e não pretende ser uma coisa dessas. Explicações longas, guias de integração e documentos de design pertencem à sua ferramenta de documentação. Um registo de decisão é pequeno de propósito: uma escolha, as suas razões e o que a substituiu. Se a sua equipa já guarda registos de decisões numa wiki e todos os clientes de IA que usa a conseguem ler, isso pode chegar. O Weft é útil quando as decisões são tomadas em conversas com a IA e o próximo leitor é muitas vezes outra IA. Se está a ponderar o Notion para isto, veja alternativas ao Notion para tarefas com IA.

Mais dois limites, com honestidade. O Weft não lê as suas conversas: uma decisão só fica registada quando a IA chama record_decision, e é por isso que a instrução acima importa. E a IA pode avaliar mal o que conta como decisão, por isso leia get_context de vez em quando e substitua o que estiver errado.

Quanto custa?

Registar e ler decisões funciona no plano Grátis, que inclui 50 tarefas ativas e 200 chamadas de ferramentas de IA por mês. Cada chamada a record_decision ou get_context conta como uma chamada. O Pro custa 8,00 € por lugar por mês ou 67,65 € por lugar por ano, com tarefas e chamadas ilimitadas (preços). O Weft não tem créditos de IA: o raciocínio acontece no seu próprio cliente de IA, e o Weft só guarda o quadro e os seus registos.

Não posso simplesmente pedir ao ChatGPT que resuma as decisões no fim de uma conversa?

Pode, e ajuda. Mas o resumo continua a viver nessa conversa, ou onde quer que o cole. Não está ligado à tarefa, outro cliente de IA não o consegue ler, e quando a decisão muda não fica registo do que ela substituiu. Registar cada decisão no momento em que é tomada evita as três coisas.

A IA vai registar decisões sem que lho peça?

A descrição da ferramenta record_decision diz à IA para a usar sempre que o utilizador faz uma escolha real na conversa, por isso alguns clientes vão fazê-lo. Não conte com isso. A instrução colada torna-o explícito, e pode sempre dizer "regista essa decisão".

Uma decisão pode ser editada se tiver ficado mal registada?

Não no lugar. Os registos são imutáveis. Registe uma decisão corrigida com supersedesId a apontar para a errada. O registo antigo fica, marcado como substituído, e get_context deixa de o mostrar.

As decisões precisam de uma tarefa?

Não. Uma decisão pode estar ligada a uma tarefa, a um projeto ou a nenhum dos dois. Ligá-la a uma tarefa faz com que get_task_history a mostre junto desse trabalho, e get_context pode ser restringido a ela.

Isto é o mesmo que a memória de trabalho do Weft?

Não. A memória de trabalho (notas curtas aprendidas) é uma funcionalidade Pro à parte. Os registos de decisões vêm de record_decision, e o código não os restringe ao Pro.

E se usar mais do que um cliente de IA?

É a principal razão para fazer isto. O ChatGPT, o Claude Code, o Cursor ou o Codex ligados ao mesmo workspace do Weft leem todos as mesmas decisões através de get_context, por isso o segundo cliente não reabre questões que o primeiro resolveu.