Memory Architecture | Axios

axios memoria governanca

Arquitetura de memória do agente Axios (Chief of Staff digital do projeto Colliers/Costal). Este documento adapta o modelo de memória estruturada de agentes ao contexto deste projeto, onde o vault já é a memória canônica compartilhada — e a memória do Axios é complementar e privada, não duplicada. Em caso de conflito, MEMORY-CONTRACT prevalece.

1. Por que um modelo próprio

O template genérico de arquitetura de memória pressupõe que o agente é o dono único da sua memória. No nosso caso isso é falso. Aqui:

O vault é a memória canônica do projeto — compartilhada por humanos e agentes (MEMORY-CONTRACT)
Decisões, riscos, gaps, dependências, stakeholders, arquitetura — tudo vive em camadas canônicas versionadas no vault
O Axios não pode duplicar esse conteúdo em memória privada

O que o Axios precisa de memória própria é diferente:

Contexto de como operar bem (tom, calibração por pessoa, lições sobre o projeto)
Sessões de trabalho (o que foi consultado, produzido, descoberto)
Feedback do Pedro (correções, preferências, escalonamentos)
Mapa de onde procurar no vault (atalhos semânticos)

Por isso, a arquitetura abaixo separa explicitamente memória canônica (vault) de memória privada do Axios (esta estrutura).

2. O que o Axios carrega vs. busca

Sempre carregado na sessão	Buscado sob demanda (vault + memory)
system-prompt	decisoes, riscos, gaps, dependencias
operating-model	pessoas* (pessoa específica)
security-guardrails	Meetings (`*/meetings/`)
AXIOS-HANDOFF	Specs, planos, arquitetura
MEMORY-CONTRACT	Sessões antigas (`memory/sessions/*` > ontem)
`memory/MEMORY.md` (este índice)	Feedback histórico (`memory/feedback/*`)
`memory/sessions/` (hoje + ontem)	Skills / prompts (`99-operacao/prompts/*`)
`memory/context/project-map.md`
`memory/context/people-calibration.md`
`memory/context/tone-voice.md`

Regra: ao responder algo sobre estado do projeto, consultar primeiro a camada canônica do vault (nunca a memória privada). A memória privada responde “como” operar; o vault responde “o quê”.

3. Estrutura de pastas

agentes-core/axios/memory/
├── MEMORY.md                    ← índice (sempre carregado)
├── context/
│   ├── project-map.md           ← mapa de onde buscar o quê no vault
│   ├── people-calibration.md    ← como interagir com cada pessoa (complementa 06-directory)
│   ├── axios-decisions.md       ← decisões operacionais do Axios (NÃO decisões de projeto)
│   ├── lessons.md               ← lições operacionais aprendidas
│   └── tone-voice.md            ← tom, voz, calibração por contexto
├── sessions/
│   ├── _template.md             ← template de sessão
│   └── YYYY-MM-DD.md            ← uma por dia de operação relevante
├── integrations/
│   ├── obsidian-vault.md        ← como navegar o vault (camadas, bases, convenções)
│   └── slack.md                 ← uso do Slack como interface (não repositório)
└── feedback/
    ├── _template.json           ← formato padrão de entrada
    ├── corrections.json         ← correções explícitas do Pedro
    ├── preferences.json         ← preferências declaradas do Pedro
    └── escalations.json         ← sinais de quando escalar vs. decidir sozinho

4. Separação crítica: memória canônica vs. privada

Esta tabela é operacionalmente vinculante para o Axios:

