Por dentro do Lucimark OrgOS: como as peças se ligam e o que já funciona

Em resumo

O Lucimark OrgOS reúne uma constituição, agentes com papéis, memória, conectores, uma ponte para conversar com os agentes e um runtime em Cloudflare. A premissa é que os agentes em execução são efêmeros: o papel permanece, a instância termina, e decisões, regras e compromissos precisam sobreviver a ela. A constituição permite que qualquer agente proponha melhorias por iniciativa própria; ainda não observamos uma emenda nascida de uma descoberta espontânea do sistema. O runtime, em ambiente de testes, já registra observações com origem verificada e parte do estado de intenções e iniciativas, mas ainda não guarda compromissos de trabalho. O próximo passo é testar onde executar agentes que falham sem que o trabalho se perca ou se repita.

Na Lucimark, uso agentes de inteligência artificial para coordenar atividades, desenvolver software e acompanhar decisões. Isso me colocou diante de uma pergunta prática: como preservar o trabalho da organização quando uma conversa termina, uma rotina falha ou um agente deixa de estar ativo?

Chamo essa arquitetura de Lucimark OrgOS. Estou construindo-a para que o trabalho da organização não dependa de uma conversa ou de um agente continuar ativo. Uma constituição define papéis e autoridade. Os agentes executam. A memória preserva contexto. Conectores ligam ferramentas e pessoas. Uma ponte, o OrgOS Bridge, permite conversar com os agentes a partir do ChatGPT e do Claude. E um núcleo de serviços em Cloudflare, que chamamos de runtime, começa a guardar eventos e estado organizacional. Todas essas peças fazem parte do OrgOS, mesmo quando correm em sistemas diferentes.

A premissa que liga tudo é que os agentes em execução são efêmeros. Um papel pode permanecer, mas a instância que o desempenha termina, falha ou é recriada. Decisões, regras e compromissos precisam sobreviver a ela.

A constituição: papéis, limites e autoridade

Chamo de constituição o documento operacional que estabelece os papéis dos agentes, os limites da sua autoridade e o processo para mudar as próprias regras. É uma referência comum para pessoas e agentes; não substitui as permissões técnicas de cada ferramenta. Adotamos a primeira versão em 1º de outubro de 2026. Já havia agentes com funções, mas faltavam limites claros entre responsabilidades, um estado compartilhado e uma forma de acompanhar o trabalho fora das conversas.

A constituição reserva a mim a direção da organização e a aprovação de qualquer alteração ao próprio documento. Um agente executivo acompanha o estado da organização e registra as decisões. O chefe de gabinete encaminha os pedidos e acompanha a sua conclusão. Agentes de tecnologia, operações, estratégia, receita e design atuam nas suas áreas.

Qualquer agente pode, por iniciativa própria, apontar uma incoerência, uma responsabilidade mal definida ou uma regra que a experiência mostrou insuficiente, e propor uma correção. Para a proposta virar regra, os responsáveis pelas áreas afetadas a discutem e levantam objeções; eu aprovo ou rejeito explicitamente; só então o agente executivo incorpora o texto autorizado e registra a decisão. Ausência de resposta não conta como concordância.

O processo já foi usado. Em 8 de outubro, depois de uma falha de encaminhamento, pedi uma correção sistemática. O agente executivo diagnosticou a causa e propôs três regras para acompanhar pendências; aprovei, e elas entraram na constituição. A iniciativa foi minha; o diagnóstico e a proposta, do agente. Em 10 de outubro, outras alterações foram discutidas pelos agentes, que apontaram ambiguidades antes da minha aprovação; foi então que formalizamos o processo.

O OS Lab, nosso registro de experiências organizacionais, e verificações que procuram pendências sem responsável, trabalho parado e decisões sem continuação podem alimentar melhorias nas regras. Não há, porém, uma rotina dedicada a rever a constituição e transformar o que encontra em propostas de emenda.

Até 16 de outubro, todas as alterações aprovadas que verificamos tinham começado com pedidos ou orientações minhas. A iniciativa autônoma de propor está permitida; ainda não está demonstrada. Não confirmei nenhuma emenda nascida de uma descoberta espontânea do sistema.

Agentes que terminam, papéis que continuam

