Habilidades dinâmicas: o novo modelo de conhecimento para agentes de IA

A maioria das “skills” dos agentes de IA hoje é estática. Alguém lê a verdade uma vez, escreve num arquivo markdown e publica. O procedimento e os fatos ficam congelados no mesmo parágrafo: qual tabela é canônica, qual é a chave de junção, qual filtro remove as contas de teste. Aí a tabela é descontinuada — e a skill não fica sabendo.

Ninguém acha que isso escala. Mas a resposta que a indústria costuma buscar é sempre a mesma gaveta: um registro, um campo de dono, um esquema de versionamento, um linter de frontmatter. Tomer Mesika, cofundador e CTO da modus, argumenta que isso só empilha metadados mais arrumados em cima de conhecimento que continua errado.

Uma skill estática é um cache sem protocolo de invalidação

A tese central: uma skill estática é um cache sem protocolo de invalidação. Ela guarda o resultado de uma busca — os fatos que alguém consultou enquanto escrevia — atrás de uma chave que é uma descrição de tarefa em linguagem natural. Sem rastreamento de dependências, sem TTL, sem como notar que uma fonte mudou.

Daí caem todas as queixas sobre bibliotecas de skills. Elas ficam obsoletas porque caches não invalidados ficam obsoletos. Elas se multiplicam porque copiar o cache é a forma mais barata de servir uma tarefa ligeiramente diferente. Elas se contradizem porque duas cópias derivam em ritmos próprios. E incham porque um autor que não consegue prever quais fatos o modelo vai precisar escreve todos eles, por via das dúvidas.

Resolvendo fatos em tempo de chamada

A alternativa que a modus roda hoje: o arquivo autoral guarda a intenção, o procedimento, o contrato de saída e as guardas, além de um escopo sobre o conhecimento da empresa. Cada fato é resolvido contra uma camada de contexto viva, no momento em que o agente pergunta. O markdown que o modelo lê continua existindo — só que vira um artefato de build com vida útil de uma única chamada.

Isso separa duas velocidades de mudança. O procedimento muda quando um time muda de ideia — talvez trimestralmente. Os fatos mudam quando os sistemas que os possuem mudam: uma migração entra às 2h da manhã, um canal é arquivado, uma query é reescrita por um analista que já saiu. Se algo muda no segundo relógio, uma pessoa não deveria mantê-lo à mão.

Rankeando seções, não chunks

Um detalhe importante do sistema é a escolha de ranquear por seções, não por itens. Os candidatos resolvidos são agrupados em seções numeradas seguindo a hierarquia natural — integração, seleção, objeto, detalhe —, as seções são rankeadas e um prefixo do ranking é escolhido até caber no orçamento de tokens (15.000 por padrão, teto de 50.000). Seção acima de 5.000 tokens é explodida nos filhos antes, senão um bloco gigante compete de igual para igual com uma nota de uma linha.

Um exemplo citado ilustra o argumento inteiro: numa execução real, uma nota humana de 68 tokens — “fact_orders conta refunds em dobro antes de 2024” — ficou em terceiro no ranking, acima de quatro tabelas. Nenhum autor teria pensado em citá-la numa skill sobre receita.

O custo e quando não vale a pena

Há um preço honesto: isso exige um time inteiro. Uma skill estática precisa de um escritor; o modelo dinâmico precisa de uma camada de contexto, um motor de composição, um contrato de renderização e um harness de avaliação. O próprio autor é taxativo: com cinco skills e um time, continue escrevendo arquivos. O momento de começar a construir é quando você corrige um fato numa skill e percebe que não tem como responder quantas outras skills ainda estão erradas.

Três lições que ele diz que guardaria: separe o artefato pela taxa de mudança (humanos escrevem intenção e escopo, o sistema resolve fatos); torne o documento composto determinístico e rastreável antes de torná-lo inteligente; e meça o recall no orçamento que você realmente envia — os números agregados podem mentir. A diferença entre o recall agregado e o recall no orçamento apertado chegou a 11 pontos numa única mudança.