O harness
da Anthropic

O que é, de fato, um harness

— e por que Claude Code, a CLI que você usa todo dia, não é o modelo. É a casca que permite o modelo operar.

Antes de qualquer coisa, uma confissão de método: o termo "harness" não é completamente padronizado na literatura de ML. A Anthropic usa ele bastante nos posts de engenharia — especialmente no Effective harnesses for long-running agents e no mais recente Harness design for long-running application development — para se referir ao conjunto do que cerca o modelo durante execução: a loop principal, o system prompt, as tools disponíveis, como o context window é gerenciado, e a lógica que decide quando compactar, resetar, ou passar trabalho pra outro agente.

Uma analogia útil, admitidamente imperfeita: harness é o cockpit do piloto. O piloto (o modelo — Opus, Sonnet, Haiku) é o que toma decisões; o cockpit é tudo ao redor que converte essas decisões em controle da aeronave: manche (tools), tela de instrumentos (context), rádio (stdout/stderr), piloto automático (compaction), ejetor de emergência (context reset). Trocar o piloto sem mexer no cockpit — você tem um piloto melhor; trocar o cockpit sem mexer no piloto — você ainda tem o mesmo piloto, só que com mais ou menos alavancas.

Dito isso, o Claude Code — a CLI que roda no seu terminal, que está interpretando este texto neste instante — é um harness específico, opinado, construído pela Anthropic em cima dos modelos Claude. Ele expõe um conjunto finito de mecanismos para você moldar o comportamento. Essa Parte 1 inventaria esses mecanismos, um por um, com evidência (arquivo:linha quando possível) e sem fingir certeza onde não temos.

Os cinco elementos que compõem o harness

Combinando a leitura dos posts de engenharia e a observação direta do comportamento do Claude Code, um harness tem cinco peças. Se alguma delas não existir, você ainda tem um chatbot — não um agente.

Inferência minha, vale explicitar: a Anthropic raramente usa essa lista de cinco itens com essa exata taxonomia. É como eu condensei, a partir dos artigos. (Veja §02 pra context management, §05 pra sub-agents, §06 pra hooks — cada uma dessas peças tem camadas que o harness do Claude Code expande.)

Context window + compaction

— o recurso mais escasso do harness, e o que toda decisão de design tenta preservar.

O context window é o cérebro de curto prazo do modelo. Todo token que entra ali — system prompt, histórico, tool results, file reads, CLAUDE.md — consome orçamento. Os modelos Opus 4.7 atingem 1 milhão de tokens (o badge do rodapé mostra isso: Opus 4.7 (1M context)); modelos anteriores tipicamente 200k. Mas capacidade não é gratuita.

Isso é o que a Anthropic chama de context rot — a decadência atencional que ocorre à medida que a janela se enche. A causa é arquitetural: transformers criam n² relações par-a-par entre tokens; quando n cresce, a atenção fica diluída e o modelo perde capacidade de recuperar a informação certa no momento certo. (Fonte: raw-anthropic-context-engineering.md:28–36.)

O que o Claude Code faz sobre isso

O harness nativo combina três estratégias (a Anthropic documenta todas em effective-context-engineering-for-ai-agents):

1. Compaction — quando a janela se aproxima do limite, o próprio modelo resume o histórico em uma versão condensada e recomeça com ela + os 5 arquivos mais recentemente acessados. O agente segue a mesma sessão com histórico comprimido. (Continuidade preservada; ansiedade de contexto não necessariamente removida.)
2. Context resets — descartar a janela inteira, preservar estado em arquivos (handoff), reiniciar agente do zero. Usado quando a continuidade importa menos que o frescor. A Harness design… menciona que Opus 4.6 reduziu a necessidade disso, pois o modelo passou a sustentar tarefas longas sem "ansiedade".
3. Just-in-time retrieval — em vez de carregar tudo pré-inferência, o agente mantém identificadores leves (paths, queries) e puxa conteúdo via tools (Read, Grep, Glob) quando precisa. É por isso que Claude Code prefere Grep a abrir 50 arquivos: cada arquivo aberto é tokens que depois vão pesar.

Precedência do que fica na janela

O harness monta o contexto em camadas. A ordem típica (inferência a partir do que observo e do que a Anthropic documenta):

Quando compaction ocorre, o item 6 é o que é resumido primeiro; itens 1–5 são mantidos integrais porque mudam as regras do jogo. Isso é inferência minha sobre o comportamento observado — a Anthropic não publica uma tabela de precedência pública.

