Extracao de comportamento com workflow blueprint

Como extrair comportamento de agentes em acao e transformar em contratos reutilizaveis — modelos mentais, evidencia de execucao, e o ciclo observation-extracao-operacao.

sysadmin@srv-hermes
·
agents skills workflows behavioral-extraction mental-models

Comportamento observado, extraido como contrato, executado pelo agente. O workflow blueprint como ferramenta de captura de conhecimento operacional.

Extracao de comportamento com workflow blueprint

O post sobre agentic workflow blueprint cobriu a estrutura: roteamento, contratos, subskills, chaining. Agora vai a parte pratica — como extrair comportamento real de agentes e transformar em skill reutilizavel.

Nao se trata de documentar o que o sistema deveria fazer. Se trata de documentar o que o agente realmente fez pra resolver um problema — e transformar essa evidencia em contrato.

O que e extracao de comportamento

Quando um agente resolve um problema, ele faz um conjunto de decisoes: qual ferramenta chamar, em que ordem, quais validacoes aplicar, como lidar com falha. Esse comportamento esta embutido na execucao — nos tool calls, nos erros, nos retries.

Extracao de comportamento e o processo de:

  • Observar a execucao (ou seu resultado)
  • Identificar o pattern de decisao
  • Formalizar como contrato (SKILL.md)
  • Operar o contrato em novos contextos

O resultado nao e uma descricao de feature. E um modelo mental que o agente carrega quando precisa resolver o mesmo tipo de problema de novo.

Modelo mental como contrato

Um modelo mental e a representacao interna que o agente tem sobre como algo funciona. Sem extracao, esse conhecimento morre na conversacao — proxima sessao, o agente descobre do zero.

O workflow blueprint transforma modelo mental em arquivo:

Observacao: agente resolveu bug X usando pattern Y
Modelo mental: "todo bug de tipo A segue passos B, C, D"
Contrato: SKILL.md com Goal, Procedure, Invariants

O contrato captura:

  • Goal — o que o modelo resolve
  • Scope — quando aplica, quando nao
  • Triggers — quais sinais ativam este modelo
  • Procedure — os passos extraidos da execucao real
  • Invariants — regras descobertas na pratica (bugs conhecidos, constraints)
  • Review gate — como verificar que o modelo funcionou

Evidencia de execucao

O formato de contrato do blueprint (Goal, Scope, Triggers, Inputs, Invariants, Procedure, Outputs, Review gate, References) nao e inventado — e extraido de evidencia real.

Exemplo real do lab: o agente operando Temporal em htsrv144 descobriu que ListWorkers retorna 501 UNRESOLVED — bug do upstream, nao config. Esse comportamento virou invariant no skill:

Invariants:
- ListWorkers retorna 501 — upstream handler bug, ignora
- docker compose pra lifecycle, nunca bare docker restart

Sem extracao, esse conhecimento perde. Com contrato, o agente sabe desde o primeiro turno.

O ciclo observation-extracao-operacao

graph LR
    A[Agente opera sistema] -->|comportamento| B[Pattern identificado]
    B -->|formato contrato| C[SKILL.md criado]
    C -->|carregado por demanda| D[Agente opera proximo sistema]
    D -->|feedback/refinamento| C
    C -->|skill expandido| E[Blueprint do projeto]

Cada passo alimenta o proximo:

  1. Observacao — agente executa tarefas, encontra problemas, aplica solucoes
  2. Extracao — pattern de decisao e capturado no formato de contrato
  3. Operacao — contrato e carregado em novos contextos, validado contra evidencia real
  4. Refinamento — quando o contrato falha ou evolve, ele atualiza junto

O blueprint cresce organicamente. Nao e um documento estatico que escreve uma vez e esquece. E um sistema vivo que captura conhecimento operacional.

Subskills como decomposicao de modelos

Um modelo mental complexo decompo em subskills:

document/
  SKILL.md               <- Modelo: gerar docs a partir de evidencia
review/
  SKILL.md               <- Modelo: validar com criterios pass/fail
changelog/
  SKILL.md               <- Modelo: gerar entrada final

Cada subskill e um modelo mental separado. O agente carrega so o que precisa no momento. Quando document falha, o retry foca em document — nao reexecuta review nem changelog.

Isso e decomposicao de comportamento: um processo complexo entendido como modelos menores, cada um com seus proprios triggers, invariants e gates.

Modelos de agentes no contexto real

No syslogs, no learning system, e nos projetos ativos, a extracao segue o mesmo pattern:

  • Temporal standalone — comportamento de operacao (lifecycle do server, bugs upstream, API keys) virou skill que o agente carrega antes de operar
  • CheckoutPP — comportamento de integracao com Pagar.me v5 virou skill com autenticação, endpoints, e fallbacks
  • Apix — comportamento de workflows Temporal (Ruby SDK, task queues, head-of-line blocking) documentado como contratos executaveis

Cada skill nasceu de: agente operou, encontrou problema, resolveu, comportamento foi extraido.

O que torna o modelo reutilizavel

O contrato e reutilizavel porque e autocontido e linkavel. Nao precisa do contexto da sessao anterior. Nao precisa de explicacao adicional. O agente carrega e executa:

  • Triggers dizem quando carregar
  • Procedure diz o que fazer
  • Invariants dizem o que nunca quebrar
  • Review gate diz como saber que deu certo

Se o modelo funciona em um projeto, funciona em outro — porque o contrato e sobre comportamento, nao sobre estrutura de arquivos especifica.

Referencia