Mapeando os Agentes Antes de Escrever o Motor

O time que constrói o seu runtime espacial deveria ser projetado com a mesma deliberação que o próprio runtime. A RakuAI começou pelo formato do time - um humano, uma frota de agentes - porque a arquitetura é consequência de quem a constrói.

Este sábado virou um exercício de quadro branco que qualquer observador acharia prematuro. O produto está longe de ser lançado. O motor ainda nem é um repositório. Não há código. Não há demo. Há um roadmap de hardware, um portfólio de patentes que remonta a mais de uma década, e uma tese clara sobre o que a próxima geração de óculos de RA deveria ser. E aqui estou eu, sentado à mesa da cozinha, mapeando os agentes que vão construir essa coisa.

Isso é de propósito.

Por que os agentes vêm primeiro

O movimento convencional nesta fase de um projeto é começar a escrever código. Abrir o repositório. Construir a prova de conceito. Contratar engenheiros quando a PoC começar a pedir ajuda. Lançar o MVP. Iterar.

Já construí três empresas seguindo o caminho convencional. Decidi que esta vai ser diferente. O time que constrói este motor vai ser um humano e uma frota de agentes de IA trabalhando em papéis definidos. A arquitetura do motor, o formato do SDK, a disciplina da revisão de código, o ritmo do ciclo de desenvolvimento - tudo isso é consequência do formato do time. Se eu não definir o formato do time primeiro, vou acabar com um motor construído para um time diferente daquele que de fato precisa construí-lo.

Então hoje é o dia de definir o formato do time.

A escalação

A escalação de agentes que estou definindo, com o papel que cada um deve assumir.

Agente de Produto. Dono da especificação. Acompanha atualizações de hardware, roadmaps de fornecedores, dependências de SDK, o calendário público de lançamentos. O Agente de Produto é a fonte canônica de verdade sobre o que o motor deve fazer. Os outros agentes conferem seu trabalho contra a leitura da especificação feita pelo Agente de Produto.

Agente de SDK. Dono do SDK em si. Documentação, fluxos de onboarding, testes de compatibilidade, publicação de pacotes. O Agente de SDK é o agente com quem os desenvolvedores vão interagir com mais frequência, na forma de documentação gerada, apps de exemplo e mensagens de erro de onboarding. A saída dele precisa parecer uma função real de relações com desenvolvedores.

Agente de Studio. Dono da prospecção junto a estúdios de jogos e desenvolvedores independentes. Preparação de demos. Material de co-marketing. Documentação de onboarding voltada especificamente a estúdios. A métrica do Agente de Studio é conversão: um estúdio que conversou conosco e depois lançou algo no motor. Essa métrica está bem no futuro, e o dia a dia do Agente de Studio é o acúmulo lento de relacionamentos que a produzem.

Agente de Marketing. Dono da superfície voltada ao público. Kits de imprensa. Materiais de Kickstarter, se esse caminho fizer sentido. Acompanhamento de influenciadores. Material para eventos de hardware. Testes A/B em landing pages. A saída deste agente é a primeira coisa que o mundo vê. Precisa ser boa.

Agente de Operações. Dono do ritmo. Stand-ups (comigo). Gestão de Notion/Gantt. Alertas de gargalo. Resumos executivos. O Agente de Operações é o agente com quem faço check-in no início de cada sábado para saber o que o resto dos agentes fez durante a semana de trabalho enquanto eu estava em outro lugar.

Agente de Estratégia de IA e Dados. Dono do flywheel de dados. Captura telemetria do SDK e dos óculos. Constrói os pequenos modelos de linguagem que eventualmente vão rodar no dispositivo. Refina o fosso competitivo de IA. Este é o agente cujo trabalho mais se acumula ao longo do tempo, porque os dados e os modelos que ele produz se tornam o diferencial que ninguém consegue replicar.

Sub-Agente de Codex Dev. Escreve o código. Integra as APIs do runtime. Constrói demos em Unity e Unreal. Dá suporte ao Agente de SDK no onboarding técnico. Este é o agente de codificação autônomo. Trabalha sob direção. Não define suas próprias prioridades.