Slash commands

— as macros do usuário. Uma pasta, um arquivo .md, e um prefixo /.

Slash commands são o mecanismo mais simples que o Claude Code oferece para o usuário empacotar prompts reutilizáveis. A definição vive em .claude/commands/<nome>.md — dois escopos: projeto (/Users/italo/italo_gustavo/.claude/commands/) e user-global (/Users/italo/.claude/commands/). Subpastas criam namespaces: .claude/commands/AIOX/init.md vira /AIOX:init.

Formato

Arquivo Markdown com frontmatter YAML opcional. O corpo do arquivo é o prompt que será injetado na conversa quando o usuário invocar. Exemplo real do seu codebase, em /Users/italo/italo_gustavo/.claude/commands/greet.md:

# greet

Generate contextual agent greeting using GreetingBuilder infrastructure.

---

## What This Command Does

When activated, this command:
1. Loads the GreetingBuilder module from
   `.aiox-core/development/scripts/greeting-builder.js`
2. Extracts agent definition from the calling agent (name, icon, persona_profile, commands)
3. Analyzes conversation history to detect session type (new/existing/workflow)
4. Generates intelligent greeting based on: ...

Esse arquivo não "faz" nada sozinho. Quando o usuário digita /greet, o harness lê o arquivo e injeta seu conteúdo como se fosse a próxima mensagem do usuário (ou algo equivalente — o comportamento exato varia).

Exemplos reais do seu setup

Listando /Users/italo/.claude/commands/ (user-global) e /Users/italo/italo_gustavo/.claude/commands/ (projeto), existem hoje:

O comando nativo /init é um bom exemplo de referência: a Anthropic embute alguns slash commands no próprio binário — não ficam em arquivos, mas se comportam identicamente ao usuário. /help, /clear, /compact, /model, /login entram nessa categoria. A documentação diz textualmente: não invoque skills para essas CLI built-ins.

Limitações que importam

• Sem auto-descoberta pelo modelo. Se você tem /deploy disponível, o modelo só sabe disso se você (ou a UI) mencionar. Contraste com Skills (§04), que se "anunciam" via descrição no frontmatter.
• Inchaço de tokens quando grandes. Um comando de 20 KB (como /mega-brain no seu caso) injeta o arquivo inteiro no contexto toda vez que invocado. Se for complexo, considere transformá-lo em Skill — a Skill tem carregamento lazy (§04).
• Sem empacotamento. Slash commands são só um arquivo .md. Scripts, templates ou assets ficam fora — você os referencia por path, mas eles não "vêm junto" com o comando. Skills podem empacotar tudo isso.

Skills

— o equivalente a plugins. Uma pasta, um SKILL.md, e — aí a diferença — o modelo as descobre sozinho.

Skills são a evolução de slash commands quando você precisa de três coisas que slash commands não dão bem: auto-descoberta (o modelo saber quando chamar), lazy loading (não gastar tokens com skills que não são ativadas), e empacotamento (trazer scripts, templates, assets junto).

Formato

Cada skill vive em uma pasta com um arquivo SKILL.md na raiz. O frontmatter YAML é agora obrigatório (diferente de slash commands): contém pelo menos name e description. A description é o que o modelo lê — é o pitch que faz a skill se auto-anunciar.

---
name: graphify
description: any input (code, docs, papers, images) → knowledge graph → clustered communities → HTML + JSON + audit report
trigger: /graphify
---

# /graphify

Turn any folder of files into a navigable knowledge graph with community
detection, an honest audit trail, and three outputs: interactive HTML,
GraphRAG-ready JSON, and a plain-language GRAPH_REPORT.md.

## Prerequisites
...
## Workflow
...
## Examples
...

Acima: cabeçalho real de /Users/italo/.claude/skills/graphify/SKILL.md (arquivo completo: 55.6 KB, 1336 linhas). O frontmatter tem 3 campos; o corpo é o conteúdo substantivo que só é carregado se a skill for ativada.

Duas mecânicas-chave

