Experimento de IA

Convidei meu agente de IA para Romergo e não sei o que é isso ou como chamá-lo.

A maioria das integrações de IA em aplicativos são projetadas de forma previsível. O produto adiciona um botão spark, envia uma solicitação para seu próprio modelo e exibe a resposta na barra lateral.

Existe outra opção comum. A aplicação fornece um servidor MCP, e o usuário abre ChatGPT, Claude ou outro agente e solicita que ele trabalhe com os dados da aplicação. Isso dá boas ferramentas ao agente, mas a conversa acontece em outro lugar. Você precisa sair do editor, explicar o que está aberto no momento, voltar e verificar o resultado.

Cansei de alternar entre o chat e o editor e me ocorreu uma ideia: e se eu pudesse evitar isso totalmente?

Adicionei um painel AI diretamente no editor, mas não o conectei a um modelo hospedado por Romergo. Em vez disso, o usuário convida seu agente pessoal de IA para a sessão aberta.

O agente permanece onde já mora: no ChatGPT, Claude, Codex ou outro cliente compatível com MCP. Mantém seu modelo, assinatura, memória, configurações e ferramentas disponíveis. Romergo fornece apenas um espaço de trabalho, contexto atual e ferramentas especializadas para edição de um projeto.

Após a conexão, o usuário pode escrever para o agente diretamente do Builder:

• descreva a cena aberta;
• mude a música neste capítulo;
• reescrever o diálogo destacado;
• coloque um fundo diferente;
• verifique a lógica de transição;
• explique por que a cena não funciona da maneira que eu esperava.

Respostas, perguntas e status intermediários são retornados ao mesmo painel. O painel mostra não apenas o texto, mas também todo o ciclo da tarefa: um comando foi recebido, atribuído a um agente, ferramentas estão sendo executadas, é necessária confirmação, o trabalho foi concluído ou ocorreu um erro. Você não precisa mais sair do editor.

Tudo começou como um experimento

Eu não tinha intenção de inventar um novo protocolo ou de criar uma nova categoria de produto. Eu queria testar uma ideia simples: um agente de usuário pessoal poderia não apenas controlar Romergo externamente via MCP, mas também participar temporariamente de uma sessão ao vivo dentro do editor?

A primeira versão foi um experimento. Para minha surpresa, funcionou bem o suficiente para eu começar a usá-lo sozinho.

O diagrama mais curto pode ser desenhado assim:

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

Mas a sinalização nas duas direções é importante.

Uma chamada típica do MCP começa no agente: o agente decide entrar em contato com a aplicação e chama sua ferramenta. Na minha experiência, Romergo também pode iniciar o trabalho. O usuário escreve um comando no Builder, Romergo coloca em um canal seguro e o agente já conectado recebe o comando via MCP.

O agente então utiliza as ferramentas usuais do Romergo para ler ou modificar o projeto e retornar o resultado ao Builder pelo mesmo canal.

Isso cria um ciclo fechado:

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 não executa o modelo em nenhuma dessas etapas.

Ao mesmo tempo, não alterei o próprio MCP e não adicionei um push de servidor real a ele. Do ponto de vista do protocolo, todas as chamadas ainda são iniciadas pelo agente. A direção inversa é implementada como uma caixa de correio segura: o Builder grava o comando no canal e o agente espera por ele por meio da ferramenta MCP usual de pesquisa longa. Em seguida, o agente envia o evento de volta usando a mesma chamada de ferramenta usual.

O comportamento bidirecional aparece no nível da sessão do aplicativo, e não por meio de um novo transporte MCP. Esta distinção é importante: a implementação atual é melhor entendida como um contrato de sessão pequena construído sobre chamadas MCP padrão.

Como um agente entra em uma sessão

O Builder cria um código de canal temporário. O usuário copia um breve prompt inicial em seu bate-papo de IA com algo assim:

Participe do meu canal Romergo Construtor. Execute cada novo comando uma vez, envie o resultado ou pergunta de volta ao Builder e continue esperando até que eu peça explicitamente para você parar.

O agente então chama a ferramenta MCP romergo_join_builder_channel e passa o código. Este é um handshake: Romergo verifica a sessão OAuth, o dono do canal e sua data de expiração, e então retorna o estado da conversa e o último cursor de comando.

Em seguida, o agente chama romergo_wait_for_builder_command. Esta é uma enquete longa que aguarda o próximo comando do editor. Se nada chegar, o agente salva o cursor e começa a esperar novamente. Se o comando existir, ele contém:

• texto de instrução;
• ID do comando;
• sequência monotônica;
• caminho atual no Builder;
• IDs do projeto aberto, capítulo e cena, quando estiverem na URL;
• tipo de superfície do editor e tempo de captura de contexto;
• texto selecionado pelo usuário, se houver.

