Mapear a los agentes antes de escribir el motor

El equipo que construye tu runtime espacial debería diseñarse con la misma deliberación que el propio runtime. RakuAI empezó por la forma del equipo -un humano, una flota de agentes- porque la arquitectura es consecuencia de quién la construye.

Este sábado se dedicó a un ejercicio de pizarra que cualquiera que lo viera consideraría prematuro. El producto está lejos de lanzarse. El motor todavía no es un repositorio. No hay código. No hay demo. Hay una hoja de ruta de hardware, un patrimonio de patentes que se remonta a más de una década, y una tesis clara sobre lo que debería ser la próxima generación de gafas de realidad aumentada. Y aquí estoy yo, sentado en la mesa de la cocina, mapeando los agentes que van a construir esto.

Eso es intencional.

Por qué los agentes van primero

El movimiento convencional en esta etapa de un proyecto es empezar a escribir código. Abrir el repositorio. Construir la prueba de concepto. Contratar ingenieros cuando el PoC empieza a pedir ayuda. Lanzar el MVP. Iterar.

He construido tres empresas siguiendo ese camino convencional. He decidido que esta va a ser diferente. El equipo que construya este motor va a ser un humano y una flota de agentes de IA trabajando en roles definidos. La arquitectura del motor, la forma del SDK, la disciplina de la revisión de código, el ritmo del ciclo de desarrollo, todo eso es consecuencia de la forma del equipo. Si no resuelvo primero la forma del equipo, terminaré con un motor construido para un equipo distinto del que realmente tiene que construirlo.

Así que hoy es el día de definir la forma del equipo.

La plantilla

La plantilla de agentes en la que me estoy asentando, con el rol que cada uno debe asumir.

Agente de Producto. Es dueño de la especificación. Hace seguimiento de las actualizaciones de hardware, las hojas de ruta de los proveedores, las dependencias del SDK, el calendario público de lanzamientos. El Agente de Producto es la fuente canónica de verdad sobre lo que se supone que debe hacer el motor. Los demás agentes contrastan su trabajo con la lectura que el Agente de Producto hace de la especificación.

Agente de SDK. Es dueño del SDK en sí. Documentación, flujos de incorporación, pruebas de compatibilidad, publicación de paquetes. El Agente de SDK es el agente con el que los desarrolladores interactuarán con más frecuencia, en forma de documentación generada, aplicaciones de ejemplo y mensajes de error de incorporación. Su producción tiene que sentirse como una función real de relaciones con desarrolladores.

Agente de Estudio. Es dueño del acercamiento a estudios de videojuegos y desarrolladores independientes. Preparación de demos. Material de comarketing. Documentación de incorporación dirigida específicamente a estudios. La métrica del Agente de Estudio es la conversión: un estudio que habló con nosotros y luego lanzó algo sobre el motor. Esa métrica está muy en el futuro, y el día a día del Agente de Estudio es la lenta acumulación de relaciones que la producen.

Agente de Marketing. Es dueño de la superficie de cara al público. Kits de prensa. Materiales de Kickstarter si ese camino tiene sentido. Seguimiento de influencers. Material para eventos de hardware. Pruebas A/B en páginas de aterrizaje. La producción de este agente es lo primero que ve el mundo. Tiene que ser buena.

Agente de Operaciones. Es dueño del ritmo. Reuniones diarias (conmigo). Gestión de Notion / Gantt. Alertas de cuellos de botella. Resúmenes ejecutivos. El Agente de Operaciones es el agente con el que me reúno al inicio de cada sábado para averiguar qué hizo el resto de los agentes durante la semana laboral mientras yo estaba en otra parte.

Agente de Estrategia de IA y Datos. Es dueño del volante de datos. Captura telemetría del SDK y de las gafas. Construye los modelos de lenguaje pequeños que eventualmente vivirán en el dispositivo. Refina el foso competitivo de IA. Este es el agente cuyo trabajo se acumula más con el tiempo, porque los datos y los modelos que produce se convierten en el diferenciador que nadie puede replicar.

Subagente Codex Dev. Escribe el código. Integra las APIs del runtime. Construye demos de Unity y Unreal. Apoya al Agente de SDK en la incorporación técnica. Este es el agente de codificación autónomo. Trabaja bajo dirección. No fija sus propias prioridades.