1. Auto-descoberta. Quando uma sessão inicia, o harness lista as skills disponíveis (nomes + descrições) na janela do modelo — você vê isso em <system-reminder> blocks. O modelo, ao ler o prompt do usuário, compara com as descrições e decide se deve chamar alguma. Frameworks mais antigos te obrigavam a declarar explicitamente qual plugin usar; Skills inverteu: descreva bem o quando, o modelo decide.
2. Lazy loading (just-in-time). O corpo do SKILL.md — que pode ter dezenas de KB — só carrega quando a skill é ativada. Antes disso, só nome + descrição ocupam tokens. Contraste com slash commands: o conteúdo do comando entra inteiro toda invocação.

O que uma skill pode empacotar

A pasta da skill pode conter além do SKILL.md:

• Scripts (Python, Bash, Node) que o modelo executará via Bash tool
• Templates (HTML, Markdown, YAML) para copiar/preencher
• Assets (imagens, fontes, arquivos de exemplo)
• Arquivos LICENSE.txt, README.md (não entram no contexto do modelo — ficam no filesystem)

Exemplo: a skill graphify embute scripts Python que extraem, detectam comunidades e renderizam o grafo. O SKILL.md diz "rode python scripts/extract.py com esses args" — e o modelo usa o Bash tool.

Skills reais no seu setup

Listando /Users/italo/.claude/skills/ (user-global) e /Users/italo/italo_gustavo/.claude/skills/ (projeto):

Como se inscrever visualmente

Quando o usuário diz algo como "Cria um grafo desses papers", o modelo compara com as descriptions em memória e pode:

1. Sugerir ao usuário invocar /graphify (recomendação verbal)
2. Invocar diretamente via Skill tool (se tiver permissão) — isso carrega o SKILL.md inteiro no contexto
3. Rodar os scripts embutidos via Bash seguindo as instruções do SKILL.md

Sub-agents

— o jeito nativo de paralelizar e isolar trabalho. Contextos novos para cada tarefa, resultados que voltam condensados.

Quando o Claude Code precisa fazer algo que vai consumir muito contexto — pesquisa em dezenas de arquivos, implementação de múltiplas features — ele tem a opção de delegar para sub-agents. A Agent tool aceita um subagent_type e um prompt, e spawna um novo agente com janela de contexto própria.

O que é nativamente oferecido

• Tipos built-in: general-purpose (investigação ampla), Explore (read-only, mapeamento de codebase), Plan (decomposição de trabalho em steps). Projetos podem definir tipos adicionais.
• Contexto isolado (fresh window): o sub-agent não "vê" o histórico do parent. Recebe apenas o prompt que o parent passa. Ao terminar, devolve uma string (o que o modelo escolheu como resumo), que aparece ao parent como resultado da tool call.
• Isolation de filesystem: com isolation: "worktree", o harness cria um git worktree novo, checkout em branch isolado, e o sub-agent opera lá. Commits do sub-agent não colidem com commits do parent. (Esse é justamente o worktree em que este texto está sendo gerado — veja o path: /Users/italo/italo_gustavo/.claude/worktrees/agent-a9bee114.)
• Resultado volta condensado: por padrão o sub-agent escreve um "final message" que o parent recebe como texto. Isso é o que o post de context engineering chama de "distilled summary".

O padrão mental

Parent combina os resumos e toma decisões. Nenhum sub-agent tem memória de outro. É deliberado: quanto maior a isolação, menor o contaminação cruzada.

Limitações reais

• Sem memória cross-sub-agent: nenhum sub-agent sabe o que o outro descobriu. Se precisar, o parent tem que passar no prompt (ou via arquivos no filesystem).
• Parent espera: quando o parent chama Agent, ele fica bloqueado até o sub-agent retornar (exceto em modo paralelo). Parelelismo é conseguido disparando múltiplas Agent calls no mesmo bloco de tool calls.
• Race conditions com worktree: isolation resolve o caso do filesystem, mas não isola portas, containers Docker, bancos de dados compartilhados. (A sua regra em parallel-subagent-isolation.md cobre exatamente isso — é uma rule criada depois de um incidente real.)

Hooks

— o único lugar onde você injeta lógica imperativa no harness. O modelo pede algo, o hook decide se passa.

Hooks são scripts externos (shell, Node, Python) que o harness executa em pontos específicos do loop. Essa é a ponte entre o modelo (declarativo, textual) e o mundo determinístico (código). Se você precisa garantir que algo sempre aconteça — independente do modelo "lembrar" — hooks são o mecanismo.

Registro

Hooks são declarados em settings.json, no campo hooks, estruturado por evento. Veja o seu ~/.claude/settings.json:

"hooks": {
  "SessionStart": [
    { "hooks": [ { "type": "command", "command": "~/.claude/hooks/kill-orphan-mcps.sh" } ] }
  ],
  "PreToolUse": [
    {
      "matcher": "Bash",
      "hooks": [
        { "type": "command", "command": "~/.claude/hooks/rtk-rewrite.sh" },
        { "type": "command", "command": "~/.claude/hooks/port-check.sh" }
      ]
    },
    {
      "matcher": "WebFetch",
      "hooks": [
        { "type": "command", "command": "~/.claude/hooks/jina-webfetch-router.cjs" }
      ]
    }
  ],
  "Stop": [...]
}

Tipos de evento

A Anthropic publica a lista oficial em docs.claude.com/en/docs/claude-code/hooks. A tabela acima reflete o conjunto que observo usado hoje na prática — pode haver outros eventos introduzidos em versões recentes. Inferência: a lista cresce com o tempo, então confirmar a doc antes de escrever hook novo.

Protocolo de I/O

O harness executa o hook e passa o contexto via stdin em JSON. O hook responde via stdout em JSON, e exit code. Semântica típica:

A forma moderna — que a própria doc recomenda desde 2025 — é usar exit 0 sempre e retornar no stdout um JSON como:

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "WebFetch auto-summarises content; use Jina Reader for full/raw text..."
  }
}

permissionDecision aceita: "allow", "deny", (ou omitir, deixando o fluxo default). Quando deny retorna, o harness mostra a permissionDecisionReason para o modelo — que então tem chance de reagir (ex: trocar de estratégia, explicar ao usuário).

function emit(permissionDecision, permissionDecisionReason) {
  process.stdout.write(
    JSON.stringify({
      hookSpecificOutput: {
        hookEventName: "PreToolUse",
        permissionDecision,
        permissionDecisionReason,
      },
    })
  );
  process.exit(0);
}

Casos de uso reais

Três hooks do seu setup pessoal ilustram tipos comuns:

• jina-webfetch-router.cjs (PreToolUse, matcher WebFetch) — intercepta toda WebFetch call, nega por padrão, diz ao modelo pra usar curl r.jina.ai em vez disso. Allowlist para localhost/privados. Bypass via env CLAUDE_WEBFETCH_ALLOW=1.
• port-check.sh (PreToolUse, matcher Bash) — detecta padrões de server-start em comandos Bash, verifica se a porta está em LISTEN, bloqueia se colidir. Criado depois de um incidente em 16/04/2026 — está documentado na rule port-availability.md.
• kill-orphan-mcps.sh (SessionStart + Stop) — housekeeping. Ao iniciar, mata processos MCP órfãos. Ao parar, idem. Ciclo de vida limpo.

settings.json

— o ponto único onde você configura o harness. Tudo que o Claude Code "lembra" sem perguntar mora aqui.

Três arquivos, três escopos, uma regra de precedência:

Local override projeto override user. Isso é importante: você pode ter defaultMode: "bypassPermissions" no user global (pra conveniência pessoal), mas um projeto específico pode forçar defaultMode: "default" no settings comitado — o projeto vence.

Os campos principais

Exemplo real — seu user settings

{
  "permissions": {
    "deny": [],
    "defaultMode": "bypassPermissions"
  },
  "env": {
    "CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING": "1",
    "CLAUDE_CODE_EFFORT_LEVEL": "max",
    "MAX_THINKING_TOKENS": "64000"
  },
  "hooks": { ... },
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline.sh"
  },
  "alwaysThinkingEnabled": true,
  "effortLevel": "xhigh",
  "autoMemoryEnabled": true
}

/Users/italo/.claude/settings.json — arquivo completo tem 95 linhas.

O que NÃO mora aqui