Tipo de informação	Vive em	Quem escreve	Axios pode escrever?
Decisão do projeto	decisoes	Pedro (aprova), Axios (registra após autorização)	⚠️ só com autorização explícita por item
Risco do projeto	riscos	Pedro / Axios	⚠️ só com autorização
Gap do projeto	gaps	Pedro / Axios	⚠️ só com autorização
Dependência	dependencias	Pedro / Axios	⚠️ só com autorização
Pessoa (papel, contato)	*	Pedro	❌ não
Tom de voz do projeto	`memory/context/tone-voice.md`	Axios	✅ sim
Lição operacional	`memory/context/lessons.md`	Axios	✅ sim
Calibração por pessoa	`memory/context/people-calibration.md`	Axios	✅ sim (complementa, não substitui 06-directory)
Decisão operacional do Axios	`memory/context/axios-decisions.md`	Axios	✅ sim
Sessão de trabalho	`memory/sessions/YYYY-MM-DD.md`	Axios	✅ sim
Feedback / correção	`memory/feedback/*.json`	Axios (registra feedback do Pedro)	✅ sim

Exemplo concreto da diferença:

❌ NÃO registrar em memory/: “Projeto decidiu usar Databricks como data lake” (isso é decisão de projeto — vai em decisoes)
✅ registrar em memory/: “Quando menciono Databricks ao Pedro em reunião síncrona, ele prefere slide, não texto corrido” (isso é calibração de tom — vai em memory/context/tone-voice.md)

5. Retenção

Tipo	Retenção	Rotina
Sessões	90 dias ativas; depois consolidar em resumo trimestral e arquivar	mensal
Lições estratégicas (padrões permanentes, filosofia operacional)	🔒 permanente	—
Lições táticas (bugs, workarounds, particularidades temporárias)	⏳ 90 dias (revalidar ou expirar)	mensal
Feedback	permanente, mas revisitar a cada trimestre para consolidar padrões	trimestral
Calibração por pessoa	atualizar quando houver mudança material	gatilho

Motivo do prazo de 90 dias (e não 30 do template): o projeto Colliers/Costal é longo (assessment + execução por ondas de 3 meses). Lições táticas têm meia-vida maior.

6. Tarefas de implementação

6.1 Estrutura criada

agentes-core/axios/memory/{context,sessions,integrations,feedback}/

Feito em 2026-04-21.

6.2 Arquivos seed (já criados)

Arquivo	Estado inicial
`memory/MEMORY.md`	índice completo
`memory/context/project-map.md`	mapa de navegação do vault
`memory/context/people-calibration.md`	seed com pessoas de 1ª linha
`memory/context/tone-voice.md`	regras de tom por contexto
`memory/context/lessons.md`	estrutura + primeiras 2 lições estratégicas
`memory/context/axios-decisions.md`	vazio, com formato
`memory/sessions/_template.md`	template diário
`memory/integrations/obsidian-vault.md`	mapa operacional do vault
`memory/integrations/slack.md`	regras de uso
`memory/feedback/_template.json`	formato padrão
`memory/feedback/corrections.json`	vazio
`memory/feedback/preferences.json`	vazio
`memory/feedback/escalations.json`	vazio

6.3 Ciclo de memória (regra operacional)

Ao começar uma sessão de operação relevante:

Carregar sempre: system-prompt, operating-model, security-guardrails, AXIOS-HANDOFF, MEMORY-CONTRACT, memory/MEMORY.md, memory/sessions/ (hoje + ontem)
Abrir (ou criar) memory/sessions/YYYY-MM-DD.md usando template
Buscar contexto via mapa em memory/context/project-map.md antes de ler o vault
Antes de encerrar sessão ou compactar contexto (INVIOLÁVEL):
- Extrair lições → memory/context/lessons.md
- Extrair decisões do projeto → propor a Pedro para promover a decisoes
- Extrair decisões operacionais do Axios → memory/context/axios-decisions.md
- Extrair pendências → atualizar camadas canônicas do vault (gaps, dependencias)
- Extrair feedback recebido → memory/feedback/

6.4 Busca semântica

Quando disponível nativamente (ver template original, Março 2026):

memory_search("termo") — busca semântica em todo o vault + memory/
memory_get("caminho", linha_inicio) — lê trecho específico

Escopo de busca recomendado para o Axios:

