A Apura, explicada do zero
A Apura é um CFO feito por inteligência artificial. O cliente recebe o trabalho financeiro pronto — o fechamento do mês e as análises — sem operar ferramenta nenhuma. A tese é vender o trabalho feito, não o software: o valor de um CFO, com a margem de um produto de tecnologia, porque quem faz o trabalho é a IA.
Não é só "fechar o mês". É o ofício de CFO inteiro: o fechamento recorrente, as análises (fluxo de caixa, negociação, valuation, pricing, tributário), os materiais de apresentação e a relação de acompanhamento com cada cliente. Este manual explica, em linguagem simples, tudo sobre como esse agente é construído: a estrutura, os papéis, o conhecimento, as regras, o aprendizado e a segurança.
Zero número inventado. Em serviço financeiro, um número errado vai parar no cliente. Por isso toda afirmação precisa de origem rastreável: ou veio de um material (cita onde), ou foi calculada por código (mostra a conta), ou é uma premissa declarada como tal. Quando falta base, o agente se abstém e pergunta — uma lacuna assumida vale mais que um chute.
Como um pedido vira entrega
A Apura não é "um robô que responde". É uma linha de produção de papéis especializados — cada um uma mente separada — que passam o bastão até o trabalho ficar pronto, revisado e aprovado. E, no fim, a casa aprende com o ciclo e fica melhor no próximo. Este é o fluxo inteiro:
O fluxo é o mesmo para qualquer domínio; só muda de onde vem a base de dados.
Onde a Apura quer chegar
O negócio sobe uma escada de três degraus:
0V0 · Protótipo
Automatizar o fechamento de um cliente-piloto de ponta a ponta.
1V1 · Multi-cliente
Rodar a carteira da Base inteira com o mesmo agente.
2V2 · Produto
CFO-as-a-service vendido a outras consultorias e PMEs.
A margem acompanha: começa híbrida (a IA faz o grosso, um humano revisa) e a fatia automatizada cresce com o tempo — de margem de serviço para margem de software.
As camadas do cérebro
O "cérebro" da Apura é organizado em camadas, cada uma com uma função clara. Entender essas peças é entender o agente inteiro. Uma frase para cada:
⚙️Núcleo
Quem cuida da casa: os papéis de suporte (orquestrador, construtor, treinador, guardião, pesquisador, revisor de engenharia) e o roteiro-mestre do trabalho. Servem todos os domínios.
🎭Domínios
Quem entrega para o cliente. Duas frentes que não se misturam: financeiro (o serviço de CFO) e conteúdo (conteúdo educativo para atrair clientes).
📚Biblioteca
O que a casa sabe: a expertise de CFO destilada (metodologia, tributário, benchmarks, glossário), organizada em 4 estantes que todos podem ler.
🔒Clientes
O dado de cada cliente — sempre sob codinome. Plano de contas, métricas, histórico e a visão de acompanhamento daquele cliente.
♻️Aprendizado
Como a casa melhora com o tempo: regras, correções e testes. É descrito como o moat — a vantagem competitiva que se acumula.
🏛️Governança
A operação do próprio agente: o painel de saúde, o versionamento, a telemetria, os runbooks. As regras e quem as aprova.
O que fica FORA do cérebro
Nem tudo mora no cérebro que sincroniza. A linha que separa é a de sigilo e LGPD: o que viaja entre máquinas é sempre anônimo; o que identifica o cliente fica preso localmente.
| Cérebro | Cortex\Apura — conhecimento + relação, só codinome. Sincroniza e sobe para backup. |
| Galpão (Drive) | Os arquivos reais do cliente (extratos, fechamentos, decks). Ficam fora do cérebro. |
| Sala de máquinas | Apura-dados, local — os scripts, o rascunho e o cofre (a tabela que liga codinome ↔ nome real). Nunca sincroniza. |
| Base | O OneDrive da Base — material do cliente, só leitura. Nunca escrever lá. |
| Supabase | Os números dos fechamentos, consultáveis por SQL, também sob codinome. |
O que sincroniza/viaja (cérebro, motor) é sempre anônimo. O que identifica o cliente (dado bruto, cofre, segredos) fica preso na máquina. Toda mudança sensível responde a duas perguntas: "onde isto é forçado?" e "como recupero se perder?".
Os papéis do agente
A Apura trabalha por papéis especializados — cada um é uma "mente" separada, com seu próprio contexto e manual. Um produtor cria, um revisor tenta derrubar, e nada chega ao cliente sem passar pela sua aprovação. Clique para expandir cada papel.
🎭Orquestrador▶
🔧Construtor▶
🎓Treinador▶
🛡️Guardião▶
🔬Pesquisador▶
✦Revisor de engenharia▶
📊Fechador▶
📈Analista▶
📝Reporter▶
♟️Estrategista▶
🔍Revisor▶
✍️Prompter▶
⛏️Pauteiro▶
✒️Redator▶
🎬Diretor de arte▶
🧠Estrategista digital▶
🔎Revisor-técnico▶
📣Prompter de conteúdo▶
Toda etapa começa declarando, na primeira linha, qual papel está na cadeira e em qual modelo roda — ex.: 🎭 ANALISTA [Opus·high] · Cliente-B · projeção 2028. Serve para você auditar ao vivo se o papel certo assumiu e se o modelo certo foi escolhido. Etapa sem carimbo = rodou "genérico" = tratado como erro.
O que a casa sabe
A biblioteca é o conhecimento do agente — o equivalente ao "RAG" (o material que a IA consulta para trabalhar). Ela é governada por uma lei simples que decide o que pode ser guardado e compartilhado.
A lei da biblioteca
Método é da casa, dado é do cliente. Toda técnica — como fechar um mês, como categorizar uma despesa, como montar um slide — é conhecimento da Apura: fica guardado, é compartilhado e vale para todos. Já número específico, extrato, nome real, CNPJ — isso é do cliente: é confidencial, não sobe para o cérebro, e é lido "fresco" na hora do trabalho.
Nas palavras do Admin: "todo fechamento é o mesmo processo, só muda de onde vem a base de dados." O processo é da casa; o que muda de cliente para cliente é só o "delta", que fica na pasta do cliente.
As 4 estantes
A biblioteca é uma só — as estantes só organizam fisicamente, para achar e carregar mais fácil. Qualquer papel pode ler qualquer estante.
📖casa
Os combinados gerais que todo papel segue: glossário, comunicação executiva, checks de sanidade, buscar o que já existe antes de produzir, design.
💰financeiro
A expertise de CFO — o coração: metodologia de fechamento, tributário, benchmarks por setor, templates de planilha, padrão de deck. + destilados de cliente (sem identidade).
📣conteúdo
O "saber fazer" da frente de conteúdo: copywriting, estratégia social, roteiro de vídeo curto, fontes de pauta, design de conteúdo.
⚙️sistema
A engenharia do próprio agente: engenharia de agentes, modelo de dados, estudos de harness. É o material de estudo de quem constrói e treina a Apura.
Um redator escrevendo sobre "margem de contribuição" pode e deve abrir os arquivos financeiros. Método é aberto a todos. O que fica fechado é o dado do cliente (a pasta Clientes, o cofre, o radar) — isso um papel de conteúdo nunca abre.
Como conhecimento novo entra
Nada entra direto. Todo conhecimento novo passa por uma quarentena com aprovação — é a defesa contra o cérebro se corromper sozinho.
Quarentena (_Inbox)
Todo rascunho — gerado pela IA ou vindo de fora — espera numa sala de quarentena. Nada pula a fila.
O pesquisador cataloga
Ele destila o tema em no máximo uma página, com fonte verificada, e deposita já rotulado com a estante de destino.
O gate (aprovação)
Só depois do Admin validar é que o conhecimento sai da quarentena e vira parte oficial da biblioteca. Nada promove pra geral sozinho.
Rotular e indexar
O arquivo ganha tags (tema, setor, escopo) e entra no índice — o mapa navegável do cérebro.
Regra que acompanha: consolidar não é apagar. Conhecimento nunca é deletado; quando uma nota "vence", ela perde o selo de certificada e volta para a quarentena até ser revalidada — mas não some.
Por que essa arquitetura é a certa
Em julho de 2026, o pesquisador checou esse desenho contra o estado da arte (documentação da Anthropic, pesquisas acadêmicas, padrões de segurança). Veredito: sólido, só pequenos ajustes de calibragem. Os pilares confirmados:
- Biblioteca maior que o agente: carregar um manual curto + consultar o método na hora é o recomendado. Copiar o mesmo texto em vários manuais é o erro clássico que causa contradição.
- Carregar só o necessário: o contexto da IA é finito e piora quando entulhado. Guardar atalhos leves e abrir o conteúdo em tempo real é o certo.
- Compartilhar método não enviesa: o que estraga a independência do revisor é ele ver o raciocínio do produtor — não o método comum. Por isso: método compartilhado, recompute em sessão separada, humano no fim.
- Quarentena + aprovação: é a defesa canônica contra "envenenamento da memória" — o risco real não é um atacante externo, é a auto-corrupção. O gate humano da Apura é até mais forte que o padrão da indústria.
Como a casa aprende
O que separa a Apura de "um chatbot" é o flywheel — a roda que ganha impulso: cada ciclo deixa a casa um pouco melhor, de forma permanente. Não é acumular anotações soltas; é compor melhoria.
Captura da lição
Quando o Admin corrige algo, vira artefato na hora — não espera "depois".
Quarentena e promoção por gate
A lição fica em rascunho e só vira verdade depois de validação humana.
Vira regra durável
Quando é geral e passa nos testes, é promovida à biblioteca ou às regras.
Uma IA não se auto-corrige bem em número ou raciocínio — às vezes piora. Por isso o loop gira em torno de verificadores externos (código que recalcula, a regra buscada no arquivo, o Admin), nunca o agente conferindo a própria conta.
Aprendizado × Biblioteca
| Aprendizado | Como a casa melhora — o flywheel: captura, quarentena, promoção, testes. A máquina de ficar mais inteligente. |
| Biblioteca | O que a casa sabe — o acervo já validado. É o destino para onde as lições promovidas vão morar. |
Dataset e treino do futuro
Toda categorização validada vira um "par" (lançamento → categoria certa) num arquivo de dataset. É uma coleção de gabaritos provados pelo Admin. Hoje orienta o agente; no futuro (V2), é o material com que se treina um modelo próprio e barato — o moat. Treinar modelo próprio é coisa de amanhã; o autoaprimoramento de hoje é por memória (texto e arquivos), sem mexer nos pesos do modelo.
Evals — o freio anti-regressão
Um "eval" é um caso de teste com gabarito conhecido. Antes de mudar uma regra importante, o agente re-testa os casos: se algum regride (passa a errar o que já acertava), a mudança não entra. Há duas suítes: regression (casos que já acerta — tem que ficar perto de 100% para aprovar qualquer mudança) e capability (casos difíceis que medem progresso).
"O dataset cresce quando o agente nos envergonha." Toda falha de produção vira caso de teste na hora, no mesmo lote da correção — nunca "depois". E na categorização, cada caso roda 3 a 5 vezes e exige acerto em todas (consistência, não sorte).
As rotinas de manutenção
- Consolidação: periodicamente, um agente de contexto limpo varre o cérebro atrás de duplicatas e contradições, propõe merges e arquiva o log destilado — sempre com aprovação.
- Validar a quarentena: esvazia o
_Inbox— promove o que é verificável, saneia dados pessoais, escala ao Admin só o essencial. - Debriefing de ciclo: consolida o aprendizado por ciclo — o feedback do Admin, a reunião com o cliente, a telemetria — separando o geral do específico.
O painel de saúde
É a primeira coisa que o agente checa ao abrir trabalho. Existe porque o flywheel já parou em silêncio duas vezes (9 dias, depois ~20 dias) — porque dependia de alguém lembrar. O painel torna todo vencimento visível e obrigatório de reportar: qualquer item vermelho vira aviso ao Admin antes da tarefa. Ele vigia a consolidação, a validação da quarentena, os evals, o dataset, a auditoria de segurança, o radar de números e o backup do cofre.
Mesa × Conselho
| Mesa | Revisa o sistema — a própria máquina (estrutura, manuais, papéis). Conserta como a casa trabalha. Cadência mensal. |
| Conselho | Revisa o entregável — o que vai ao cliente. Confere o que a casa produz, com revisor adversarial em contexto separado. |
As regras e quem aprova
A Apura tem uma hierarquia de regras clara, do inviolável ao pessoal. A regra específica detalha a geral, nunca a contradiz — e em conflito, o nível mais alto sempre vence.
Invioláveis
Valem sempre, para qualquer um, até para o administrador — os "NUNCA" e as regras de segurança.
Gerais do sistema
O que define a Apura: identidade, o Princípio Zero, a arquitetura de dados, o aprendizado.
De domínio
As regras de cada frente (financeiro × conteúdo) — valem quando o pedido é daquela área.
De papel
O ofício de cada função (fechador, revisor…) — valem só quando aquele papel é assumido.
De modo
Produção × desenvolvimento — valem conforme o branch do git em que se está.
De pessoa
Preferências pessoais (tom, formato) — só para aquela pessoa; nunca viram regra geral.
Gates — onde o humano aprova
Um gate é um ponto de parada obrigatório onde o Admin precisa aprovar. Os principais:
- Entregável ao cliente: todo material passa pelo revisor e para no gate do Admin. Nada é enviado sem isso — é a linha que protege a marca.
- Gate de entrada: num pedido ambíguo, o agente devolve um brief curto e espera OK antes de executar. Tarefa trivial e reversível é feita direto.
- Promover aprendizado: conhecimento auto-gerado só vira verdade com aval humano.
- Subir uma versão: PR → aprovação → merge → tag. Em versão MAJOR, gate reforçado.
Cada tema tem um único arquivo que é a fonte da verdade — e só nele a regra é editada. Os outros lugares apontam, nunca duplicam. É por isso que o manual foi enxugado de 486 para ~230 linhas: nada foi apagado, os detalhes moraram nos donos.
Versionamento
A Apura é um sistema que evolui — as versões se sucedem, não convivem. O número diz o quão evoluído o sistema está, e independe de qual modelo Claude roda por baixo. Cada versão é uma tag no git (recuperável em minutos). MAJOR muda arquitetura ou comportamento profundo (ritual completo: backup + testes + gate). MINOR é capacidade ou regra nova. Patch é correção pequena.
| v1.0 | Baseline versionada — toolbox, o treinador, os NUNCA, os hooks, o manual enxuto. |
| v2.0 | O salto — governança (N0–N5), segurança/acesso, versionamento + modo dev, a lei da biblioteca. Aprovado com 14 gates. |
| v2.1 | A ponte pro cutover — harness distribuível, runbook do corte. |
| v2.2 | A casa arrumada — reorganização em Núcleo × Domínios × 4 estantes. |
| v2.3 | Nomes que se explicam — Conhecimento→Biblioteca, Sistema→Núcleo. 0 arquivo perdido. |
| 3.0 (planejado) | O cutover pra Base — repos da organização, time GT. Major por definição. |
Produção × desenvolvimento
O agente opera em dois modos, e a fronteira é o branch do git. Produção (main) é onde se atende o cliente — aqui não se mexe no sistema. Desenvolvimento (dev/*) é a oficina onde se mexe no próprio sistema — aqui não se atende cliente. A regra de ouro: "quem está em dev não atende; quem atende não desenvolve." Entrar em dev exige a chave de administrador.
A régua de decisão: o treinador propõe a mudança (no debrief ou na mesa); o gate — o Admin — aprova. Quem produz nunca é quem aprova.
Como a casa se protege
Segurança na Apura não é um aviso no manual — é estrutura: proibições duras, anonimização por desenho, uma chave à prova de forja, e verificações automáticas que rodam sozinhas em toda sessão.
Os NUNCA
- Nome real ou dado pessoal no cérebro, nunca. Nada de pessoa, CNPJ, banco/conta real. Um "guarda-PII" avisa quando algo do tipo aparece.
- Entregável ao cliente sem revisor + gate, nunca.
- Número sem origem não se escreve.
- Segredo em chat, documento ou repositório, nunca. O segredo nasce direto no destino (arquivo local ou 1Password). Colar no chat "queima" o segredo.
- Escrever no OneDrive da Base, nunca (é zona só de leitura).
- Trabalhar sem o carimbo de papel+modelo, ou um papel agir sem ter lido o próprio manual = erro.
Codinome — a regra de ouro da LGPD
O codinome (Cliente-A, Cliente-B…) é a chave em todos os documentos e tabelas. Zero nome real, zero CNPJ, zero conta real — até as contas são genéricas (corrente-1). O cérebro sincroniza entre máquinas, então só pode conter codinome. O cofre — a tabela que liga codinome ao nome real — nunca sobe: fica só local. O que viaja é anônimo; o que revela quem é o cliente fica preso na máquina.
A chave de administrador (anti-forja)
Como o sistema sabe que quem manda mexer é autorizado? Não pela identidade declarada (dizer "sou o Admin" no git é só uma assinatura, e assinatura se forja). A autoridade vem da credencial provada: o sistema testa se a máquina realmente acessa o repositório privado.
A chave de dev é um código secreto. O sistema não guarda a chave — guarda só a "impressão digital" dela (um hash, que não revela o segredo). Na abertura, ele compara a impressão do arquivo na máquina com a impressão oficial, vinda do repositório central. Se bate → modo dev autorizado. Se o arquivo existe mas a impressão não bate → possível forja, recusa e avisa o Admin. A trava física final é o merge com aprovação (CODEOWNERS) — duas camadas. E perder a chave nunca tranca o agente: produção roda sem ela.
As verificações automáticas (hooks)
Um roteiro dispara sozinho no começo de toda sessão e injeta as regras + checagens no contexto, mesmo que ninguém leia manual. Ele:
- Reforça o carimbo obrigatório e o Princípio Zero.
- Lê o painel de saúde e avisa o que está vencido, antes da tarefa.
- Confere se o motor está sincronizado (senão manda dar
git pullantes de qualquer fechamento). - Valida o modo dev e a chave (a checagem anti-forja).
- Verifica a idade do backup do cofre (local e no Drive) e manda renovar se envelheceu.
- Avisa quando um arquivo de aprendizado passou do teto e precisa ser arquivado.
- Repete os NUNCA no fim, como lembrete fixo.
Backups — onde mora a recuperação
| Versões (git) | Cada versão é uma tag recuperável — voltar a qualquer estado anterior leva minutos. |
| 7z do cofre | Em dois lugares: local na máquina + cópia no Drive (fora da máquina). O hook vigia a idade dos dois. |
| Recuperação da chave | Plano A: 1Password. Plano B: regenerar o par. Plano C: a conta do GitHub (raiz de confiança, com 2FA). |
Onde os números e o código vivem
A Apura separa fisicamente o que sincroniza (sempre anônimo) do que identifica o cliente (preso local). São quatro "caixas", cada uma com um papel.
O radar (Supabase)
É um banco de dados na nuvem — projeto próprio da Apura, região Brasil, isolado do projeto do cliente — onde os números ficam consultáveis. Em vez de abrir uma planilha de 26 MB, confere-se um número com uma consulta rápida. Quem manda continua sendo a planilha e o motor; o Supabase espelha o resultado para consulta.
- Entrada: cada transação vira uma linha, sem duplicar (por hash). (em construção)
- Saída: os números já fechados — é o que se consulta. (já funciona)
- Ele se defende sozinho: trava de acesso ligada, só aceita codinome no padrão
Cliente-…, um gatilho barra CPF/CNPJ em descrição, e mês fechado vira imutável. - Benchmark entre clientes é proibido por consulta solta — só sai de uma camada dedicada, com amostra mínima. Nenhum dado real de pessoa entra ali.
As quatro caixas
🧠Cérebro nina-vault
O conhecimento e a relação (Cortex\Apura). Sincroniza entre máquinas e sobe para backup. Só codinome, nunca PII.
🔧Motor apura-motor
O código que roda a lógica (scripts, hooks, migrations). Vai para o GitHub da organização; as chaves ficam na máquina.
📁Drive
O dado bruto do cliente — extratos e arquivos originais. O cofre (codinome ↔ nome real) também mora local/no Drive, nunca no cérebro.
🗄️Supabase
Os números, consultáveis, isolados e sob codinome.
O que viaja (cérebro, motor) é sempre anônimo. O que identifica o cliente (dado bruto, cofre, segredos) fica preso local. Método sobe; dado de cliente, não.
Como pedir — e o que roda por baixo
Você fala com a Apura em linguagem natural. Não há comando decorado a aprender: o orquestrador entende o pedido e chama o papel certo. Para as tarefas recorrentes, existem "comandos salvos" — receitas fixas que rodam sempre igual, nunca de memória.
Comandos salvos (os rituais)
Quando você diz uma destas frases, o agente roda um roteiro versionado — a garantia de que o passo a passo é sempre o mesmo, não improvisado.
| "fecha o Cliente-A de maio" | Roda o fechamento mensal completo (fechador → revisor → seu gate). |
| "prepara a reunião do Cliente-B" | Monta a leitura estratégica e o roteiro para a conversa com o cliente. |
| "gera o deck" | Transforma o fechamento já aprovado no material de apresentação. |
| "analisa [a decisão]" | Abre uma análise (viabilidade, pricing, cenário) com número rastreável. |
| "fluxo de caixa do Cliente-X" | Monta ou atualiza a projeção de caixa. |
| "pesquisa X" | O pesquisador estuda o tema e entrega o destilado, em quarentena. |
| "encerra a sessão" | O ritual de fim: captura aprendizados, atualiza o painel, fecha os ciclos. |
Há também os comandos que cuidam do cérebro: "consolida" (junta lições repetidas numa regra), "valida a inbox" (esvazia a quarentena), "roda a mesa do treinador" (revisa o sistema) e "debriefing do ciclo". Para mexer no sistema: "entra em modo desenvolvimento" — e aí a chave de administrador é exigida.
A caixa de ferramentas
Para não errar conta e não reinventar a roda, a Apura tem um toolbox — ferramentas testadas que os papéis usam em vez de escrever um script novo toda vez. A regra: antes de escrever qualquer script, consulta o índice — a ferramenta provavelmente já existe. As principais:
📄Ler planilha
Inspeciona e extrai dados de um xlsx/xlsm (abas, células, fórmulas) sem depender do Excel aberto.
🏦Ler extrato e fatura
Converte um extrato OFX do banco, ou uma fatura em PDF (mesmo com senha), em números exatos.
🖨️Gerar e conferir deck
Transforma HTML, planilha ou PPTX em PDF e faz o QA visual do entregável, página a página.
💼Roll da folha
Insere o mês novo na folha do FP preservando gráficos e fórmulas — e confere sozinho até o centavo.
📊Radar do fechamento
Sincroniza os números fechados com o banco de dados consultável, para conferência rápida.
♻️Métrica do flywheel
Mede quanto a casa reusou de ferramenta pronta versus script novo — o vigia da eficiência.
Cada ferramenta nasce de um caso real e passa pelo revisor de engenharia antes de virar oficial.
Os termos, em uma linha
Um dicionário rápido dos termos que aparecem neste manual, para leigos.
| Agente | A IA que faz o trabalho — aqui, a Apura. Não é um chatbot; é uma linha de produção de papéis. |
| Papel | Uma função especializada (fechador, revisor…), com manual próprio e contexto separado. |
| Pipeline | A ordem em que os papéis trabalham: produz → revisa → reporta → aprova. |
| Gate | Ponto de aprovação humana obrigatória (quase sempre, o Admin). |
| Flywheel | A roda de aprendizado: cada ciclo deixa a casa melhor de forma permanente. |
| Biblioteca (RAG) | O conhecimento que o agente consulta para trabalhar, organizado em 4 estantes. |
| Quarentena (_Inbox) | A sala onde todo conhecimento novo espera aprovação antes de virar oficial. |
| Eval | Caso de teste com gabarito, que impede o agente de regredir ao mudar uma regra. |
| Codinome | O apelido anônimo de cada cliente (Cliente-A…) usado em todo o cérebro. |
| Cofre | A tabela local que liga codinome ao nome real. Nunca sai da máquina. |
| Carimbo | A etiqueta na 1ª linha de cada etapa dizendo qual papel e qual modelo está rodando. |
| Mesa × Conselho | Mesa revisa o sistema (a máquina); Conselho revisa o entregável (o que vai ao cliente). |
| Modo dev | A "oficina" (branch dev/* + chave de admin) onde se mexe no próprio sistema. |
| Tag / versão | Uma foto recuperável do sistema no git (apura-v2.3), a que se pode voltar em minutos. |
| Princípio Zero | Zero número inventado — toda afirmação tem origem, ou o agente se abstém e pergunta. |
Apura · Manual do agente · versão 2.3 · documento interno da Base · pt-BR.