• Instruções em prosa ao modelo → vão em CLAUDE.md
• Regras carregáveis por path-match → vão em .claude/rules/*.md
• Prompts reutilizáveis → slash commands (§03) ou skills (§04)
• Configuração de MCP servers → geralmente em arquivo próprio .mcp.json ou no settings, dependendo da versão

Memory system

— o caderno de anotações que o agente carrega entre sessões. Não é o histórico; é o que ele escolheu guardar.

Memory é uma feature relativamente recente do Claude Code. A ideia vem direto de Effective context engineering for AI agents (seção Structured note-taking, raw-anthropic-context-engineering.md:100–110): dar ao agente um filesystem persistente onde ele registra o que descobriu, para que futuras sessões possam recuperar sem releer tudo.

Localização

Nativamente, a Anthropic organiza memória por projeto, em ~/.claude/projects/<slug-do-projeto>/memory/. O slug é derivado do path absoluto do projeto (trocando / por -). No seu caso:

/Users/italo/.claude/projects/-Users-italo-italo-gustavo/memory/
├── MEMORY.md                      ← index
├── feedback_aiox_agents_opus.md   ← uma entrada
└── feedback_git_remote_policy.md  ← outra entrada

O formato do MEMORY.md

MEMORY.md é o index: lista de itens com link para o arquivo detalhado + um resumo de uma linha. O modelo lê o index; se um item for relevante, abre o arquivo referenciado. Exemplo real do seu projeto:

- [All AIOX agents must use Opus](feedback_aiox_agents_opus.md) — CTO directive
  2026-04-15: every squad agent (registry model, agent .md model_tier) defaults
  to Opus, not Haiku/Sonnet
- [Git push policy — private only](feedback_git_remote_policy.md) — always push
  to `private` (contatoitalo/aiox-business), never to origin/italo_gustavo upstream

/Users/italo/.claude/projects/-Users-italo-italo-gustavo/memory/MEMORY.md:1–2

Tipos de entrada

A Anthropic menciona convenções para os prefixos dos arquivos. Pelo que observo e o que a doc sugere:

Inferência: a doc oficial lista esses tipos, mas convenções de nomeação evoluíram. O que importa é que o MEMORY.md linke cada um com um resumo claro — o modelo toma decisões a partir do index, não dos arquivos individuais.

Descoberta automática

Quando autoMemoryEnabled: true está setado em settings.json (seu caso), o harness:

1. Localiza o diretório memory do projeto ativo (pelo cwd)
2. Injeta o conteúdo de MEMORY.md no contexto inicial
3. Permite ao modelo ler/escrever arquivos em memory/ ao longo da sessão
4. Ao final da sessão, pode compactar aprendizados em novas entradas (via hooks de Stop ou comandos do próprio modelo)

Por que isso importa

Sem memória, cada sessão começa do zero. Toda correção que você dá ("não use whisper, use VibeVoice", "sempre commit em branch do worktree") é esquecida. Memory transforma o agente de uma amnesic tool em algo que acumula aprendizado. É pequeno em disk — uns kilobytes — mas grande em comportamento ao longo de semanas.

MCP

— o jeito padrão de o Claude falar com o resto do mundo. Não é uma feature; é um protocolo.

Model Context Protocol é a padronização que a Anthropic publicou em 2025 para o problema "como um LLM fala com sistemas externos de forma interoperável". Antes do MCP, cada framework tinha seu jeito (ChatGPT plugins, LangChain tools, bespoke integrations). MCP virou o USB-C: um protocolo de client/server sobre JSON-RPC que qualquer runtime pode implementar.

Do ponto de vista do Claude Code, MCP significa duas coisas:

1. Claude Code é um MCP client. Ele se conecta a MCP servers (processos separados — geralmente node ou python — que implementam o protocolo).
2. Tools de MCP servers aparecem como tools nativas. O harness expõe cada tool MCP com o prefixo mcp__<servidor>__<tool>. O modelo chama como chamaria qualquer tool. Ex: mcp__chrome-devtools__take_screenshot.

Exemplos de servidores MCP

Na sessão presente temos vários servidores MCP disponíveis. A lista completa vem via system-reminder, mas destaco alguns:

Configuração

MCP servers são configurados via CLI (claude mcp add …) ou em arquivo. O Claude Code lê .mcp.json no projeto, e ~/.claude.json no user global. Cada servidor declara: tipo de transport (stdio, HTTP SSE), comando pra spawn, env vars, e a lista de tools é descoberta pelo próprio Claude via handshake do protocolo.

Por que MCP é importante

Sem MCP, cada integração externa demanda modificar o próprio Claude Code (ou um wrapper). Com MCP:

• Você escreve um servidor MCP uma vez — pode usar ele com Claude, Cursor, outras IDEs que suportam o protocolo
• O ecossistema compartilha servidores (há dezenas publicados abertamente)
• Updates de ferramentas não exigem novo release do Claude Code — só do servidor

Inferência técnica: embora MCP seja um protocolo aberto, quanto da implementação client interna do Claude Code seja realmente pública/extensível é menos claro. A spec do protocolo está em modelcontextprotocol.io.

Permission modes

— quatro perfis de "o quão autônomo o agente opera". Trocar de modo muda o fluxo, não o modelo.

O harness tem quatro modos de permissão. O modo controla como o Claude Code lida com cada tool call potencialmente arriscada (Bash, Edit, Write, Delete). Você pode trocar no meio da sessão via UI ou CLI.

Controle fino: allow/deny em settings

Independente do modo, permissions.allow e permissions.deny em settings.json dão controle por padrão de tool call. Exemplo real do seu settings.local.json:

{
  "permissions": {
    "allow": [
      "Bash(mkdir -p .claude/commands/Support/agents)",
      "Bash(cp squads/aiox-support-squad/agents/*.md .claude/commands/Support/agents/)",
      "Bash(rtk ls *)"
    ]
  }
}

/Users/italo/italo_gustavo/.claude/settings.local.json:1–10

Com esses allows, mesmo em modo default o Claude não precisa pedir permissão para esses comandos específicos. É a forma certa de reduzir interrupção sem desligar permissions completamente.

Todo list tool

— a forma nativa de mostrar progresso. Pequena, simples, boa no que faz.

O Claude Code expõe uma tool — historicamente chamada TodoWrite — que o agente usa para manter uma lista de tarefas visível no UI do usuário. Não é uma feature sofisticada; é um buffer JSON com três campos por item: content, status, activeForm.

A mecânica é simbiótica: o agente, ao receber uma tarefa complexa, decompõe em 3–7 itens, marca cada um como in_progress enquanto trabalha, e completed ao terminar. O usuário vê isso no UI como checklist ao vivo. É ao mesmo tempo ferramenta do agente e telemetria do usuário.

Por que existe

Duas razões, ambas mencionadas em Effective context engineering for AI agents:

• Ajuda o modelo a se manter coerente em tarefas longas. Escrever "TODO 1: fazer X" ocupa um turno, mas dá âncora para o modelo retomar depois de tool calls.
• Transparência pro usuário. O usuário vê o plano sendo executado — sabe se o agente está no rumo certo, e pode intervir cedo.

Em documentos recentes, a Anthropic também se refere a esse mecanismo como "TaskCreate/TaskUpdate/TaskList" — provavelmente uma evolução de API (mudança de nome sem mudança conceitual). Inferência: depende da versão do Claude Code.

O que tudo isso somado significa

— e por que frameworks de agentes existem em cima disso.

Recapitulando o que o harness da Anthropic, sozinho, oferece:

Note o padrão: são primitivos. Peças pequenas, bem definidas, que compõem. Nenhuma delas, isolada, é um "framework de agentes". Juntas, dão o que a Anthropic chama em Building Effective Agents de augmented LLM: modelo + tools + memory + retrieval. Composição em vez de framework.

O que a Anthropic deliberadamente não oferece

Vale notar os vazios — não porque sejam defeitos, mas porque explicam onde frameworks emergem:

• Nenhum conceito de "agente com persona". O harness sabe invocar sub-agents, mas não tem primitivo para "este é o @dev, este é o @qa, estes são os comandos que cada um tem". Isso é convenção, não estrutura.
• Nenhum workflow engine. Não existe "primeiro rode A, depois B se A passou". Workflows são padrões que você codifica em slash commands, skills, ou em lógica externa.
• Nenhum sistema de delegação/autoridade. O harness não entende "@devops é o único que pode dar push". Você pode instruir (CLAUDE.md) ou forçar (hooks), mas a semântica tem que ser construída.
• Nenhum conceito de "story", "epic", "PRD". O harness é agnóstico a metodologia. Você pode pôr qualquer convenção de desenvolvimento em cima.

A ponte para a Parte 2

É exatamente nesse vazio deliberado — agents-com-persona, workflows, delegação, metodologia de dev — que frameworks como AIOX se instalam. Eles não substituem o harness; eles compõem em cima dele. Usam skills para empacotar agents, slash commands para comandos de persona, hooks para impor regras, memory para persistir governança, sub-agents para paralelizar trabalho.

Na Parte 2 investigaremos como esse empilhamento funciona — o que é genuinamente novo no framework, o que é reembalagem de primitivos nativos, e o que é atrito contra o harness. É aí que fica interessante.

Fim da Parte 1.
A Parte 2 começa onde esta termina — examinando o que o AIOX adiciona por cima, e o custo/benefício de cada camada.