Todo o contexto anexado é marcado como conteúdo de aplicativo não confiável. Estes são dados para trabalho e não uma continuação da instrução de controle do agente.

O agente executa a tarefa usando ferramentas existentes do Romergo MCP. Por exemplo, ele pode ler o projeto e o capítulo, encontrar ativos, alterar a cena e verificar o resultado salvo.

Enquanto estiver funcionando, o agente pode ligar para romergo_report_builder_event e enviar o painel:

• status - status intermediário curto;
• question - uma pergunta sem resposta para a qual não é seguro continuar;
• reply — resultado final;
• error – uma descrição clara do erro.

A resposta está vinculada a commandId e o próximo comando é lido a partir da última sequência processada. Quando emitida pela primeira vez, a API atribui atomicamente o comando ao cliente OAuth client_id. Outro agente conectado não poderá realizar a mesma tarefa ao mesmo tempo. O cursor ajuda a continuar após um tempo limite ou reconexão, e as confirmações únicas de chamadas de ferramentas específicas são protegidas por uma impressão digital de argumento e não podem ser reutilizadas para outra ação.

Os direitos pertencem à sala, não ao prompt

Antes de se conectar, o usuário visualiza as configurações do canal e seleciona o que o agente pode fazer: ler o projeto, editar conteúdo, trabalhar com mídia e áudio, publicar ou excluir dados. Essas configurações podem ser abertas a qualquer momento através da engrenagem no cabeçalho do painel.

Por padrão, estão disponíveis leitura, edição e trabalho com mídia, e uma solicitação direta do usuário já é considerada permissão para aplicar essas ações. A publicação e a exclusão são desabilitadas e habilitadas separadamente. Se desejar, o usuário pode ativar um modo mais rigoroso e confirmar novamente cada alteração, ou exigir confirmação apenas para publicação e exclusão.

Este não é apenas um texto no prompt de início. O wrapper de servidor comum verifica o escopo antes de chamar a ferramenta de modificação do MCP. Se a confirmação adicional estiver habilitada, o Builder mostra a ação exata com os botões "permitir uma vez" e "rejeitar", enquanto a chamada original continua aguardando uma decisão. A permissão está vinculada à impressão digital do comando, ferramenta e argumento e, uma vez executada, não é mais válida.

O início, conclusão, erro e bloqueio de cada ferramenta de modificação são retornados automaticamente ao painel. Cada resposta final deve conter um resumo estruturado com status e descrição específica do resultado. Após as alterações, o agente também lista as entidades alteradas, as verificações realizadas e vincula o resultado; O Builder exibe este resumo diretamente abaixo do texto da resposta. O canal pode ser encerrado explicitamente nas configurações; o código antigo para de funcionar imediatamente.

O que está no Romergo e o que fica com o usuário

Gosto de pensar nesta arquitetura como uma separação de preocupações.

Romergo fornece:

• editor e espaço de trabalho visual;
• projeto atual, página e seleção;
• sala temporária para comunicação bidirecional;
• ferramentas específicas de domínio para leitura, modificação e verificação de um projeto;
• OAuth, direitos de acesso e histórico de eventos de sessão;
• uma interface na qual o usuário vê dúvidas, progresso e resultados.

O agente do usuário traz:

• modelar e calcular;
• assinatura própria;
• raciocínio e planejamento;
• memória e personalização, se fornecidas pelo agente selecionado;
• outras ferramentas conectadas;
• estilo de trabalho familiar ao usuário.

A inteligência não pertence à aplicação. O aplicativo cria um local onde essa inteligência pode operar com segurança.

Por que não fazer um copiloto integrado regular

A IA integrada seria mais fácil de explicar e mais fácil de ativar. O usuário aperta um botão, o aplicativo chama o modelo selecionado, tudo funciona.

Mas então Romergo também teria de se tornar um operador de infraestrutura de IA:

• pagar por inferência ou repassar seu custo por meio de um plano;
• selecione modelos para o usuário;
• crie sua própria memória e personalização;
• reconectar serviços externos;
• armazenar contexto sensível adicional;
• acompanhar constantemente as capacidades dos produtos horizontais de IA.

Ao usar um agente pessoal, tudo isso já existe do lado do usuário. Romergo não está tentando construir outro ChatGPT. Dá ao ChatGPT, Claude ou outro agente um espaço de trabalho especializado e ferramentas claras.

Isto é especialmente interessante para um editor criativo. The same agent can know how the user writes dialogue, what tone they prefer, which references have already been discussed, and which external tools they use. Romergo não precisa copiar todo esse sistema apenas para ajudar a substituir um plano de fundo ou reorganizar uma cena.

A parte mais estranha: o agente está fora e dentro

O agente não se desloca fisicamente para Romergo. Seu modelo e loop de agente continuam em execução no cliente de IA original.

