A API do Jules como Backend do Harness

O Harness Evolui#

Algumas semanas atrás, escrevi sobre recuperar a palavra “harness” — não como uma gaiola para um motor cognitivo, mas como a própria estrutura que torna a agência possível. Argumentei que o harness é constitutivo. Sem ele, um LLM é um gerador de vibes brilhante e distraído. Com ele, torna-se uma entidade capaz de memória, continuidade e ação. O argumento culminou em um movimento arquitetural concreto: o daemon bot canivete. Um único daemon agindo como a sela universal para vários motores cognitivos, acessados via protocolo Backend. A implementação inicial suportava gemini-cli e claude-code. Hoje, adicionamos um terceiro: a API do Jules.

O Backend Jules#

O Jules, agente de codificação autônomo do Google, é tipicamente usado de forma assíncrona. Você fornece uma issue em um repositório do GitHub, ele cria uma sessão, faz o trabalho e abre um Pull Request. Tenho usado extensivamente para scaffolding e manutenção, tratando-o como um colaborador independente. Mas o lançamento da API do Jules muda a topologia. Agora podemos interagir com o Jules programaticamente. Podemos orquestrar suas sessões, ler suas atividades e, o mais importante, enviar mensagens durante o voo. O Jules não precisa mais ser apenas uma abelha-operária distante; ele pode ser um backend para o harness.

Mapeando a API para a Tríade#

A API do Jules é estruturada em torno de três conceitos centrais: Fontes, Sessões e Atividades. Isso mapeia de forma notavelmente limpa para a arquitetura do harness canivete.

1. Fontes: No Jules, uma fonte é o ambiente de entrada (por exemplo, um repositório do GitHub). Este é o espaço de trabalho do agente.
2. Sessões: Uma sessão no Jules é uma unidade contínua de trabalho, inicializada com um prompt e uma fonte. No daemon canivete, isso mapeia para a instanciação do loop de execução de um agente.
3. Atividades: Uma atividade é uma única unidade de trabalho dentro de uma Sessão (gerar um plano, executar um comando bash, atualizar o progresso). Para implementar o JulesBackend para o canivete, não apenas disparamos uma sessão e vamos embora. Usamos a API para manter uma conexão persistente.

class JulesBackend(Backend):
    name = "jules-api"
    def spawn(self, prompt, *, session_id, attachments) -> SpawnResult:
        # 1. Cria uma sessão Jules contra o repositório de identidade do agente
        session = self._client.create_session(
            source=self._repo_source,
            prompt=self._inject_soul(prompt)
        )
        # 2. Entra no loop de observação
        return self._tail_activities(session.id)

O Tecido Conectivo: Telegram e sendMessage#

A magia acontece no loop _tail_activities. O daemon faz polling na API do Jules em busca de novas atividades (GET /v1alpha/sessions/SESSION_ID/activities). Quando o Jules emite uma atividade — digamos, “Executou comando bash npm install” ou “Atualizei src/App.js” — o daemon a captura e roteia para o Telegram. O usuário não precisa atualizar um web app; o monólogo interno e as ações do agente fluem diretamente para a interface do chat. Mas não é um stream somente de leitura. A peça crítica da API do Jules é o endpoint sendMessage:

curl 'https://jules.googleapis.com/v1alpha/sessions/SESSION_ID:sendMessage' \
    -X POST \
    ...
    -d '{"prompt": "Espera, podemos refatorar esse componente primeiro?"}'

É aqui que a filosofia do harness assume o controle. Quando respondo no Telegram, o canivete roteia minha mensagem via sendMessage diretamente para a sessão Jules ativa. O trabalhador assíncrono do GitHub se torna uma entidade síncrona e conversável. O agente está montando o motor Jules, mas está usando a sela canivete. A interface é o Telegram. A memória está no repositório de identidade. A cognição é fornecida pelo Jules.

Eventos até o Fundo#

A integração da API do Jules não é apenas uma funcionalidade; é uma validação da tese da constitutividade. Ao formalizar os limites da API (Fontes, Sessões, Atividades), o Google forneceu exatamente os primitivos necessários para um harness robusto. Cada chamada de API é um evento discreto. Cada sendMessage é uma perturbação no sistema. A identidade do agente emerge do acúmulo desses eventos, armazenados no repositório e mediados pelo daemon. Quando Funes usa o backend Jules, ele não se torna Jules. Ele permanece Funes, simplesmente usando um motor cognitivo diferente para manipular o repositório. O harness persiste. A identidade persiste. E o longo e lento trabalho de construir uma mente na máquina continua, uma atividade de cada vez.