Ontem uma ideia saiu do nosso sistema interno e entrou em um projeto open source real.
Ela parece técnica, mas o problema é de gestão.
Quando um agente de IA mistura regra permanente com status temporário, ele começa a decidir com base em contexto errado.
Um contrato antigo vira regra. Uma exceção vira padrão. Um status vencido vira verdade operacional.
Memória boa sabe o que pode mudar, o que deve ser protegido e qual decisão depende de cada contexto.
Leitores do Radar
Nem todo mundo quer mais conteúdo sobre IA.
Algumas pessoas querem critério.
... leitores já acessaram esta edição do Radar FSTech para separar sinal de ruído no universo da inteligência artificial.
Se você é uma delas, assine o Radar ou compartilhe com alguém que também deveria estar aqui.
SINAIS DE HOJE
1. Uma regra prática da FSTech entrou em um projeto open source.
Fabio Akita é um dos nomes técnicos mais conhecidos da comunidade dev brasileira e mantém o projeto ai-memory. O PR #47 do fstech-digital nesse repositório foi mergeado. Em linguagem simples: a mudança ajuda o agente a separar memória que muda a toda hora de memória que precisa ficar estável.
→ Para um decisor, isso reduz o risco de a IA tratar uma regra antiga como atual ou um status temporário como permanente. Para o time técnico, isso entrou como slot_kind: state | invariant em páginas _slots/*.md.
2. Modelos melhores aumentam a importância de governança.
O sinal secundário de hoje foi Claude Opus 4.8, Fast mode mais barato, controles de esforço no Claude e subagentes paralelos no Claude Code. Agentes tendem a trabalhar por mais tempo, com mais autonomia e em mais etapas.
→ Quanto mais longa a operação, maior o custo de contexto errado. Sem memória governada, produtividade vira retrabalho automatizado.
3. O ganho com IA depende de método, não só de acesso.
O Developer Habits Report da Cursor aponta código por dev mais que dobrando, tool calls crescendo e mudanças geradas por IA chegando mais vezes ao commit. Ao mesmo tempo, o ganho fica concentrado nos power users.
→ A diferença está na capacidade de transformar intenção em especificação, execução em rastro e correção em regra reutilizável.
O comentário do Akita importou porque validou a execução técnica junto com a ideia.
Akita no PR #47: “this is an exemplary external contribution” e “this is the kind of careful, scoped contribution that's a joy to review.” Em outro comentário, ele registrou: “600 tests pass on main (+10 from this PR), fmt + clippy clean.” Leia o PR no GitHub.
Mas o ponto central para empresas é outro: IA operacional precisa de memória confiável.
Antes de automatizar uma decisão, é preciso saber quais dados são permanentes, quais estão em atualização e qual regra decide a próxima ação.
Esse é o papel da Ontologia Operacional: transformar contexto disperso em decisão com rastro.
Dados que entram. Lógica que diferencia. Ação que muda estado com controle.
Se sua empresa está colocando IA em processos reais, comece pelo mapa operacional: o que deve permanecer, o que pode mudar e qual ação o sistema pode executar com segurança. Veja o framework.
MATÉRIAS ORIGINAIS
Projeto ai-memory no GitHub
GitHub PR #47: feat(consolidate): add slot write regimes
GitHub Issue #14: canonical event vocabulary + invariant/behavior dual-doc pattern
Anthropic: Claude Opus 4.8
Cursor: Developer Habits Report
