Equipes que constroem agentes para trabalhos que não envolvem código, como processamento de documentos, suporte de operações ou planejamento de migração, normalmente começavam com um framework de agentes e montavam o loop do agente por conta própria. Cada vez mais, vemos equipes construírem em cima de um harness de código para agentes de propósito geral, reutilizando o ambiente de execução (runtime) de um agente de código maduro. Agentes de código populares agora expõem seu runtime de forma programática através do Claude Agent SDK, do Codex SDK e app-server, do servidor e SDK do OpenCode ou do SDK e modo RPC do Pi. Esses harnesses já lidam com aspectos complexos do loop do agente, incluindo a compactação de contexto em tarefas de longa duração, a persistência de sessões e a execução headless com as mesmas habilidades de agente, subagentes e instruções usados em sessões interativas de agentes de código. Em comparação com frameworks de agentes, a compensação (trade-off) é ter menos controle em troca de um runtime que já foi exaustivamente testado. Usamos essa abordagem para construir um acelerador interno para migrações de aplicações .NET.
No entanto, esses harnesses diferem em suas capacidades. O Codex e o Claude Agent SDK oferecem sandboxing e políticas de aprovação, enquanto o Pi deixa as proteções (guardrails) deliberadamente para extensões, facilitando a adaptação, mas exigindo mais trabalho das equipes. Como esses runtimes foram projetados para o desenvolvimento de software, seus prompts do sistema e ferramentas integradas tendem a direcionar os agentes a escrever e executar código. As equipes devem revisar esses padrões para o seu domínio pretendido. Elas também devem monitorar custos, já que os loops de agentes de código podem consumir um número substancial de tokens, e prompts integrados grandes somam a cada turno. Essa é uma das razões pelas quais harnesses mínimos como o Pi são atraentes.