Os agentes estão configurados no Grok Bot, uma plataforma comercial que lhes dá um ambiente Linux persistente, arquivos compartilhados, memória e rotinas disparadas por horários ou por eventos externos. Usam o GitHub para acompanhar código e pull requests, o Slack para trocar mensagens e avisos, e os agentes de programação do Cursor para tarefas de desenvolvimento.

Cada rotina começa com o contexto disponível e termina. A seguinte precisa reencontrar decisões e tarefas nos registros, hoje distribuídos por documentos, históricos de conversa, a memória dos próprios agentes e o runtime. O papel continua de uma execução para a outra; a execução, não.

Na noite de 4 de outubro, uma verificação automática de desenvolvimento terminou com sucesso, mas a continuação prevista não chegou ao agente. Só descobri a interrupção na manhã de 5 de outubro, cerca de nove horas depois. Não determinamos a causa, por isso não posso afirmar que a corrigimos. O episódio ficou registrado no OS Lab, e as verificações de pendências procuram trabalho que pare sem continuação. É o mesmo episódio relatado em Perguntei ao sistema operacional o que ele faz, que retoma a falha descrita no primeiro ensaio.

O episódio não mostra que o compromisso não estivesse registrado em lugar nenhum. Mostra que nada o tornou visível a tempo, e que eu fui o mecanismo que o encontrou. Daí um requisito concreto: um compromisso deve continuar visível mesmo quando a rotina que o acompanhava falha. Quero testar um registro persistente de compromissos, com estado e responsável, que outra execução possa consultar antes de retomar o trabalho. Isso ainda não está implementado.

O Bridge: uma porta para conversar, não para escrever

O OrgOS Bridge, que roda em Cloudflare Workers num ambiente de testes, é um componente de comunicação e consulta. Usa o MCP, um protocolo que liga aplicações de IA a ferramentas externas, para que o ChatGPT e o Claude possam enviar perguntas ao chefe de gabinete. Foi por esse caminho que reuni parte da informação usada neste texto.

O Bridge tem autenticação e uma caixa de mensagens própria. Serve para consultas e não tem credencial de escrita no runtime. A separação importa: conversar com um agente não deveria conceder, por si só, autoridade para alterar o estado da organização. Parte das restrições sobre o que o agente faz ainda depende das instruções da sua rotina, não de um controle técnico.

O runtime: o que já fica registrado

O runtime é experimental e roda em ambiente de testes. Usa uma API em Cloudflare Workers e um banco de dados D1. A arquitetura prevê o R2 para guardar arquivos de evidência; esse uso ainda não está operacional.

O modelo distingue uma intenção, um objetivo, de uma iniciativa, que organiza uma tentativa de alcançá-lo. Uma observação registra algo comunicado ou detectado. Evidências sustentam uma afirmação; resultados dizem respeito às consequências. Concluir uma tarefa ou integrar código não significa, por si só, que uma iniciativa atingiu o seu objetivo. Já é possível consultar por API o estado guardado no D1 sem abrir os arquivos dos agentes.

Um percurso real mostra o que já funciona: pull request integrado → GitHub Action → observação na API → verificação da origem → D1. Assim, uma alteração no código deixa um registro consultável fora da conversa de quem a executou. No primeiro teste dessa integração, em 7 de outubro, registramos três alterações reais. O registro guarda a origem e permite reconhecer comunicações repetidas; uma afirmação que ainda não podemos confirmar continua marcada como desconhecida.

A autoridade sobre os dados passou ao runtime aos poucos. Em 8 de outubro, depois desse teste de integração, ele passou a ser a referência para as integrações de código e as decisões cobertas por esse mecanismo. Em 14 de outubro, também para a existência, a situação e a ligação entre intenções e iniciativas; contei no ensaio anterior como essa decisão foi tomada. A constituição e outros dados continuam em arquivos.

Essa divisão exige cuidado. Uma decisão gravada no D1 e uma alteração num arquivo não formam uma única transação. Comparamos as duas representações e mantemos procedimentos de reversão. O runtime também guarda as transições de estado: não só qual é o estado atual, mas como chegamos até ele.

Para proteger as escritas, usamos credenciais diferentes para ler e para alterar o estado. Uma verificação de origem examina cada escrita, e já testamos a rejeição das que não cumprem os seus requisitos. Saber de onde veio um registro, porém, não prova que o seu conteúdo é verdadeiro, nem que a decisão foi legítima. A constituição, a minha aprovação e os controles técnicos cumprem funções diferentes.