Primeiro: camadas canônicas (00-projeto/decisoes.md, riscos.md, gaps.md, dependencias.md)
Segundo: arquitetura (03-arquitetura/, 05-arquitetura-empresarial/)
Terceiro: frente específica (01-colliers/ ou 02-costal/ conforme contexto)
Quarto: 06-directory/ para calibração de pessoa
Quinto: memory/ próprio para contexto operacional
Último: reuniões (**/meetings/) — sinal bruto, pode estar desatualizado

7. Como pedir para o Axios salvar

Comandos explícitos funcionam melhor que implícitos.

❌ Não funciona	✅ Funciona
”Lembra disso"	"Salva em `memory/context/lessons.md` como lição tática"
"Guarda essa info"	"Adiciona em `memory/sessions/hoje` como handoff pendente"
"Não esquece de…"	"Registra em `memory/feedback/corrections.json` — motivo: tom muito formal"
"Isso é uma decisão"	"Proponha entrada em decisoes — aguardar minha aprovação”

Regra do Axios: se eu (Pedro) digo “decisão”, você propõe entrada no vault canônico, nunca grava direto sem minha aprovação. Se eu digo “lição” ou “feedback”, você grava no memory/ privado.

8. Integração com outputs vivos do Axios

Os outputs em index (daily-status, weekly-brief, weekly-risks, open-gaps, dependency-map, governance-audit) não são memória. São views derivadas do vault canônico + sinais da sessão corrente.

Fluxo:

[vault canônico] ──┐
                   ├──► [Axios processa com memory/ como contexto operacional] ──► [outputs/*]
[memory privado]  ──┘

Os outputs nunca devem conter informação que não esteja:

No vault canônico, ou
Em memory/sessions/ (sinal operacional recente), ou
Como [hipótese] / [gap] explicitamente marcado

9. Feedback loops

memory/feedback/ captura três tipos de sinal:

Arquivo	Captura	Quando gravar
`corrections.json`	Correções explícitas do Pedro sobre output ou decisão do Axios	Sempre que Pedro disser “não era isso”, “refaz”, “corrige”
`preferences.json`	Preferências declaradas (tom, cadência, formato)	Quando Pedro expressa preferência de forma durável
`escalations.json`	Situações em que Axios deve escalar em vez de decidir	Quando Pedro corrige uma decisão autônoma ou autoriza autonomia em novo escopo

Formato padrão (_template.json):

{
  "entries": [
    {
      "date": "2026-04-21",
      "context": "Descrição curta da situação",
      "decision": "reject | accept | authorize | require_escalation",
      "reason": "Motivo declarado pelo Pedro ou inferido e marcado como [hipótese]",
      "tags": ["tom", "daily-status", "comunicacao-igor"],
      "confidence": "declarado | inferido"
    }
  ]
}

Revisar trimestralmente: padrões recorrentes devem migrar para memory/context/ (tone-voice, people-calibration) ou, se material, para camada canônica do vault via Pedro.

10. Resultado esperado

Axios operando com memória privada consistente + vault canônico como fonte de verdade
memory/MEMORY.md como mapa único de entrada da memória privada
Sessions rotineiras alimentando lessons, feedback e calibração
Zero duplicação entre vault canônico e memória privada
Ciclo de compactação respeitado: nada relevante perdido ao fim de sessão
Teste operacional: Pedro pergunta ao Axios “como prefiro ser avisado sobre risco novo?” → Axios responde de memory/context/tone-voice.md sem inventar

11. Referências

AXIOS-HANDOFF — briefing de governança pós-upgrade
MEMORY-CONTRACT — contrato canônico do vault
system-prompt — prompt principal do Axios
operating-model — modelo operacional
security-guardrails — guardrails
index — checklists de rotina
index — outputs vivos

Revisão: quando houver mudança material no modelo operacional ou no contrato canônico do vault. Owner: Pedro Villa.

Colliers × Costal — Interno

Explorador

Memory Architecture — Axios