Essa é a escalação-base: sete agentes em papéis definidos, com interações explícitas entre eles.

Os três que estou adicionando

A escalação-base nos leva a maior parte do caminho. Há três papéis que acredito serem necessários, mas que não estavam no rascunho original. Adicionando-os neste sábado.

Agente de Relações com Desenvolvedores. Issues no GitHub. Discord. Reddit. O agente que responde quando um desenvolvedor faz uma pergunta e o Agente de SDK ainda não tem documentação para ela. É trabalho de concierge. É também trabalho de evangelismo. A pessoa certa nesse papel (ou o agente certo) constrói confiança com estúdios e devs independentes de um jeito que nenhuma quantidade de material de marketing consegue replicar.

Agente de Parcerias Estratégicas. Prospecção B2B. Conversas de licenciamento. Acordos de co-marketing com lan houses gamer, arenas de e-sports, qualquer lugar onde o produto possa ser experimentado primeiro por alguém que não seja um estúdio. Este é o agente que vai atrás de canais de receita que não são de consumidor final.

Agente de Governança de Agentes. O agente que monitora os outros agentes. Propõe atualizações. Gerencia versionamento. Cuida do rollback quando um agente toma uma decisão ruim. Esta é a recursão que considero o verdadeiro desbloqueio para este tipo de fluxo de trabalho. Sem ela, os agentes desviam do rumo. Com ela, melhoram ao longo do tempo porque alguém está vigiando os vigilantes.

Como fica o mapa de interações

A versão do quadro branco, simplificada:

• A supervisão executiva (eu) fica no topo.
• O Agente de Governança de Agentes fica abaixo de mim e monitora tudo abaixo dele.
• Produto, SDK e Codex Dev formam um triângulo de trabalho técnico.
• Studio e Relações com Desenvolvedores formam a superfície voltada ao desenvolvedor.
• Marketing e Parcerias Estratégicas formam a superfície voltada para fora.
• Operações e IA/Dados ficam por baixo como preocupações transversais.

Cada agente tem interações explícitas com os outros. SDK conversa com Codex Dev. Studio conversa com Marketing. Operações conversa com todo mundo. O Agente de Governança observa tudo e intervém quando as saídas de um agente começam a desviar do seu papel.

Este não é o organograma de uma empresa tradicional. É o organograma de um fluxo de trabalho onde a maioria das caixas são agentes de IA e a maioria das conexões entre elas são handoffs automatizados. O único humano no organograma está no topo, fazendo o enquadramento e o trabalho de julgamento. Todo o resto é agente.

Por que este é o momento certo para fazer isso

Três razões.

A arquitetura do motor vai ser moldada pelo time. Preocupações transversais como documentação, testes e revisão de código precisam ser projetadas dentro da base de código desde o dia um, se os agentes vão participar delas. Se eu escrever a base de código primeiro e depois tentar encaixar agentes nela, vou ter que fazer a maior parte do trabalho duas vezes.

O portfólio de patentes me dá fôlego para planejar com cuidado. As patentes que sustentam este produto são de mais de uma década. O timing competitivo não é “lance em três meses ou outra pessoa lança”. É “lance a coisa certa no momento certo”, que está mais próximo do que em qualquer outro ponto dos últimos dez anos, mas ainda permite um trimestre de planejamento. Estou usando o trimestre.

Os próprios agentes precisam ser projetados. Cada um precisa de um system prompt, um conjunto de ferramentas, um conjunto de salvaguardas. Escrever o motor antes de escrever os agentes significa contratar o time depois que o trabalho já começou. É assim que projetos de motor acabam com agentes encaixados à força em papéis para os quais a base de código não foi projetada.

O que vem a seguir

O próximo sábado vai para o design do SDK. Estrutura de pastas, superfície de módulos, como fica a interação do desenvolvedor com cada peça. O sábado depois desse vai para o conjunto de demos: quais são os apps de exemplo canônicos, o que eles provam, o que eles ensinam. Até o fim do verão a fase de design deve estar concluída e o repositório de verdade pode ser aberto.

Esta é uma construção lenta para os padrões tradicionais de ritmo de venture capital. Não vai parecer lenta quando estiver pronta.