🐜 Antfarm

📄 workflow.yml ANTFARM

Define o pipeline de agentes em YAML. O OpenClaw não sabe o que é um workflow.yml — é 100% conceito do Antfarm.

O que contém:

• agents: lista de agentes com id, role, workspace files
• steps: sequência de passos, cada um executado por um agente
• input: prompt com variáveis {{task}}, {{skill_name}}
• on_fail: retry automático ou escalação para humano

id: skill-create
steps:
  - id: research
    agent: researcher
    input: |
      Research requirements for: {{task}}
      Reply with:
      STATUS: done
      SKILL_NAME: nome-da-skill
    expects: "STATUS: done"
    on_fail:
      escalate_to: human

Relação com OpenClaw: O workflow.yml é interpretado pelo Antfarm CLI, que traduz cada step em cron jobs e sessões do OpenClaw. O gateway nunca vê o YAML.

🤖 Agentes YAML FORMATO: OpenClaw → CONTEÚDO: Antfarm

Cada agente do Antfarm tem 3 arquivos Markdown — o formato é do OpenClaw, mas o conteúdo é escrito pelo Antfarm.

• AGENTS.md — Instruções operacionais + output format. Prioridade alta no prompt.
• SOUL.md — Personalidade (10-20 linhas). "Você é cético e rigoroso..."
• IDENTITY.md — Nome e role (2-5 linhas). "Name: Pesquisador"

Quando o Antfarm instala: copia esses arquivos para o workspace do agente no OpenClaw (~/.openclaw/workspaces/workflows/). A partir daí, o OpenClaw os trata como qualquer outro workspace file — injeta no prompt do LLM.

O LLM vê: o conteúdo como parte do system prompt. Não sabe que veio do Antfarm.

🗃️ antfarm.db (SQLite) ANTFARM

Banco de dados exclusivo do Antfarm. NÃO é o SQLite de memória/embeddings do OpenClaw. São bancos completamente separados.

~/.openclaw/antfarm/antfarm.db    ← ANTFARM (runs, steps, context)
~/.openclaw/memory/<id>.sqlite    ← OPENCLAW (embeddings, busca semântica)

NÃO se falam. São sistemas independentes.

Tabelas do antfarm.db:

• runs — workflow runs (id, status, context JSON, timestamps)
• steps — etapas de cada run (id, status, input, output)
• stories — user stories (para workflow feature-dev)

Context JSON: acumula KEY:VALUE de cada step completado. Quando o step 2 precisa de {{skill_name}}, o Antfarm busca no context do run.

⏰ Cron Polling (Two-Phase) ANTFARM cria → OPENCLAW executa

O Antfarm NÃO roda processos próprios. Ele registra cron jobs no OpenClaw que fazem polling a cada 5 min.

FASE 1 — PEEK (barata, ~2s)
┌─────────────────────────────────────────────┐
│ Cron dispara → OpenClaw spawna sessão       │
│ Agente executa: step peek         │
│ Resultado: NO_WORK → para. HAS_WORK → fase 2│
└─────────────────────────────────────────────┘

FASE 2 — CLAIM + TRABALHO (completa, ~1-5 min)
┌─────────────────────────────────────────────┐
│ Agente executa: step claim        │
│ Recebe: {"stepId":"...", "input":"..."}     │
│ Trabalha (sessão fresh, sem memória)        │
│ Executa: step complete              │
│ Output com KEY: VALUE → salvo no antfarm.db │
└─────────────────────────────────────────────┘

⚠️ Cada peek consome 1 chamada de API porque spawna uma sessão LLM. Com 3 agentes a cada 5 min = ~36 chamadas/hora. Crons devem ser deletados após workflow completar.

Quem faz o quê:

• Antfarm — registra crons via openclaw cron add
• OpenClaw — executa o cron, spawna a sessão, roda o agente
• Antfarm — CLI step peek/claim/complete roda dentro da sessão

📊 Dashboard :3333 ANTFARM

Web server próprio do Antfarm. NÃO é a Control UI do OpenClaw (que roda na :18789).

• Kanban board — runs movendo pelas colunas (pending → running → done)
• Detail panel — steps com status, output, timeline
• Medic — indicador de saúde (steps travados, crons órfãos)
• Auto-refresh — board a cada 30s, panel a cada 5s
• Somente leitura — não permite gerenciar crons ou editar runs pela UI

Acesso remoto: ssh -f -N -L 3333:127.0.0.1:3333 user@host → http://localhost:3333

Stack: Vanilla JS + HTML, zero dependências. Lê direto do antfarm.db.

🔗 KEY:VALUE Handoff ANTFARM

Como dados fluem entre agentes que nunca se comunicam diretamente. Cada sessão é 100% isolada.

Step 1 (Pesquisador) output:       Step 2 (Desenvolvedor) input:
────────────────────────           ─────────────────────────
STATUS: done                       SKILL_NAME: {{skill_name}}
SKILL_NAME: youtube-summary   →    SCOPE: {{scope}}
SCOPE: extrair legendas...         TOOLS_NEEDED: {{tools_needed}}
TOOLS_NEEDED: exec, read           ...

        ┌───────────────────────┐
        │   antfarm.db          │
        │   runs.context (JSON) │
        │   Acumula tudo        │
        └───────────────────────┘

1. Agente 1 termina → output com KEY: VALUE
2. Antfarm parseia as linhas KEY: VALUE do output
3. Salva no campo "context" do run no SQLite
4. Quando agente 2 é ativado, Antfarm substitui
   {{key}} no input do step pelo valor do context

O OpenClaw não participa desse handoff. É 100% lógica do Antfarm CLI. O OpenClaw só spawna as sessões — não sabe que existe um "pipeline".