O domínio A1–A5 + A4b + A4c em 10 perguntas: binding de memória, playbooks inteiros no prompt, o write-back honesto do A3b, manifests PAUSED, o caveat da fabricação sem tool-loop, import idempotente e destilação marcada com confidence ≤ 0.5.
Hoje existem 43 AI Employees (~/.alembic/employees) e 148 skills no SkillStore (~/.hermes/skills). Código: packages/hermes/src/employee/ (run, writeback, connectors, introspect) e packages/hermes/src/memory/ (transcript-import, session-distill). Cada explicação cita a âncora.
Um AI Employee é composição, não mágica: uma soul (identidade + preferências de modelo), skills cujos playbooks inteiros entram no prompt, um binding de memória que decide quais substores o turno enxerga, e DECLARAÇÕES de connector/schedule que só viram fio nos seams A3/A4. O que não está bindado não vaza; o que não está construído não é prometido.
Pense como… a pasta de admissão de um funcionário novo: crachá (soul), manuais que ele leu de verdade (playbooks), as gavetas a que tem chave (substores bindados) e os pedidos de acesso ainda pendentes no RH (connectors unwired). Onde quebra: funcionário lembra do dia anterior por conta própria; o employee só "lembra" do que o binding injeta.
# inspecione um employee de ponta a ponta ($0, determinístico) alembic employee list alembic employee show <id> alembic employee connectors <id> --json # {wired, unwired} — offline: tudo unwired alembic employee explain <id> --goal "triagem de issues" # 10 passos observed/inferred/unknown alembic employee run <id> --goal "triagem de issues" # preview do prompt; modelo NÃO é chamado # âncoras: run.ts:162/281 (composeSkillsText) · connectors.ts:67-75 (unwired nunca dropado) # introspect.ts:51-52 (tags) · writeback.ts:5-14 (A3b honesto, opt-in)
Placar cumulativo no fim. O tema de fundo é um só: honestidade estrutural — o sistema é desenhado para não conseguir mentir sobre o que fez.
O que um AI Employee COMPÕE, na definição do domínio?
packages/hermes/src/employee/employee.ts + alembic employee show <id>.O employee binda só episodic e semantic. O que o turno enxerga do multi-store?
employee run consulta APENAS os substores bindados do diretório multi-store (<dataDir>/memory/<substore>.jsonl, o mesmo de alembic memory). Un-bound não entra nem "por conveniência". E memória nunca quebra o turno — falha de leitura degrada, não derruba.Como as skills bindadas participam do prompt do employee?
composeSkillsText (packages/hermes/src/employee/run.ts:162 e :281) carrega cada skill bindada pelo SkillStore (~/.hermes/skills) e injeta o CORPO no prompt. Best-effort: skill que falha ao carregar é pulada; sem skills bindadas, a seção nem existe.Após um turno --online bem-sucedido, o que o A3b escreve?
recordEmployeeTurn, packages/hermes/src/employee/writeback.ts:5-14) appenda UM registro episódico HONESTO — goal real + excerpt real — e NUNCA um "learning" fabricado. É opt-in (sem binding episódico = no-op), determinístico (clock injetado do CLI), --no-memory-write desliga, o dry-run offline NUNCA escreve, e falha de escrita não quebra o turno.Com o offlineConnectorProvider, o que acontece com cada connector DECLARADO?
resolveEmployeeConnectors devolve {wired, unwired} com ordem mantida e de-dupe — "NEVER silently dropped" (packages/hermes/src/employee/connectors.ts:14 e :67-75). O provider offline é HONESTO: sem adapter real (OAuth/keys são founder-gated, fora do seam), tudo reporta unwired.No employee explain, o que as tags observed / inferred / unknown garantem?
observed (lido da config do employee), inferred (default real do engine) ou unknown (interno não-inspecionável) — packages/hermes/src/employee/introspect.ts:51-52. E o explain NUNCA afirma que A3 runtime ou A4 runner "estão operacionais" — subsistema não construído não vira promessa.O que employee schedule --out gera a partir de schedule[]?
schedule[i] vira UM AutomationManifest com id determinístico emp-<id>-<i> (apps/cli/src/employee-schedule.ts:75), o cron carregado como rrule opaco e status: 'PAUSED' (:42) — registrável mas spend-safe, nunca auto-roda. Default = só IMPRIME; --out escreve <dir>/<id>/automation.toml, exatamente o que automation list --dir lê de volta.Um manifest roda via automation run --online com o prompt "varra os repos e liste os arquivos novos". O relatório volta detalhado. Qual é a leitura correta?
--online honesto faz: roda o turno e appenda 1 registro real ao journal memory.md (PR #159; dry-run default; NÃO é daemon — PAUSED só roda à mão).Por que re-rodar alembic import <sessões> --write não duplica o transcript?
packages/hermes/src/memory/transcript-import.ts:74), o at vem do START TIME da fonte (nunca Date.now) e o --write appenda só os NOVOS após dedupe-by-id. Default é dry-run $0; --format é inferido do path e o caso ambíguo falha fechado.O que impede um registro destilado (--distill --online) de passar por fato?
session:<id> + distilled:<modelId> (tags com essa cara vindas do MODELO são STRIPPED — origem não se spoofa), e todo semântico sai com DISTILLED_MEMORY_CONFIDENCE = 0.4 (packages/hermes/src/memory/session-distill.ts:66, clamp ≤ 0.5). Resposta malformada/vazia ⇒ resultado VAZIO; --distill sem --online falha fechado; ids distill-<agent>-<sessionId>-sem|dec-<n> mantêm o write idempotente.PAUSED; A4c roda um por vez com journal honesto; A4b importa fatos e marca interpretações com ≤ 0.5. Autonomia cresce SEM inflar a verdade.# o ciclo A4b completo, spend-safe em cada degrau alembic import ~/.claude/projects/<proj> --agent revisor # dry-run: conta, não escreve alembic import ~/.claude/projects/<proj> --agent revisor --write # appenda só os NOVOS (dedupe-by-id) alembic import ~/.claude/projects/<proj> --agent revisor --distill --online # computa, NÃO persiste alembic import ~/.claude/projects/<proj> --agent revisor --distill --online --write # persiste sem/dec (≤0.5) alembic memory semantic list --limit 5 # confira: associations trazem session: + distilled: # A4/A4c alembic employee schedule <id> --out ~/.codex/automations # manifests PAUSED emp-<id>-<i> alembic automation list