Mas do ponto de vista do usuário, o agente está presente dentro do editor:

• recebe comandos do painel integrado;
• sabe em qual página o usuário está;
• vê a seleção anexada;
• muda o mesmo projeto;
• faz perguntas e retorna respostas ao mesmo painel;
• pode continuar a conversa depois de mudar de página ou reconectar.

Portanto, as expressões “IA dentro da aplicação” e “IA fora via MCP” não são totalmente precisas aqui. É antes uma presença temporária de um agente externo na sessão do aplicativo.

Eu não sou o primeiro a seguir nessa direção

Depois que o experimento funcionou, comecei a procurar abordagens semelhantes.

Protocolo Agente Cliente permite que editores como Zed e JetBrains conectem agentes de codificação externos. Tidewave coloca Claude Code, Codex e outros agentes ACP próximos ao aplicativo da web em execução e passa a eles o navegador e o contexto de tempo de execução. Cliente Agente Obsidian mostra Claude Code, Codex e Gemini ao lado das notas e anexa automaticamente o documento ativo e a seleção. marimo fornece ao agente externo um live notebook como um espaço de trabalho compartilhado.

Existem também experimentos mais gerais. AG-UI padroniza a comunicação bidirecional entre a interface do usuário e o backend do agente. WebMCP propõe que as páginas web registrem ferramentas disponíveis para um navegador conectado ou agente desktop. Protocolo de Aplicativo do Agente descreve um modelo no qual o aplicativo possui a UI e as ferramentas de domínio, e o agente externo possui o raciocínio, o histórico e as ferramentas de uso geral.

Ou seja, a ideia básica já existe em diversas formas. Mas a maioria das implementações concentra-se em IDEs, agentes de codificação locais ou agentes implantados pela própria empresa.

O experimento Romergo é interessante para mim por causa de uma questão um pouco diferente: o que aconteceria se um agente de usuário pessoal pudesse entrar em um aplicativo criativo normal?

Não é um modelo novo. Não é uma chave de API para o modelo. Não é um aplicativo copiloto integrado. Um agente que uma pessoa já usa todos os dias.

A conveniência é apenas metade do problema

Depois que um agente externo pode escutar comandos do aplicativo e alterar um projeto, a segurança não é mais um recurso opcional.

Surgem perguntas que não podem ser respondidas com uma tela do OAuth:

• quais páginas e entidades estão disponíveis para uma sala específica;
• quais ações são permitidas sem confirmação;
• o texto do projeto pode conter injeção imediata;
• como um agente deve distinguir um comando do usuário de dados não confiáveis;
• o que acontece com o comando após o tempo limite;
• como mostrar ao usuário as alterações reais, e não apenas uma resposta de texto confiável;
• como revogar uma sessão e comprovar que o agente realmente parou de escutar;
• que parte da memória do agente pessoal e das conexões externas é aceitável para uso em uma aplicação específica.

A versão atual limita o canal por usuário e tempo, usa OAuth, escopos de servidor, confirmações únicas, declarações de comando atômico e um ciclo de vida explícito. Isto ainda é um experimento, mas limites importantes agora fazem parte da execução e não apenas diretrizes para o agente.

Como chamar isso

Ainda não tenho um título definitivo.

Traga sua própria IA geralmente significa sua própria chave de API ou seleção de modelo. O Bring Your Own Agent está mais próximo porque o usuário traz não só o modelo, mas também memória, ferramentas e um loop de agente. Porém, BYOA não descreve uma parte importante do experimento: a aplicação também pode entrar em contato com o agente e manter uma sessão ao vivo com ele.

Talvez seja isto:

• um canal de agente ao vivo;
• uma sessão de agente de aplicação;
• uma camada de presença de agente;
• uma ponte de agente pessoal;
• MCP bidirecional;
• ou apenas uma experiência bem-sucedida com base em ideias existentes.

Não quero criar um novo padrão apenas para o nome. Primeiro, é mais importante para mim compreender se tal modelo é útil fora do Romergo e quais limites são necessários para que ele seja confiável.

Os aplicativos podem não precisar de IA nativa

Hoje, quase todo produto tenta construir seu próprio assistente. Como resultado, o usuário tem muitas IAs separadas: uma no editor, outra no correio, uma terceira no sistema de tarefas. Cada um tem sua memória curta, suas limitações e seu preço.

Existe outro modelo possível.

O aplicativo fornece um espaço de trabalho, contexto ao vivo e ferramentas especializadas. O usuário traz um agente em quem já confia. Enquanto trabalha, o agente entra na aplicação, ajuda a concluir a tarefa e sai com o usuário.

Ainda não sei se esta se tornará uma categoria arquitetônica independente. Mas agora sei que tal ciclo pode ser montado e que pode realmente ser usado.

Mas sei que experimentar é muito divertido.

Voltar ao blog técnico