AI Employees: o domínio A1–A5

Um AI Employee do Alembic não é um novo runtime: é uma camada de composição sobre coisas que o motor já tinha. O schema diz tudo — employeeDefinitionSchema (packages/hermes/src/employee/employee.ts:95) compõe: um soul (identidade + modelPreferences), uma lista de skills (nomes resolvidos no SkillStore), um memory binding opcional (quais dos 5 substores este funcionário lê), e DECLARAÇÕES de connectors e schedule — que outros seams (A3, A4) fiam depois. O comentário do próprio arquivo: "it adds no behaviour to any of them".

O acervo real de hoje: 43 AI Employees em ~/.alembic/employees e 148 skills no SkillStore ~/.hermes/skills.

Pense como… uma ficha de contratação: nome e valores (soul), cursos que a pessoa fez (skills), o caderno que ela pode consultar (memory binding), os crachás de acesso que ela PEDIU mas ainda não recebeu (connectors) e a agenda combinada (schedule). A analogia quebra num ponto: o funcionário de verdade lembra sozinho — aqui, só entra na cabeça dele o substore explicitamente bindado.

Tudo que o employee É converge para UMA string: o system prompt do turno. renderEmployeePrompt (employee.ts:208) lidera com o soul e lista skills/connectors; assembleSystemPrompt (run.ts:249) apensa ## Skill Playbooks (os CORPOS das skills) e ## Memory (só substores bindados) — playbooks antes da memória: conhecimento operacional primeiro, recall por turno depois.

Toda a superfície do domínio no CLI é alembic employee <ação>. Seis ações, todas offline/$0 por default — só run --online chama modelo.

explain responde "como ESTE employee transformaria ESTE goal em ação verificável" — em 10 passos canônicos (executionStepKindSchema, introspect.ts:36): message-to-task → context-assembly → planning → tool-use → verification → output → memory-update → report → next-loop → failure-recovery. O truque não é o mapa: é que cada claim carrega uma tag de confiança (introspect.ts:55).

observed lido da config DESTE employee · inferred comportamento default real do motor · unknown um interno verdadeiro não-inspecionável (ex.: o CONTEÚDO de um store).

Pense como… um laudo pericial: o perito separa "eu vi" (observed), "pela mecânica, deve ter sido assim" (inferred) e "não dá para saber daqui" (unknown). Quebra onde? O perito pode errar a tag; aqui a tag é imposta pelo schema — um claim sem tag nem compila.

alembic employee run <id> --goal "…" tem DOIS modos, e o default nunca gasta. Sem flag: runEmployeeRunOffline (apps/cli/src/commands.ts:5163) monta via buildEmployeeRunInput (run.ts:112, PURO/determinístico — requestId = employee-<id>) e IMPRIME o preview spend-safe: o prompt que SERIA enviado + o modelId resolvido (primary ?? fallback ?? local-default; sem nenhum dos três ⇒ err, run.ts:119). NENHUM modelo é chamado.

Com --online (founder-gated): runEmployeeTurnOnline (commands.ts:5219) constrói o adapter real do gateway com preflight — gateway/token ausente ⇒ falha fechada, SEM gasto — e o turno vira runEmployeeTurn (run.ts:151): compõe memória (best-effort, memória nunca quebra o turno), compõe playbooks, chama adapter.run(input) e valida o resultado.

Depois de um turno --online bem-sucedido, recordEmployeeTurn (writeback.ts:74) apensa UM registro episódico honesto: episode = o goal REAL verbatim (writeback.ts:92), context = excerto REAL da resposta do modelo, truncado em WRITEBACK_CONTEXT_MAX = 500 chars (writeback.ts:50). NUNCA um "learning" fabricado. Opt-in: sem binding episodic ⇒ no-op ok(false) (writeback.ts:81). Determinístico: at vem do clock injetado do CLI; id = writeback-<employeeId>-<at> (writeback.ts:89). E uma falha de escrita NUNCA quebra o turno (writeback.ts:102-107).

Isso não é teoria: o primeiro registro episódico da história do motor foi gravado em 06-07, pelo employee failure-historian. Ele está em ~/.alembic/memory/episodic.jsonl — exatamente 1 linha, com o formato de id do writeback.ts:

A4: alembic employee schedule <id> mapeia cada schedule[i] = {task, cron} para um manifest @alembic/automation via employeeToAutomations (apps/cli/src/employee-schedule.ts:111 — PURO, fail-closed). Id determinístico emp-<id>-<i>, o cron viaja como rrule opaco, e o status nasce PAUSED (employee-schedule.ts:42) — registrável mas spend-safe: nunca auto-roda. Default = IMPRIMIR; --out <dir> escreve <dir>/<id>/automation.toml, o exato formato que alembic automation list --dir relê.

A4c (PR #159): alembic automation run <id> EXECUTA um manifest — dry-run default; --online roda o turno e apensa 1 registro honesto ao journal memory.md da automation. O journal já é um tipo de primeira classe: JOURNAL_FILENAME = 'memory.md' + AutomationJournal append-only (packages/automation/src/journal.ts:35) — o análogo tipado do memory.md que as automations codex acumulam por run. O 1º registro real desse journal também é de 06-07. Não é daemon: PAUSED só roda à mão.

Pense como… pendurar o crachá do funcionário no relógio de ponto (A4) com o ponteiro TRAVADO em pausa — e o A4c é você girar a manivela UMA vez, à mão, e o relógio carimbar a ficha (journal). A analogia quebra: relógio de verdade anda sozinho; aqui, de propósito, não existe daemon.

Honestidade final, provada na fronteira: o turno do employee NÃO tem tool-loop. O modelo recebe prompt e devolve texto — ele não pode LER arquivo, rodar comando, varrer diretório. Se o goal pede "varra X e liste o que achar", a resposta vem com uma varredura FABRICADA (isso foi testado e provado; está no spec do curso como caveat oficial).

A regra operacional até a perna tool-loop existir: dados verificados vão NO PROMPT. É exatamente o que o goal do 1º registro episódico fez — repare no texto real: "DADOS VERIFICADOS (auditoria 06-07): (1)… (2)… (3)…". O operador auditou fora, colou os fatos, e pediu ao modelo só o que modelo faz bem: sintetizar e propor.