O que o OrgOS já faz por mim na operação da Lucimark

Em resumo

Estou construindo o Lucimark OrgOS, um sistema operacional organizacional: o conjunto de agentes de IA com papéis definidos, as regras sob as quais trabalham e um registro estruturado da empresa que eles mantêm. Ainda não é um produto, mas já mudou coisas concretas na forma como trabalho. As minhas decisões ficam registradas em vez de dependerem da memória das conversas. Consigo delegar a execução sem delegar a autoridade. Uma promessa passou a exigir uma verificação. E a memória da organização pode ser corrigida sem apagar a história. Ainda não sei quanto tempo isso me poupa nem se aumenta a receita, mas já opero a Lucimark com menos dependência da minha memória individual.

Em 10 de outubro, perto do meio-dia, um serviço de produção da Lucimark começou a falhar. Catorze minutos depois, um agente decidiu reverter a versão, e em vinte minutos o serviço estava normal. Em menos de meia hora, outro agente tinha encontrado a causa no código. Uma hora e meia depois do primeiro erro, a correção estava pronta, testada e integrada no código.

Há pouco tempo, cada um desses passos teria passado por mim.

A Lucimark desenvolve infraestrutura de software para empresas que operam redes de telas digitais. Como fundador, preciso acompanhar produto, engenharia, infraestrutura e decisões estratégicas. E, como acontece em muitas empresas pequenas, uma parte desproporcional desse trabalho acaba dependendo de mim.

Não necessariamente porque eu seja a melhor pessoa para executar cada tarefa, mas porque sou quem conhece o contexto, entende as prioridades e sabe o que já foi decidido.

Nos últimos meses, comecei a construir uma alternativa a essa dependência: o Lucimark OrgOS, um sistema operacional organizacional. Com isso quero dizer o conjunto inteiro, não só a sua memória: agentes de IA com papéis definidos, as regras sob as quais trabalham e um registro estruturado da empresa que eles mantêm.

Ainda não é um produto comercial. Funciona internamente, com componentes em ambiente de testes, e está longe de resolver toda a operação.

Mas já mudou algumas coisas concretas na maneira como trabalho. Quatro, em particular: as minhas decisões já não se perdem nas conversas, consigo delegar a execução sem delegar a autoridade, uma promessa passou a exigir uma verificação, e a memória da empresa pode ser corrigida sem apagar a história.

As decisões deixaram de depender da memória das conversas

Uma das primeiras dificuldades que procurei resolver foi simples: como garantir que uma decisão tomada hoje continua sendo a mesma decisão amanhã?

Quando trabalho com vários agentes de IA, é fácil acumular conversas. Um agente propõe uma solução, outro implementa, um terceiro revisa. Enquanto isso, mudo uma prioridade ou estabeleço uma restrição.

O problema não é apenas transmitir essa informação. É garantir que existe um registro inequívoco daquilo que autorizei.

Antes, uma decisão minha vivia na conversa em que a tomei. Se dias depois fosse preciso saber o que eu tinha decidido, alguém tinha de encontrar essa conversa, ou confiar na memória: a de um agente ou a minha.

Hoje, um agente de coordenação me apresenta as decisões que precisam de mim, com as consequências e a possibilidade de reverter. Quando decido, a decisão fica escrita no registro do OrgOS, nas palavras exatas que usei, e é a esse registro que se volta, não à conversa. Em 8 de outubro, por exemplo, tomei treze decisões numa única sessão, e todas ficaram registradas assim.

Isso não torna as decisões melhores. Torna-as inequívocas. O ganho mais importante, para mim, não é a velocidade. É deixar de depender da memória de alguém para saber o que foi decidido.

Consigo delegar execução sem delegar autoridade

A engenharia da Lucimark já utiliza agentes especializados.

Cada agente tem a sua função e os seus limites.

A execução continua passando por mecanismos normais de engenharia: alterações de código, propostas de integração, testes, revisões e publicações de novas versões.

