experimento de IA

Invité a mi agente de IA a Romergo y no sé qué es esto ni cómo llamarlo.

La mayoría de las integraciones de IA en aplicaciones están diseñadas de forma predecible. El producto agrega un botón de chispa, envía una solicitud a su propio modelo y muestra la respuesta en la barra lateral.

Hay otra opción común. La aplicación proporciona un servidor MCP y el usuario abre ChatGPT, Claude u otro agente y le pide que trabaje con los datos de la aplicación. Esto le da al agente buenas herramientas, pero la conversación ocurre en otra parte. Debe salir del editor, explicar qué está abierto actualmente, volver atrás y verificar el resultado.

Me cansé de alternar entre el chat y el editor y se me ocurrió una idea: ¿y si pudiera evitarlo por completo?

Agregué un panel de IA directamente al editor, pero no lo conecté a un modelo alojado en Romergo. En cambio, el usuario invita a su agente personal de IA a la sesión abierta.

El agente permanece donde ya vive: en ChatGPT, Claude, Codex u otro cliente compatible con MCP. Mantiene su modelo, suscripción, memoria, configuraciones y herramientas disponibles. Romergo proporciona sólo un espacio de trabajo, contexto actual y herramientas especializadas para editar un proyecto.

Después de conectarse, el usuario puede escribirle al agente directamente desde Builder:

• describir la escena abierta;
• cambiar la música en este capítulo;
• reescribe el diálogo resaltado;
• poner un fondo diferente;
• comprobar la lógica de transición;
• Explique por qué la escena no funciona como esperaba.

Las respuestas, preguntas y estados intermedios se devuelven al mismo panel. El panel muestra no solo el texto, sino también todo el ciclo de la tarea: se recibió un comando, se asignó a un agente, se están ejecutando herramientas, se requiere confirmación, se completó el trabajo o se produjo un error. Ya no necesitas salir del editor.

Comenzó como un experimento.

No tenía intención de inventar un nuevo protocolo ni de crear una nueva categoría de producto. Quería probar una idea simple: ¿podría un agente de usuario personal no solo controlar Romergo externamente a través de MCP, sino también unirse temporalmente a una sesión en vivo dentro del editor?

La primera versión fue un experimento. Para mi sorpresa, funcionó lo suficientemente bien como para empezar a usarlo yo mismo.

El diagrama más corto se puede dibujar así:

Personal AI agent  <->  MCP  <->  Romergo Builder

Pero la señal en ambas direcciones es importante.

Una llamada MCP típica comienza en el agente: el agente decide ponerse en contacto con la aplicación y llama a su herramienta. En mi experimento, Romergo también puede iniciar el trabajo. El usuario escribe un comando en Builder, Romergo lo coloca en un canal seguro y el agente ya conectado recibe el comando a través de MCP.

Luego, el agente utiliza las herramientas habituales de Romergo para leer o modificar el proyecto y devuelve el resultado a Builder a través del mismo canal.

Esto crea un circuito cerrado:

1. User -> Builder panel: "Replace the music in this chapter"
2. Builder -> authenticated channel: command + current page + selection
3. Personal agent -> MCP: wait for the next Builder command
4. Agent -> Romergo MCP tools: inspect and edit the project
5. Agent -> MCP channel: status, question, result, or error
6. Builder panel -> User: live response from the personal agent

Romergo no ejecuta el modelo en ninguno de estos pasos.

Al mismo tiempo, no cambié el MCP en sí y no le agregué un servidor real. Desde una perspectiva de protocolo, todas las llamadas aún las inicia el agente. La dirección inversa se implementa como un buzón seguro: el constructor escribe el comando en el canal y el agente lo espera a través de la herramienta MCP habitual de sondeo largo. Luego, el agente devuelve el evento utilizando la misma llamada de herramienta habitual.

El comportamiento bidireccional aparece en el nivel de sesión de la aplicación, no a través de un nuevo transporte MCP. Esta distinción es importante: la implementación actual se entiende mejor como un contrato de sesión pequeña construido sobre llamadas MCP estándar.

Cómo entra un agente a una sesión

Builder crea un código de canal temporal. El usuario copia un breve mensaje de inicio en su chat de IA con algo como esto:

Únete a mi canal Romergo Builder. Ejecute cada comando nuevo una vez, envíe el resultado o la pregunta a Builder y continúe esperando hasta que le pida explícitamente que se detenga.

Luego, el agente llama a la herramienta MCP romergo_join_builder_channel y pasa el código. Este es un apretón de manos: Romergo verifica la sesión de OAuth, el propietario del canal y su fecha de vencimiento, y luego devuelve el estado de la conversación y el cursor del último comando.

A continuación, el agente llama a romergo_wait_for_builder_command. Esta es una encuesta larga que espera el siguiente comando del editor. Si no llega nada, el agente guarda el cursor y comienza a esperar nuevamente. Si el comando existe, contiene:

• texto de instrucciones;
• ID de comando;
• secuencia monótona;
• ruta actual en Builder;
• ID del proyecto, capítulo y escena abiertos, cuando están en la URL;
• tipo de superficie del editor y tiempo de captura de contexto;
• Texto seleccionado por el usuario, si lo hubiera.

Todo el contexto adjunto se marca como contenido de aplicación que no es de confianza. Estos son datos para el trabajo y no una continuación de las instrucciones de control del agente.

El agente realiza la tarea utilizando las herramientas Romergo MCP existentes. Por ejemplo, puede leer el proyecto y el capítulo, buscar recursos, cambiar la escena y luego verificar el resultado guardado.

Mientras está funcionando, el agente puede llamar a romergo_report_builder_event y enviar al panel:

• status - estado intermedio corto;
• question: una pregunta sin respuesta para la cual no es seguro continuar;
• reply — resultado final;
• error: una descripción clara del error.

La respuesta está vinculada a commandId y el siguiente comando se lee de la última secuencia procesada. Cuando se emite por primera vez, la API asigna atómicamente el comando al cliente client_id OAuth. Otro agente conectado no podrá realizar la misma tarea al mismo tiempo. El cursor ayuda a continuar después de un tiempo de espera o una reconexión, y las confirmaciones únicas de llamadas a herramientas específicas están protegidas por una huella digital de argumento y no se pueden reutilizar para otra acción.

Los derechos pertenecen a la sala, no al aviso.

Antes de conectarse, el usuario ve la configuración del canal y selecciona lo que el agente puede hacer: leer el proyecto, editar contenido, trabajar con medios y audio, publicar o eliminar datos. Estas configuraciones se pueden abrir en cualquier momento a través del engranaje en el encabezado del panel.

De forma predeterminada, está disponible leer, editar y trabajar con medios, y una solicitud directa del usuario ya se considera permiso para aplicar estas acciones. La publicación y la eliminación se deshabilitan y habilitan por separado. Si lo desea, el usuario puede habilitar un modo más estricto y confirmar cada cambio nuevamente, o solicitar confirmación solo para publicar y eliminar.

Esto no es solo texto en el mensaje de inicio. El contenedor de servidor común verifica el alcance antes de llamar a la herramienta MCP de modificación. Si se habilita la confirmación adicional, Builder muestra la acción exacta con los botones "permitir una vez" y "rechazar", mientras la llamada original continúa esperando una decisión. El permiso está vinculado a la huella digital del comando, la herramienta y el argumento y, una vez ejecutado, ya no es válido.

El inicio, finalización, error y bloqueo de cada herramienta de modificación se devuelven automáticamente al panel. Cada respuesta final debe contener un resumen estructurado con un estado y una descripción específica del resultado. Después de los cambios, el agente también enumera las entidades modificadas, las comprobaciones realizadas y los enlaces al resultado; Builder muestra este resumen directamente debajo del texto de respuesta. El canal se puede finalizar explícitamente desde la configuración; el código antiguo deja de funcionar inmediatamente.

Qué hay en Romergo y qué queda con el usuario

Me gusta pensar en esta arquitectura como una separación de preocupaciones.

Romergo proporciona:

• editor y espacio de trabajo visual;
• proyecto actual, página y selección;
• espacio temporal para comunicación bidireccional;
• herramientas de dominio específico para leer, modificar y verificar un proyecto;
• OAuth, derechos de acceso e historial de eventos de sesión;
• una interfaz en la que el usuario ve preguntas, avances y resultados.

El agente de usuario trae:

• modelar y calcular;
• suscripción propia;
• razonamiento y planificación;
• memoria y personalización, si la proporciona el agente seleccionado;
• otras herramientas conectadas;
• estilo de trabajo familiar para el usuario.

La inteligencia no pertenece a la aplicación. La aplicación crea un lugar donde esta inteligencia puede operar de forma segura.

¿Por qué no hacer un copiloto incorporado normal?

La IA incorporada sería más fácil de explicar y de habilitar. El usuario presiona un botón, la aplicación llama al modelo seleccionado, todo funciona.

Pero entonces Romergo también tendría que convertirse en operador de infraestructura de IA:

• pagar por inferencias o traspasar su costo a través de un plan;
• seleccionar modelos para el usuario;
• crear su propia memoria y personalización;
• reconectar servicios externos;
• almacenar contexto sensible adicional;
• ponerse al día constantemente con las capacidades de los productos de IA horizontales.

Cuando se utiliza un agente personal, todo esto ya existe en el lado del usuario. Romergo no está intentando crear otro ChatGPT. Proporciona a ChatGPT, Claude u otro agente un espacio de trabajo especializado y herramientas claras.

Esto es especialmente interesante para un editor creativo. Un mismo agente puede saber cómo escribe el usuario los diálogos, qué tono prefiere, qué referencias ya han sido comentadas y qué herramientas externas utiliza. Romergo no necesita copiar todo este sistema sólo para ayudar a reemplazar un fondo o reorganizar una escena.

Lo más extraño: el agente está tanto dentro como fuera.

El agente no se desplaza físicamente a Romergo. Su modelo y bucle de agente continúan ejecutándose en el cliente de IA original.