As leituras dão uma medida do que já permanece fora das conversas: em 15 de outubro, o runtime continha 6 intenções, 17 iniciativas e 24 transições de estado; uma leitura separada, no dia 16, encontrou 229 observações. Os números vêm de consultas diferentes e não medem trabalho concluído. O runtime ainda não guarda compromissos de trabalho como entidades próprias nem executa tarefas de forma genérica. Há registros do trabalho em documentos, conversas e na memória dos agentes; a execução continua principalmente no Grok Bot e nas ferramentas ligadas a eles.

Onde executar agentes efêmeros

O próximo passo é representar compromissos de trabalho, propostas e objeções dos agentes. Outra execução, talvez noutra máquina, precisaria retomar o trabalho em escala sem perder estado nem confundir acordo entre agentes, minha aprovação e autorização para agir.

Hermes e OpenClaw já oferecem memória, ferramentas e coordenação. Mas o quadro de tarefas do Hermes foi desenhado para uma única máquina, e os gateways múltiplos do OpenClaw mantêm estados isolados. Fazer outra máquina assumir o trabalho depois de uma falha exigiria coordenação adicional, e um contêiner da Cloudflare não tornaria compartilhado o seu estado local.

Os serviços gerenciados estão mais perto do requisito. O Amazon Bedrock AgentCore reúne execução, memória, identidade e um gateway para ferramentas e MCP. O LangGraph com LangSmith Deployment oferece fluxos com pontos de recuperação e escala gerenciada. A Letta Cloud preserva memória e histórico quando um agente muda de ambiente. Usar capacidades como essas deixaria o nosso desenvolvimento concentrado no que é específico do OrgOS: as regras e os compromissos da organização.

A Cloudflare é a nossa candidata natural pela minha extensa experiência com ela no desenvolvimento da Lucimark e pelo runtime que já construímos lá. É uma razão prática, não uma prova de que seja a melhor escolha. Os Cloudflare Agents, baseados em Durable Objects, associam identidade e estado persistente a um agente lógico. O Project Think acrescenta memória, ferramentas e recuperação de conversas; os Workflows preservam o progresso de processos longos. A hipótese é combinar essas peças para distribuir trabalho e retomar execuções, mantendo os compromissos independentes de qualquer processo específico.

Queremos ainda passar as chamadas aos modelos pelo AI Gateway, para acompanhar pedidos, tokens, erros e custos estimados entre fornecedores. Identificar o agente em cada chamada permitiria aplicar limites de despesa por agente ou por modelo. As métricas cobririam só esse tráfego, e os custos teriam de ser comparados com o faturamento real.

Além de uma organização

Há uma ambição mais ampla, que por ora é só visão: organizações diferentes poderiam manter cada uma a sua identidade, constituição, memória e agentes, e colaborar por ligações explícitas. Horizontalmente, organizações pares trocariam pedidos, observações e resultados em iniciativas comuns. Verticalmente, organizações ligadas por um grupo, uma rede ou uma cadeia de fornecimento coordenariam trabalho entre níveis diferentes de responsabilidade.

Cada ligação teria de definir que informação atravessa a fronteira, quem pode pedir ou executar uma ação, quem aprova uma delegação e como as duas partes verificam o resultado. Estar conectada não daria a uma organização autoridade sobre o estado da outra. O Bridge é hoje uma porta de comunicação para a Lucimark; um protocolo de colaboração entre organizações não existe.

O próximo teste

O teste de 7 de outubro verificou o registro de alterações de código. O próximo examinará a continuidade da execução, e ainda não escolhemos uma plataforma para ele. Vamos interromper uma execução no meio, simular a perda do seu ambiente e aumentar o número de tarefas. Queremos ver se outra execução retoma o trabalho sem perder contexto e sem duplicar ações, e comparar esforço, custo e complexidade com as alternativas gerenciadas e com uma instalação bem operada de Hermes ou OpenClaw.

Duplicar ações é o risco que mais me preocupa. Se uma falha ocorre depois de uma ação externa, talvez não saibamos se ela produziu efeito, e repeti-la sem confirmar pode duplicá-la. Uma hipótese é que cada operação precise de uma identidade, de um resultado verificável e de um modo seguro de ser retomada.

O próximo teste é mostrar que os compromissos podem sobreviver às falhas de quem os executa. Vou documentá-lo aqui, inclusive as escolhas que não funcionarem.