O OrgOS não substitui essas ferramentas: os seus agentes trabalham com elas, e o seu registro preserva o contexto organizacional: que intenção justifica determinado trabalho, que decisões o autorizam e que evidências existem sobre o resultado.

O incidente do início deste texto mostra bem a diferença. A alteração que o provocou só devia acrescentar medições ao serviço. A reversão, o diagnóstico e a correção, confirmada por testes, foram feitos por agentes. A minha parte foi aprovar a nova tentativa.

Os agentes fizeram esse trabalho, e o registro guardou o que eu tinha aprovado e com base em quê. As duas coisas são o OrgOS: uma parte age, a outra lembra. Ainda preciso supervisionar, mas já não sou o intermediário de cada passo técnico.

Uma promessa passou a exigir uma verificação

Na noite de 10 de outubro, estava previsto levar para produção a versão corrigida da alteração que, nesse mesmo dia, tinha provocado o incidente.

A publicação estava marcada para as 22h20 e não aconteceu: a rotina responsável abortou ao ler uma ordem antiga e não avisou ninguém.

Só na manhã seguinte o problema ficou claro.

O que me incomodou não foi a falha. Foi perceber que eu tinha tratado a promessa de um agente e a sua execução como uma coisa só.

É uma falha pequena na aparência, mas relevante para quem depende de agentes autônomos. Um agente pode afirmar que vai executar uma tarefa. Pode até iniciar o trabalho. Isso não significa que tenha terminado, nem que alguém tenha confirmado o resultado.

No dia 11, estabelecemos uma regra mais exigente: compromissos com horário precisam de uma verificação associada. Uma rotina que falha ou termina inesperadamente deve comunicar o problema ao responsável. A confirmação de conclusão tem de vir de quem efetivamente verificou.

Já ocorreram verificações agendadas sob esse novo processo. Ainda é cedo para demonstrar que o mecanismo resolve todos os casos.

Mas o critério mudou.

Uma tarefa prometida não é uma tarefa concluída. Uma tarefa executada não é necessariamente uma tarefa verificada.

O que ganho com isso é um critério que já não depende da minha atenção: só conta como concluído o que alguém verificou.

A memória da organização também precisa ser corrigível

Um sistema organizacional não pode se limitar a acumular informação. Precisa distinguir aquilo que aconteceu, aquilo que alguém relatou e aquilo que continua desconhecido.

No dia 10, carregamos no registro do OrgOS os objetivos da Lucimark: seis intenções e as catorze iniciativas que as servem. Conferimos cada um dos vinte registros com a origem, e todos batiam.

No caminho, a própria ferramenta de conferência errou: leu mal de onde vinha uma informação e acusou vinte diferenças que não existiam. Corrigimos.

Foi aí que percebi que não basta verificar. É preciso também poder verificar quem verifica.

Estamos construindo mecanismos de confiança, mas os próprios mecanismos também podem falhar.

Aliás, aconteceu algo semelhante enquanto eu preparava este artigo.

Pedi ao agente responsável pela coordenação operacional que me apresentasse dados reais da empresa. Na primeira resposta, ele forneceu uma contagem inconsistente de alterações de engenharia e descreveu incorretamente parte do incidente de 10 de outubro. Quando pedi que confrontasse as afirmações com os registros, corrigiu a resposta e reconheceu o que não tinha verificado.

Um agente de IA pode responder com convicção e estar errado. Atribuir a ele responsabilidades organizacionais não altera essa realidade.

O objetivo do OrgOS não é tornar os seus agentes infalíveis. É criar condições para que as afirmações possam ser verificadas, as contradições identificadas e as correções preservadas sem apagar a história.

É isso que ele já me permite: confrontar o que um agente afirma com o que ficou registrado.

O que continua dependendo de mim

Há uma fronteira que faço questão de preservar: os agentes podem propor, analisar e executar trabalho autorizado. Não podem assumir a autoridade estratégica do fundador.

