Passo 3 · Avaliação & Prática · Avaliação & Prática · Quiz — AI Employees
Learn Alembic Complete v3 · Visual Course

Quiz — AI Employees

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.

produto · 0005-ai-employee · s1
Você sai daqui sabendo
  • Desenhar de cabeça o que ENTRA no prompt de um employee (e o que fica de fora por não ser bindado).
  • Explicar por que o A3b nunca grava "aprendizados" — e por que o turno atual FABULA varreduras.
  • Distinguir fato de interpretação: transcript importado vs registro model-distilled ≤ 0.5.
Fonte da verdade

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.

1

Anatomia do employee


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.

EMPLOYEE = SOUL + SKILLS + MEMORY BINDING + DECLARAÇÕES SOUL identidade + model preferences (primary → fallback → local) SKILLS playbooks INTEIROS no prompt via SkillStore (composeSkillsText) MEMORY BINDING só substores BINDADOS entram; um não-bindado NUNCA vaza no turno DECLARAÇÕES connectors → unwired schedule → PAUSED (seams A3 / A4) renderEmployeePrompt soul + ## Skills + ## Skill Playbooks + ## Memory default: dry-run $0 (imprime o prompt; NENHUM modelo) --online (founder-gated) → ModelAdapter → A3b write-back
Quatro entradas, um prompt, um default que não gasta. As linhas tracejadas são DECLARAÇÃO, não fio ligado.
Camada técnica
# 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)
2

As 10 perguntas


Placar cumulativo no fim. O tema de fundo é um só: honestidade estrutural — o sistema é desenhado para não conseguir mentir sobre o que fez.

Prova — AI Employees (A1–A5 + A4b + A4c)
Pergunta 1/10 · composição

O que um AI Employee COMPÕE, na definição do domínio?

Employee é COMPOSIÇÃO do que já existe: soul (identidade + modelPreferences), skills, binding de memória e DECLARAÇÕES de connector/schedule — os seams A3 (connector) e A4 (scheduler) é que as ligam depois. Nada de fine-tune, nada de daemon. Âncora: packages/hermes/src/employee/employee.ts + alembic employee show <id>.
Pergunta 2/10 · binding de memória

O employee binda só episodic e semantic. O que o turno enxerga do multi-store?

O binding é um contrato de visibilidade: 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.
Pergunta 3/10 · skill playbooks

Como as skills bindadas participam do prompt do employee?

É a diferença entre VER nomes e SEGUIR regras: 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.
Pergunta 4/10 · A3b

Após um turno --online bem-sucedido, o que o A3b escreve?

O A3b (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.
Pergunta 5/10 · connectors (A3)

Com o offlineConnectorProvider, o que acontece com cada connector DECLARADO?

O seam A3 resolve declarações em portas: 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.
Pergunta 6/10 · explain

No employee explain, o que as tags observed / inferred / unknown garantem?

Anti-fabricação ESTRUTURAL: cada claim dos 10 passos canônicos carrega 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.
Pergunta 7/10 · A4 schedule

O que employee schedule --out gera a partir de schedule[]?

A4 MAPEIA, não roda: cada 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.
Pergunta 8/10 · A4c + fabricação

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?

Caveat de honestidade PROVADO na fronteira: o turno do A4c não tem tool-loop — pedir "varra X" produz uma varredura fabricada com cara de real. Até a perna tool-loop existir, dados verificados entram NO prompt. O que o --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).
Pergunta 9/10 · A4b import

Por que re-rodar alembic import <sessões> --write não duplica o transcript?

Idempotência por construção: cada turno vira um registro com id determinístico que inclui o agent (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.
Pergunta 10/10 · distill ≤ 0.5

O que impede um registro destilado (--distill --online) de passar por fato?

Destilação é INTERPRETAÇÃO, nunca ground truth: todo registro carrega 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.
Acertos: 0/10
3

A régua da honestidade


0
AI Employees em ~/.alembic/employees
0
skills no SkillStore ~/.hermes/skills
0.4
confidence fixa de TODO semântico destilado (≤ 0.5)
1
registro episódico honesto por turno --online (A3b)
produto · 0005-ai-employee · s3
A3b — O QUE PODE E O QUE NUNCA PODE SER ESCRITO turno --online SUCEDIDO (dry-run offline: NUNCA escreve) episodic BINDADO? não → no-op (opt-in) --no-memory-write → no-op 1 registro honesto episode = goal REAL context = excerpt REAL PODE: o que aconteceu de verdade goal enviado · excerpt da resposta · clock injetado falha de escrita: loga e NÃO quebra o turno NUNCA: o que soaria bem "learning" sintetizado · claim de ação sem tool-loop confidence alta em interpretação · tag distilled: spoofada a mesma régua vale no A4c (journal memory.md) e no A4b (--distill ≤ 0.5)
Grave o contraste: o lado verde registra o que HOUVE; o lado tracejado é o que o desenho torna impossível.
Síntese do domínio: A1 compõe o prompt; A3 revela o que está unwired; A3b grava só o que houve; A4 entrega manifests 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.
Camada técnica
# 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
Se errou a 8, releia o caveat: é a pergunta que separa quem opera de quem torce. Próxima parada: o Glossário visual — 24 termos da casa com um ícone-diagrama cada.