O modelo de IA deixou de ser a parte mais difícil de explicar. Quase todo mundo já conversou com um. A mudança que exige atenção agora acontece ao redor do modelo: quais dados ele recebe, quais ferramentas consegue usar, onde executa, o que pode alterar, por quanto tempo mantém estado e como alguém verifica o trabalho.
Foi isso que tornou o OpenClaw um caso tão visível. Ele colocou um modelo dentro de um ambiente com arquivos, terminal, navegador, canais de mensagem, sessões e skills. Quando a IA ganha esse “corpo”, sai da resposta isolada e entra na operação. Também ganha um raio de dano.
Essa distinção resolve boa parte da confusão atual. Duas empresas podem usar o mesmo modelo e obter sistemas completamente diferentes. Uma abre um chat e copia a resposta. A outra conecta o modelo ao ERP, limita as ações por função, guarda estado e registra cada chamada. Regras verificáveis determinam o que o agente pode executar, o que deve bloquear e o que precisa encaminhar para aprovação. Logs e avaliações ajudam a propor melhorias; mudanças relevantes dependem de teste, aprovação e possibilidade de voltar à versão anterior. O raciocínio do modelo varia. Os limites de acesso precisam ser aplicados também pelo sistema que executa a ação.
Uso agent harness para nomear esse ambiente operacional. O termo ainda é pouco amigável em português, então vale uma definição direta:
Uma agent harness é o conjunto de contexto, memória, ferramentas, ambiente de execução, regras, permissões e verificações que permite a um modelo executar trabalho de forma controlada.
O modelo raciocina e escolhe ações. O ambiente operacional decide o que ele sabe, o que consegue tocar e como provamos que funcionou.
A escada de maturidade: seis formas de usar IA
Organizo o uso de IA em seis níveis para comparar alcance, continuidade e autonomia. Esta é uma classificação proposta neste artigo, não uma escala padronizada de mercado. Cada degrau amplia o que o sistema consegue fazer e exige controles proporcionais. Um produto pode combinar recursos de vários níveis.
Nível 1: conversa pontual
Você faz uma pergunta, recebe uma resposta e conduz cada próximo passo. Todo o trabalho permanece no texto. É ótimo para explorar ideias, reescrever um parágrafo, entender um conceito ou preparar uma primeira análise.
O humano transporta o contexto, confere a resposta e executa qualquer ação fora do chat. O risco operacional é baixo porque a IA quase não toca o mundo.
Nível 2: assistente contextualizado
Você fornece documentos, exemplos, regras e um critério de sucesso. Um GPT configurado para uma área entra aqui: ele pode ter instruções próprias, arquivos de conhecimento e capacidades selecionadas. A documentação da OpenAI também permite apps ou Actions para conectar APIs.
O ganho vem da consistência. O usuário para de repetir o briefing inteiro a cada conversa. Ainda assim, um GPT configurado continua dentro do produto ChatGPT e, segundo a documentação atual, cada conversa começa sem memória salva, instruções pessoais ou conversas anteriores. Ele pode chamar uma API, mas isso não cria sozinho uma operação persistente, com estado, rotina e trilha de auditoria.
Nível 3: ambiente especializado com ferramentas
O modelo passa a ler e alterar um espaço de trabalho. Ferramentas de código são o exemplo mais claro: o agente examina o repositório, edita arquivos, executa testes e compara o resultado. Pesquisa, documentos e análise de dados também podem operar assim.
Aqui aparece o agent loop: o modelo observa o estado, escolhe uma ferramenta, recebe o resultado e decide o próximo passo. A tarefa pode durar dezenas de ações sem o usuário copiar e colar cada saída.
Pi, Codex e Claude Code pertencem a essa família, embora tenham filosofias diferentes. O ponto comum é que a IA ganhou ferramentas e um ambiente de execução delimitado.
Nível 4: APIs e automações
O agente cruza a fronteira do seu espaço de trabalho. Ele consulta sistemas, atualiza registros, dispara webhooks, abre tarefas, envia mensagens ou inicia um processo. n8n, conectores MCP e APIs próprias costumam aparecer nesse degrau.
Uma integração dessas precisa de identidade atribuível, credenciais com escopo limitado e regras claras. “Pode consultar o CRM” e “pode alterar qualquer negócio no CRM” são permissões muito diferentes.
Nível 5: agente persistente
O agente mantém estado entre sessões, executa rotinas agendadas e responde por diferentes canais. Memória deixa de ser apenas o histórico aberto na tela. Passa a incluir fatos duráveis, preferências, decisões anteriores, skills e artefatos de trabalho.
Hermes e OpenClaw entram com mais naturalidade aqui. Eles trazem boa parte da infraestrutura de continuidade, ferramentas, canais e execução que uma equipe teria de montar separadamente.
Nível 6: operação autônoma e adaptativa
Nesse nível, o sistema deixa de apenas executar fluxos e passa a melhorar o próprio modo de operar. Em um ciclo de autoaperfeiçoamento governado, faz pesquisa autônoma (autoresearch) sobre o processo, cria ou revisa evals, compara versões em benchmarks de capacidade e propõe mudanças em prompts, skills, memória ou ferramentas. Mudanças relevantes só entram com evidência, aprovação e rollback.
Isso exige engenharia de contexto. Índices vetoriais e lexicais, grafos, caches, esquemas tipados e hierarquias de memória recuperam o conhecimento certo com custo e latência controlados. Sem estruturas de dados e políticas de recuperação, mais memória produz mais ruído, não mais inteligência.
A operação pode assumir dois regimes: um agente residente, com agência delimitada e execução contínua, ou um swarm de agentes especializados que pesquisa, executa e revisa em paralelo. Nos dois casos, o sistema precisa definir como o estado circula, quem aprova mudanças e onde a decisão fica registrada.
Autoaperfeiçoamento não é autoalteração irrestrita. Mais agentes, mais contexto e mais loops só agregam valor quando evals, limites e rollback demonstram que cada mudança melhora o processo sem ampliar o risco.
A regra para subir
O degrau seguinte só faz sentido quando o anterior já tem um resultado útil e verificável. A cada aumento de autonomia, aumente também a qualidade das permissões, dos logs e das avaliações.
Um produto pode misturar níveis. Um GPT configurado pode chamar uma Action, enquanto um agente persistente pode trabalhar com uma única ferramenta. A escada mede a operação completa, não o nome do produto.
A anatomia de uma agent harness
O modelo fica no centro. Ao redor dele, nove componentes determinam se temos uma demonstração ou um sistema de trabalho.
1. Contexto e instruções
Inclui o objetivo, o papel do agente, regras do domínio, exemplos, documentos do projeto e a definição de “pronto”. Bom contexto reduz ambiguidade; contexto demais esconde o que importa e aumenta custo.
O desenho precisa responder: o que entra sempre, o que entra só quando relevante e quem mantém esse material atualizado?
2. Memória
Memória não é uma pasta onde todo histórico deve viver. Há pelo menos três tipos úteis:
- memória de sessão, para manter a linha de raciocínio atual;
- memória factual, para fatos e preferências que continuam válidos;
- memória procedural, para rotinas e skills que o agente deve repetir.
Sem critérios de gravação e expiração, a memória acumula erros antigos e contradições. Persistência exige curadoria.
3. Ferramentas e integrações
Ferramentas transformam intenção em ação: ler um arquivo, buscar na web, consultar uma API, editar um registro, operar o navegador ou executar um comando. Cada ferramenta precisa de uma descrição precisa, entradas tipadas e uma saída que o modelo consiga interpretar.
Uma skill ensina como trabalhar; uma ferramenta permite agir. Confundir as duas leva a sistemas cheios de instruções, mas sem capacidade, ou cheios de acesso, mas sem método.
4. Ambiente de execução
É onde as ações acontecem: máquina local, container, servidor remoto, navegador isolado ou função em nuvem. O ambiente define arquivos disponíveis, rede, dependências, segredos, duração e raio de dano.
Um diretório de trabalho não é automaticamente uma sandbox. Se o processo herda as permissões do usuário, caminhos absolutos e comandos podem alcançar muito mais do que a pasta exibida na interface.
5. Workflow e orquestração
O workflow organiza a sequência: pesquisar, planejar, executar, revisar, aprovar e publicar. A orquestração também define paralelismo, tentativas, timeouts, cancelamento e passagem de contexto entre agentes.
Separar pesquisa, execução e revisão costuma funcionar melhor do que entregar “faça tudo” a um único loop sem checkpoints.
6. Identidade e permissões
O agente precisa agir com uma identidade reconhecível, própria ou delegada, e credenciais de escopo mínimo. Isso permite atribuir ações, revogar acesso e impedir que uma automação herde todos os privilégios de uma pessoa.
O desenho de acesso precisa especificar qual agente, em qual canal, usando qual credencial, pode executar qual ação sobre qual conjunto de dados.
Essa delegação exige mais do que uma credencial. Aprofundo o recorte em identidade, permissões e autoridade dos agentes.
7. Isolamento e aprovações
Sandbox, allowlists e aprovação humana reduzem o dano de uma decisão ruim. A aprovação funciona melhor na fronteira de risco: antes de enviar uma mensagem externa, publicar, fazer deploy, mover dinheiro ou apagar dados.
Pedir confirmação para toda leitura trava a operação. Não pedir confirmação para uma transferência deixa o sistema irresponsável. O desenho precisa distinguir ações reversíveis, sensíveis e destrutivas.
- schema válido
- identidade autorizada
- allowlist de canal
- limite de orçamento
- idempotência
8. Observabilidade e logs
Um log útil registra o objetivo, o contexto relevante, as ferramentas chamadas, as mudanças produzidas, as aprovações e o resultado. Ele permite reconstruir o que aconteceu e localizar a falha: modelo, prompt, dado, integração ou permissão.
Logs também carregam risco. Segredos e dados pessoais precisam de filtragem, retenção definida e acesso restrito. “Logar tudo” não significa armazenar credenciais para sempre.
9. Evals e critérios de sucesso
Uma avaliação transforma “parece bom” em uma checagem. O mecanismo varia conforme o trabalho:
- código precisa de testes que executam;
- pesquisa precisa de fontes que sustentam cada afirmação;
- resumo precisa de comparação com o original;
- dado estruturado precisa de validação de esquema e regras;
- transação precisa de simulação, limites e registro de aprovação;
- conteúdo pode passar por revisão humana ou por uma rubrica explícita.
O critério deve existir antes de aumentar a autonomia. Trabalho de agente sem verificação vira vibes at scale.
O caso de Astra no RuneBench ajuda a delimitar o que um benchmark não demonstra sobre a operação, mesmo quando o desempenho chama atenção.
Do ChatGPT Desktop aos agentes customizados
Esses nomes aparecem na mesma conversa, mas representam categorias diferentes: interface de uso, assistente configurado, coding agent, harness extensível ou runtime persistente. “Mais avançado” não quer dizer “usa um modelo mais inteligente”. Quer dizer que o sistema assume mais responsabilidades ao redor do modelo.
ChatGPT Desktop
- Superfície de ação
- Chat conversa; Work cria entregáveis e pode usar apps, arquivos locais e tarefas; Codex opera repositórios e terminais
- Continuidade
- projetos e chats sincronizados; tarefas agendadas; sessões locais ou em nuvem conforme o modo
- Extensão e orquestração
- plugins, apps e skills; tarefas no Work; threads e worktrees no Codex
- Fronteira de controle
- permissões locais, aprovações, RBAC e políticas do workspace dentro do produto OpenAI
- Melhor encaixe
- trabalho geral e técnico numa interface pronta
GPT configurado
- Superfície de ação
- instruções, conhecimento, capacidades e apps ou Actions
- Continuidade
- cada conversa do GPT começa fresca
- Extensão e orquestração
- configuração no-code; uma API por Actions ou ferramentas do usuário por apps
- Fronteira de controle
- configuração do GPT, permissões do workspace e política do serviço conectado
- Melhor encaixe
- assistente reutilizável dentro do ChatGPT
Claude Code
- Superfície de ação
- arquivos, busca, shell, web, git, IDE e ferramentas MCP; execução local ou em ambientes remotos
- Continuidade
- sessões retomáveis,
CLAUDE.md, memória automática e contexto por projeto - Extensão e orquestração
- skills, MCP, hooks, plugins, subagentes, agent teams e Agent SDK
- Fronteira de controle
- regras allow/ask/deny combinadas com sandbox de filesystem e rede
- Melhor encaixe
- engenharia de software e automações baseadas em projeto
Pi base
- Superfície de ação
- leitura, escrita, edição, shell, sessões, contexto de projeto e compactação
- Continuidade
- sessões salvas e retomáveis
- Extensão e orquestração
- núcleo mínimo com skills, extensões, pacotes, SDK, RPC e múltiplos provedores
- Fronteira de controle
- roda com as permissões do usuário; isolamento precisa vir do sistema operacional
- Melhor encaixe
- equipes técnicas que querem uma harness pequena e inspecionável
Pi customizado
- Superfície de ação
- tudo que a equipe construir sobre extensões ou SDK
- Continuidade
- definida pela implementação
- Extensão e orquestração
- máxima liberdade para ferramentas, interface, políticas, memória e coordenação
- Fronteira de controle
- código, runtime, credenciais, dados, sandbox e evals ficam sob responsabilidade da equipe
- Melhor encaixe
- produto interno ou agente vertical com regras específicas
Hermes
- Superfície de ação
- terminal, arquivos, browser, MCP e mensageria em backends locais, containers, SSH ou nuvem
- Continuidade
- memória persistente, busca de sessões, skills que evoluem e cron
- Extensão e orquestração
- plugins, toolsets, perfis, bots e subagentes isolados
- Fronteira de controle
- toolsets, aprovações, allowlists, containers e configuração do gateway
- Melhor encaixe
- agente residente que aprende rotinas e trabalha em vários canais
OpenClaw
- Superfície de ação
- exec, browser, nodes, mídia, canais e ferramentas de plugins sob um gateway local-first
- Continuidade
- sessões por agente, workspaces, cron e heartbeat
- Extensão e orquestração
- skills, plugins, provedores e roteamento multiagente por bindings
- Fronteira de controle
- política de ferramentas, sandbox, bindings e allowlists de canal
- Melhor encaixe
- operação multicanal com agentes e identidades separados
- GPT configurado
- ChatGPT Desktop
- Claude Code
- Pi base
- Pi customizado
- Hermes
- OpenClaw
ChatGPT Desktop: três experiências na mesma aplicação
O ChatGPT Desktop atual reúne Chat, Work e Codex, mas eles não são o mesmo modo. Chat atende perguntas e tarefas conversacionais. Work conduz trabalhos longos, pesquisa em múltiplas fontes, cria documentos, planilhas, apresentações, relatórios ou Sites e pode executar tarefas agendadas ou disparadas por eventos. Codex permanece voltado a software, com acesso autorizado a pastas, repositórios, terminais e ferramentas de desenvolvimento.
Essa combinação dá ao usuário uma superfície pronta para alternar entre conversa, produção de entregáveis e execução técnica. No desktop, Work pode usar arquivos locais e aplicativos com permissão; chats locais permanecem no computador, enquanto tarefas em nuvem podem sincronizar entre dispositivos. Codex mantém histórico separado e pode coordenar múltiplas threads de trabalho.
O ganho é integração e experiência de uso. A contrapartida é que identidade, memória, políticas, catálogo de ferramentas e ciclo de atualização continuam majoritariamente definidos pelo produto e pelo workspace da OpenAI. É uma plataforma operacional pronta, não uma harness inteiramente controlada pela equipe.
O limite de um GPT configurado
Um GPT configurado é uma ótima embalagem para instruções, arquivos e uma pequena superfície de ferramentas. Ele reduz a barreira de entrada e evita construir interface, autenticação e experiência de conversa.
O limite aparece quando a operação exige estado durável, jobs agendados, execução em infraestrutura própria, observabilidade detalhada, identidades separadas, políticas de rede ou múltiplos agentes. A própria OpenAI diferencia GPTs, usados dentro do ChatGPT, de integrações feitas por API dentro de produtos e serviços.
Isso não torna o GPT configurado inferior. Para suporte interno, orientação, consulta de documentos ou pré-análise conduzida por uma pessoa, ele pode ser a escolha mais econômica e segura.
Onde Claude Code se diferencia
O Claude Code é uma harness de execução centrada no projeto. Seu loop nativo reúne operações de arquivo, busca, shell, web, git e inteligência de código. O mesmo mecanismo aparece no terminal, IDE, desktop, web e pipelines de CI; o que muda é onde o código executa e como a pessoa supervisiona o trabalho.
A camada de extensão é ampla: CLAUDE.md mantém convenções do projeto; skills empacotam procedimentos; MCP conecta serviços; hooks executam validações ou efeitos em eventos do ciclo; subagentes isolam contexto; agent teams e background agents permitem paralelismo; o Agent SDK embute essas capacidades em fluxos próprios. Isso o coloca acima de um simples copiloto de edição.
O diferencial de controle está na combinação de regras allow, ask e deny com uma sandbox opcional que restringe filesystem e rede no nível do sistema operacional. A configuração padrão ainda exige decisões do operador, e modos permissivos podem ampliar o risco. É uma harness pronta e extensível, mas continua sendo uma ferramenta com acesso real ao ambiente de desenvolvimento.
Por que Pi é uma base interessante para versões customizadas
O Pi assume uma posição deliberadamente mínima. Por padrão, oferece ao modelo ferramentas de leitura, escrita, edição e terminal. Recursos como MCP, subagentes, modo de planejamento e pop-ups de permissão não fazem parte do núcleo. A equipe acrescenta o que precisa por skills, extensões, pacotes ou código próprio.
Essa ausência é uma decisão de arquitetura. As extensões do Pi podem registrar ferramentas, interceptar chamadas, adicionar aprovações, personalizar compactação, criar interfaces, executar em sandbox e coordenar subagentes. O SDK permite embutir sessões do agente em outra aplicação e testar seu comportamento por código.
Uma versão customizada do Pi pode, portanto, deixar de parecer uma ferramenta de código. Ela pode virar um agente de pesquisa, um operador de conteúdo ou um assistente para um processo vertical. A equipe passa a ser responsável por tudo que adiciona: autenticação, memória, logs, atualizações, segurança e evals.
Há um alerta importante. Extensões e pacotes rodam com acesso ao sistema. Instalar código de terceiros sem revisão troca simplicidade por risco de cadeia de suprimentos.
Onde Hermes se diferencia
O Hermes Agent vem mais opinionado. Sua documentação dá destaque a um ciclo de aprendizado com memória persistente, criação e melhoria de skills, recuperação de conversas, rotinas agendadas e operação por vários canais. Ele pode executar localmente, em container, por SSH ou em ambientes remotos.
Hermes também delega tarefas a subagentes com conversas e terminais isolados. Hoje, inclui bots nomeados que podem ter modelo, memória, skills e rotinas próprias. Por isso, a comparação “Hermes é um agente único; OpenClaw é multiagente” ficou curta. A diferença está na ênfase: Hermes organiza o produto ao redor de um agente que aprende e acumula procedimentos, embora também coordene especialistas.
A infraestrutura pronta economiza desenvolvimento, mas não elimina decisões de segurança. A documentação de segurança do Hermes descreve autorização por usuário, aprovação de comandos perigosos, proteção de escrita, containers, filtragem de credenciais e isolamento entre sessões. O backend local continua compartilhando as permissões do usuário; isolamento real exige uma fronteira real.
Onde OpenClaw se diferencia
O OpenClaw integra descoberta de modelos, montagem de prompt, ferramentas, sessões e entrega por canais no mesmo runtime. Sua arquitetura distingue ferramentas, que executam ações; skills, que ensinam procedimentos; e plugins, que adicionam código, credenciais, hooks, provedores ou novos canais.
Ele suporta vários agentes com workspaces, identidades, modelos e roteamento próprios. O modo padrão, porém, continua sendo um agente. A comunicação agente a agente precisa ser habilitada e restringida. O workspace é o diretório inicial, não uma barreira de segurança; a sandbox e a política de ferramentas precisam ser configuradas.
A metáfora “uma empresa de agentes” é útil para imaginar uma implantação com papéis e rotas. Ela descreve uma possibilidade de configuração, não uma propriedade automática do produto.
O mesmo modelo pode produzir quatro sistemas
Imagine que todos usem o mesmo modelo para analisar contratos.
No chat geral, uma pessoa envia um PDF e pergunta quais cláusulas merecem atenção. No GPT configurado, a rubrica jurídica, os modelos de contrato e o formato de resposta já estão carregados. Numa versão customizada do Pi, o agente lê uma pasta, extrai texto, cruza cláusulas com uma base interna, produz um diff e exige aprovação antes de salvar. Em Hermes ou OpenClaw, a rotina pode rodar quando um arquivo chega, manter histórico do fornecedor, abrir uma tarefa e notificar o responsável.
O modelo permaneceu igual. Mudaram o contexto, as ferramentas, o gatilho, a memória, as permissões e a verificação.
Essa é a comparação que interessa na prática. Benchmark de modelo ajuda a escolher capacidade e custo. Arquitetura do ambiente define confiabilidade operacional.
Cloud, local ou híbrido
Modelos em nuvem costumam oferecer melhor raciocínio, contexto longo e manutenção mais simples. Também colocam dados, custo variável e disponibilidade sob regras do provedor.
Modelos locais oferecem mais controle sobre dados, custo previsível em carga constante, operação offline e liberdade de experimentação. Exigem infraestrutura, atualizações, monitoramento e uma avaliação honesta da qualidade necessária.
O desenho híbrido costuma separar tarefas:
- modelos locais cuidam de triagem, classificação, extração e rotinas sensíveis ou repetitivas;
- modelos de nuvem entram em planejamento, código complexo, revisão difícil e exceções;
- dados e ferramentas continuam sob uma camada de política que independe do modelo escolhido.
Soberania não vem apenas de rodar pesos localmente. Também depende de quem controla memória, credenciais, logs, ferramentas e decisões de atualização.
Um exemplo completo: produzir campanhas publicitárias em escala
Considere uma operação que recebe dezenas de briefings por semana e precisa transformar cada um em textos, peças, variações de formato, aprovações e entregas para diferentes canais.
-
01 Briefing
- Agentes
- interpreta
- Harness
- ChatGPT / GPT
- Sistemas
- formulário
- Equipe
- define conceito
-
02 Preparação
- Agentes
- pesquisa + planeja
- Harness
- Claude Code / Pi
- Sistemas
- biblioteca de marca
-
03 Produção
- Agentes
- gera variações
- Harness
- Pi custom / Hermes
- Sistemas
- arquivos criativos
-
04 Controle
- Agentes
- verifica marca e formato
- Harness
- políticas + logs
- Sistemas
- gestor de projetos
- Equipe
- resolve exceções
-
05 Entrega
- Agentes
- empacota
- Harness
- Hermes / OpenClaw
- Sistemas
- canais e mídia
- Equipe
- aprova publicação
-
06 Melhoria
- Agentes
- compara evals
- Harness
- benchmark + rollback
- Sistemas
- métricas
No nível 1, uma pessoa cola o briefing no chat e pede opções de texto. No nível 2, o assistente também recebe o guia da marca, campanhas aprovadas, restrições legais e uma rubrica de qualidade. No nível 3, ele lê os arquivos da campanha, cria variações, redimensiona e nomeia peças e verifica especificações técnicas. No nível 4, conecta-se ao gestor de projetos e à biblioteca de ativos, abre tarefas, anexa rascunhos e encaminha cada peça para aprovação. No nível 5, acompanha continuamente a fila, os prazos, as versões e o feedback, retomando o trabalho quando chega uma revisão. No nível 6, uma operação orquestrada distribui briefing, pesquisa, produção e controle de qualidade entre agentes especializados; um ciclo separado mede retrabalho, tempo de entrega e aderência à marca, testa mudanças contra casos de referência e só promove melhorias com aprovação e rollback.
O valor não está em remover a equipe criativa. Ela deixa de transportar arquivos, repetir adaptações e conferir detalhes mecânicos para decidir sobre conceito, exceções e qualidade. O sistema precisa de limites explícitos: marcas e canais permitidos, fontes de ativos, alegações proibidas, orçamento, política de aprovação e ações que nunca podem publicar sem uma pessoa.
Em publicidade, um erro pode desperdiçar verba, violar direitos ou expor uma marca. Escala operacional exige controle proporcional ao alcance.
Três gates antes de aumentar a autonomia
1. O processo tem dono e linha de base?
Alguém precisa responder pelo resultado. Também precisamos saber como o trabalho acontece hoje: tempo, custo, volume, erro e pontos de espera. Sem linha de base, “ficou mais eficiente” é apenas impressão.
2. O agente tem fronteiras operacionais?
Liste sistemas, dados, ferramentas, credenciais e ações. Defina o que é somente leitura, o que é reversível, o que exige aprovação e o que permanece proibido.
3. Existe uma checagem proporcional ao risco?
Defina um teste observável para cada entrega e guarde evidência suficiente para reconstruir a execução. Quanto maior o impacto de uma ação, mais forte deve ser a verificação anterior e posterior.
Antes de escolher entre ChatGPT Desktop, um GPT configurado, Claude Code, Hermes, OpenClaw ou uma versão própria do Pi, responda sete perguntas:
- Qual trabalho específico precisa mudar?
- Qual evento inicia a tarefa?
- Que dados o agente precisa conhecer?
- Que ferramentas e credenciais ele pode usar?
- Quais ações exigem aprovação?
- Como sabemos que a entrega está correta?
- Quem sustenta o processo quando regras, modelos ou integrações mudarem?
Se essas respostas ainda não existem, escolha o degrau mais baixo que gere valor e use o piloto para produzi-las. Não dê acesso root ao estagiário digital no primeiro dia.
Sobre o autor
Ion “Zeugh” Neto trabalha na interseção entre inteligência artificial, design de serviço, governança e segurança em cripto. Desde 2024 constrói agentes aplicados a tesourarias, votos e operações de DAOs. É cofundador da fator.ai, que desenha e integra trabalhadores digitais com processos, permissões, avaliação e auditoria, e da Blockful, onde atua com ecossistemas como ENS e Uniswap.
Fontes primárias e leituras
- OpenAI: GPTs in ChatGPT
- OpenAI: Configuring actions in GPTs
- OpenAI: ChatGPT Work and Codex
- OpenAI: Work with Apps on macOS
- Claude Code: overview
- Claude Code: funcionamento e agent loop
- Claude Code: extensões
- Claude Code: permissões e sandbox
- Pi: documentação do coding agent
- Pi: extensões
- Pi: SDK
- Pi: fronteira de segurança
- Hermes Agent: documentação
- Hermes Agent: delegação e subagentes
- Hermes Agent: segurança
- OpenClaw: runtime do agente
- OpenClaw: configuração multiagente
- OpenClaw: ferramentas, skills e plugins
Capacidades de produtos mudam rápido. Comparação revisada nas fontes oficiais em 27 de agosto de 2026.