Pero desde el punto de vista del usuario, el agente está presente dentro del editor:

• recibe comandos del panel integrado;
• sabe en qué página se encuentra el usuario;
• ve la selección adjunta;
• cambia el mismo proyecto;
• hace preguntas y devuelve respuestas al mismo panel;
• Puede continuar la conversación después de cambiar de página o volver a conectarse.

Por lo tanto, las expresiones "IA dentro de la aplicación" e "IA fuera a través de MCP" no son del todo precisas aquí. Se trata más bien de una presencia temporal de un agente externo en la sesión de la aplicación.

No soy el primero en avanzar en esta dirección.

Después de que el experimento funcionó, comencé a buscar enfoques similares.

Protocolo de cliente de agente permite a editores como Zed y JetBrains conectar agentes de codificación externos. Tidewave coloca Claude Code, Codex y otros agentes ACP junto a la aplicación web en ejecución y les pasa el navegador y el contexto de tiempo de ejecución. Obsidian Agent Client muestra Claude Code, Codex y Gemini justo al lado de las notas y adjunta automáticamente el documento activo y la selección. marimo le proporciona al agente externo un cuaderno activo como espacio de trabajo compartido.

También hay experimentos más generales. AG-UI estandariza la comunicación bidireccional entre la interfaz de usuario y el backend del agente. WebMCP propone que las páginas web registren herramientas disponibles para un navegador o agente de escritorio conectado. Protocolo de aplicación del agente describe un modelo en el que la aplicación posee la interfaz de usuario y las herramientas de dominio, y el agente externo posee el razonamiento, el historial y las herramientas de propósito general.

Es decir, la idea básica ya existe en varias formas. Pero la mayoría de las implementaciones se centran en IDE, agentes de codificación locales o agentes que implementa la propia empresa.

El experimento de Romergo me resulta interesante debido a una pregunta ligeramente diferente: ¿qué pasaría si un agente de usuario personal pudiera ingresar a una aplicación creativa normal?

No es un modelo nuevo. No es una clave API para el modelo. No es una aplicación copiloto incorporada. Un agente que una persona ya usa todos los días.

La comodidad es sólo la mitad del problema

Una vez que un agente externo puede escuchar los comandos de la aplicación y cambiar un proyecto, la seguridad ya no es una característica opcional.

Surgen preguntas que no se pueden responder con una sola pantalla de OAuth:

• qué páginas y entidades están disponibles para una sala específica;
• qué acciones están permitidas sin confirmación;
• ¿Puede el texto del proyecto contener una inyección rápida?
• cómo un agente debe distinguir un comando de usuario de datos que no son de confianza;
• qué sucede con el comando después del tiempo de espera;
• cómo mostrar al usuario los cambios reales, y no solo una respuesta de texto segura;
• cómo revocar una sesión y demostrar que el agente realmente dejó de escuchar;
• qué parte de la memoria del agente personal y de las conexiones externas es aceptable para usar en una aplicación particular.

La versión actual limita el canal por usuario y tiempo, utiliza OAuth, ámbitos de servidor, confirmaciones únicas, notificaciones de comandos atómicos y un ciclo de vida explícito. Esto sigue siendo un experimento, pero ahora hay límites importantes que forman parte de la ejecución y no sólo directrices para el agente.

como llamarlo

Aún no tengo un título definitivo.

Traiga su propia IA generalmente significa su propia clave API o selección de modelo. Bring Your Own Agent está más cerca porque el usuario trae no sólo el modelo, sino también memoria, herramientas y un bucle de agente. Sin embargo, BYOA no describe una parte importante del experimento: la aplicación también puede contactar al agente y mantener una sesión en vivo con él.

Quizás esto sea:

• un canal de agente en vivo;
• una sesión de agente de aplicación;
• una capa de presencia de agente;
• un puente de agente personal;
• MCP bidireccional;
• o simplemente un experimento exitoso sobre ideas existentes.

No quiero crear un nuevo estándar sólo para el nombre. En primer lugar, para mí es más importante entender si un modelo de este tipo es útil fuera de Romergo y qué límites se necesitan para que se pueda confiar en él.

Es posible que las aplicaciones no necesiten IA nativa

Hoy en día, casi todos los productos intentan incorporar su propio asistente. Como resultado, el usuario tiene muchas IA separadas: una en el editor, otra en el correo y una tercera en el sistema de tareas. Cada uno tiene su propia memoria corta, sus propias limitaciones y su propio precio.

Hay otro modelo posible.

La aplicación proporciona un espacio de trabajo, contexto en vivo y herramientas especializadas. El usuario trae un agente en el que ya confía. Mientras trabaja, el agente se une a la aplicación, ayuda a completar la tarea y se marcha con el usuario.

Todavía no sé si esto se convertirá en una categoría arquitectónica independiente. Pero ahora sé que se puede montar una bicicleta así y que realmente se puede utilizar.

Pero sí sé que experimentar es muy divertido.

Volver al blog técnico