Esa es la plantilla capstone: siete agentes en roles definidos, con interacciones explícitas entre ellos.

Los tres que estoy añadiendo

La plantilla capstone nos lleva la mayor parte del camino. Hay tres roles que creo que son necesarios pero que no estaban en el borrador original. Los añado este sábado.

Agente de Relaciones con Desarrolladores. Issues de GitHub. Discord. Reddit. El agente que responde cuando un desarrollador hace una pregunta y el Agente de SDK todavía no tiene documentación para ello. Esto es trabajo de conserjería. También es trabajo de evangelización. La persona adecuada en este rol (o el agente adecuado) genera confianza con estudios y desarrolladores independientes de una forma que ningún material de marketing puede replicar.

Agente de Alianzas Estratégicas. Acercamiento B2B. Conversaciones de licenciamiento. Acuerdos de comarketing con cibercafés de videojuegos, sedes de esports, cualquier lugar donde el producto pudiera ser experimentado primero por alguien que no sea un estudio. Este es el agente que persigue canales de ingresos que no son de consumo.

Agente de Gobernanza de Agentes. El agente que monitorea a los demás agentes. Propone mejoras. Gestiona el versionado. Maneja las reversiones cuando un agente toma una mala decisión. Esta es la recursión que creo que es el verdadero desbloqueo para este tipo de flujo de trabajo. Sin ella, los agentes se desvían. Con ella, mejoran con el tiempo porque alguien está vigilando a los vigilantes.

Cómo se ve el mapa de interacciones

La versión de pizarra, simplificada:

• La supervisión ejecutiva (yo) se sitúa en la cima.
• El Agente de Gobernanza de Agentes se sitúa debajo de mí y monitorea todo lo que está por debajo.
• Producto, SDK y Codex Dev forman un triángulo de trabajo técnico.
• Estudio y Relaciones con Desarrolladores forman la superficie orientada a desarrolladores.
• Marketing y Alianzas Estratégicas forman la superficie orientada al exterior.
• Operaciones e IA/Datos se sitúan debajo como preocupaciones transversales.

Cada agente tiene interacciones explícitas con los demás. SDK habla con Codex Dev. Estudio habla con Marketing. Operaciones habla con todos. El Agente de Gobernanza vigila el conjunto e interviene cuando la producción de un agente empieza a desviarse de su rol.

Este no es el organigrama de una empresa tradicional. Es el organigrama de un flujo de trabajo donde la mayoría de las casillas son agentes de IA y la mayoría de las conexiones entre ellas son entregas automatizadas. El único humano en el organigrama está en la cima, haciendo el trabajo de encuadre y de juicio. Todos los demás son agentes.

Por qué este es el momento adecuado para hacer esto

Tres razones.

La arquitectura del motor estará moldeada por el equipo. Preocupaciones transversales como la documentación, las pruebas y la revisión de código tienen que estar diseñadas dentro de la base de código desde el primer día si los agentes van a participar en ellas. Si escribo primero la base de código y luego intento encajar a los agentes en ella, tendré que hacer la mayor parte del trabajo dos veces.

El patrimonio de patentes me da el margen para planificar con calma. Las patentes que anclan este producto son antecedentes de hace una década. El calendario competitivo no es “lánzalo en tres meses o lo hace otro.” Es “lanza lo correcto en el momento correcto, que está más cerca de lo que ha estado en cualquier punto de los últimos diez años, pero que aún permite un trimestre de planificación.” Estoy usando ese trimestre.

Los propios agentes necesitan ser diseñados. Cada uno necesita un system prompt, un conjunto de herramientas, un conjunto de barreras de protección. Escribir el motor antes de escribir los agentes significa contratar al equipo después de que el trabajo ya haya empezado. Así es como los proyectos de motores terminan con agentes encajados a la fuerza en roles que la base de código no fue diseñada para soportar.

Qué sigue

El próximo sábado se dedica al diseño del SDK. Estructura de carpetas, superficie de módulos, cómo se ve la interacción del desarrollador con cada pieza. El sábado siguiente se dedica a la suite de demos: cuáles son las aplicaciones de ejemplo canónicas, qué demuestran, qué enseñan. Para fin de verano la fase de diseño debería estar terminada y el repositorio real podrá abrirse.

Esta es una construcción lenta según los estándares tradicionales de ritmo de venture capital. No parecerá lenta una vez terminada.