Continuo responsável pelas intenções da empresa, pelas decisões de custo, pelas mudanças de política e pelas mudanças importantes na operação.

A própria alteração que provocou o incidente de 10 de outubro passou por mim: eu a aprovei de manhã, como exceção. A responsabilidade por essa decisão é minha, não dos agentes.

O silêncio não significa aprovação. Uma resposta rápida sem compreensão das consequências também não deve ser tratada como autorização válida.

Parte dessas proteções já existe no processo. Outra parte continua dependendo de regras seguidas pelos agentes, e não de mecanismos técnicos capazes de bloquear qualquer violação.

Não confundo as duas coisas.

O que pretendo não é uma empresa governada por agentes. É uma organização em que os agentes conseguem trabalhar dentro de limites claros, mantendo a autoridade e a responsabilidade humanas identificáveis.

O que mudou no meu dia a dia

Hoje, posso consultar a função de coordenação operacional para entender o estado dos trabalhos em curso, conhecer as verificações realizadas, identificar pendências e receber questões que precisam de uma decisão minha.

Não preciso acompanhar pessoalmente cada conversa entre agentes nem reconstruir manualmente todas as decisões a partir de mensagens dispersas.

Há também uma vigilância que já funciona sem mim. Uma rotina de um agente acompanha de forma proativa o uso da nossa plataforma de nuvem. Fica calada por padrão e só dá o alarme quando vê um pico súbito, um crescimento que se mantém ou algo que parece um erro.

Em 3 de outubro, sinalizou um possível erro num ambiente de testes, com o uso cerca de cinco vezes acima do normal. Em 7 de outubro, abriu um alerta na produção e o fechou em menos de uma hora, ao concluir que era crescimento real: mais telas conectadas. Foi a primeira vez que um alerta sobre a minha empresa foi aberto, investigado e fechado sem que eu precisasse fazer nada. Ela mede uso, não dinheiro, e não foi feita para detectar falhas. Mas já faz por mim uma vigília que eu não conseguiria manter sozinho.

O que ainda não tenho é uma medição confiável das horas que poupei.

Também não tenho um cálculo confiável do custo total desta operação, nem evidência de que o OrgOS tenha aumentado diretamente as vendas, a retenção de clientes ou a receita da Lucimark.

Por enquanto, o OrgOS não coordena o comercial, o marketing ou o suporte aos operadores. O seu uso mais concreto está na estruturação das decisões, na memória organizacional e no acompanhamento do trabalho realizado pelos agentes.

Seria fácil apresentar uma arquitetura ambiciosa e chamá-la de empresa autônoma. Seria muito mais difícil demonstrar que essa autonomia é confiável.

Prefiro começar pelo que consigo observar.

O próximo problema não é dar mais autonomia aos agentes

Como medir a qualidade de uma decisão? Como distinguir uma tarefa realmente concluída de uma conclusão apenas reportada? Como saber se os agentes estão gerando mais valor do que custo? Como preservar uma história organizacional que não muda arbitrariamente quando o contexto é reescrito?

Ainda não tenho respostas completas.

Durante muito tempo, o meu papel de fundador se confundiu com ser a memória, o coordenador e o mecanismo de correção da empresa.

O OrgOS está me permitindo experimentar uma separação dessas funções.

Continuo decidindo. Continuo responsável pelos resultados. Continuo intervindo quando algo dá errado.

A diferença é que começo a dispor de uma estrutura que registra o que foi decidido, acompanha o que foi executado e permite questionar o que me é apresentado como verdade.

Ainda não sei se isso vai se traduzir em crescimento mais rápido ou maior rentabilidade. Essas hipóteses terão de ser testadas.

O que já consigo afirmar é mais modesto: estou aprendendo a operar a Lucimark com menos dependência da minha memória individual e com mais disciplina sobre as decisões e a execução.

E, neste momento, esse é o resultado mais concreto do OrgOS.

O que vem a seguir é descobrir se essa disciplina também se mede em horas e em dinheiro. É a próxima pergunta que quero responder.