A vantagem competitiva está no arcabouço, não no modelo.

A resposta a incidentes moderna roda em torno das mesmas cinco investigações sobre os mesmos cinco runbooks, repetidas dezenas de milhares de vezes por dia em cada data center do planeta.

Um engenheiro sênior é chamado às 03h, gasta de 20 a 40 minutos provando qual das correções conhecidas se aplica, e a aplica. O trabalho é estruturalmente repetitivo; a pessoa é o gargalo; e o modo de falha é o descuido do operador sob fadiga — o serviço errado reiniciado na hora errada, o nome de host errado digitado em um comando destrutivo.

O OpenRemedy é uma plataforma de SRE autônoma que encerra esses incidentes sob o controle do operador. Ela executa o passo de verificação que hoje é feito por pessoas, propõe a correção que sabe ser segura, e executa apenas o que o operador aprovou — diretamente ou de antemão, por meio da escada de confiança.

Essa não é uma afirmação nova. Uma análise acadêmica recente da plataforma Claude Code, da Anthropic — um agente autônomo comparável no domínio adjacente da engenharia de software — descobriu que apenas 1,6% do código era lógica de decisão de IA; os outros 98,4% eram infraestrutura determinística: portas de permissão, gestão de contexto, roteamento de ferramentas, lógica de recuperação.^[1] Os modelos de fronteira estão convergindo em capacidade. A superfície competitiva duradoura é o sistema que decide o que mostrar ao modelo, o que o modelo pode tocar, e como se recuperar quando o modelo comete um erro.

O OpenRemedy é construído sobre essa tese, aplicada a um domínio diferente e a um comprador diferente.

O ciclo do agente é simples. Montar o contexto do incidente, chamar o modelo, despachar as ferramentas que o modelo quer chamar, verificar se o operador autorizou essas ferramentas a rodar neste host, executar as que passam, coletar os resultados, repetir até o modelo dizer que terminou. Talvez duzentas linhas de código.

O que envolve o ciclo é a plataforma.

Toda caixa fora de Triagem e Diagnóstico é infraestrutura determinística. O agente não decide se uma receita é segura para rodar neste host; a plataforma decide. O agente não escreve no log de auditoria; a plataforma escreve. O agente não promove um servidor de shadow para live; a plataforma promove, e só depois que um operador clicou em aceitar sobre uma sugestão que a plataforma conquistou com resultados registrados.

Isso não é uma restrição que aceitamos a contragosto. É o design.

A mesma lógica governa o que o modelo chega a ver. A plataforma monta o contexto do incidente a partir de fatos coletados — a topologia real do servidor, o serviço realmente vinculado à porta que está falhando, a política que disparou o alerta — de modo que o modelo raciocina a partir de informação verificada, e não de uma descrição em texto livre que pode estar desatualizada. Decidir o que colocar na frente do modelo já é, por si só, trabalho de arcabouço, não trabalho de modelo.

Os modelos de fronteira vão continuar melhorando, e quem compra uma plataforma de operações autônomas — sobretudo em setores regulados — não está comprando um modelo. Está comprando a superfície de controle do operador, a trilha de auditoria, as portas de segurança, a capacidade de defender uma correção diante de um auditor. Nada disso vem do modelo. Tudo vem do arcabouço.

Quando decidimos o que construir a seguir, perguntamos: isso torna a plataforma mais inteligente, ou torna o arcabouço mais confiável? Preferimos a segunda opção.

Cada decisão arquitetural do OpenRemedy remete a um de cinco valores. Os valores não são aspiracionais; são critérios de decisão. Quando duas alternativas de design funcionam igualmente bem do ponto de vista técnico, escolhemos a que pontua mais alto nos cinco.

As pessoas são donas de toda ação que importa. O agente propõe; o operador decide. Isso é uma regra dura, não um padrão que pode ser relaxado. A plataforma se recusa a implantar uma configuração em que um LLM possa autoautorizar uma remediação fora dos limites que o operador definiu explicitamente.

A escada de confiança (audit → shadow → live) é o mecanismo pelo qual os operadores concedem autonomia em etapas. Um servidor em modo audit nunca vê uma proposta de remediação. Um servidor em modo shadow vê toda proposta pausar esperando aprovação humana, independentemente da porta de confiança × risco que governa o modo live. A promoção entre modos é conduzida pelo operador, com uma trilha de auditoria que registra quem decidiu conceder autonomia, quando, e com base em qual evidência.

Uma barreira de segurança que depende de um único mecanismo não é defesa em profundidade — é defesa de fachada. A plataforma roda cinco portas de controle independentes antes de qualquer remediação, cada uma com um modo de falha diferente.

Se duas dessas portas dependessem do mesmo serviço externo — por exemplo, se todas precisassem de uma chamada a um LLM para avaliar — elas não seriam cinco portas. Seriam uma única porta usando cinco chapéus. Auditamos explicitamente em busca de modos de falha compartilhados e separamos as camadas quando elas coincidem. Esse é o princípio que Liu et al. apontam como o padrão de falha mais comum em plataformas de agentes: uma defesa em profundidade que degenera em um único ponto de falha sob carga.

Conceder a um agente a autoridade para agir sobre infraestrutura de produção não é uma decisão binária. É um gradiente, e o trabalho da plataforma é tornar esse gradiente legível.

Cada servidor do OpenRemedy vive em um de três modos.

No modo audit, o agente classifica o incidente e o resolve imediatamente. Nenhuma remediação é proposta; nada é executado; o operador ganha visibilidade sem nenhum compromisso.

No modo shadow, o agente executa o pipeline completo de diagnóstico e proposta, e toda proposta espera aprovação humana.

No modo live, a porta de confiança × risco decide se uma receita roda de forma autônoma.

Um servidor entra em modo audit e só conquista o caminho até live por meio de aprovações do operador registradas — não por configuração, nem por uma decisão pontual que o operador poderia esquecer. A escada de promoção gera sugestões quando um par (servidor, receita) acumula pelo menos dez aprovações sem nenhuma rejeição em uma janela de 30 dias. O operador aceita ou descarta; a plataforma nunca se autopromove.

Estar pronto para auditoria não é uma funcionalidade adicionada no fim da construção. É uma restrição aplicada em cada camada.

Toda ação que muda estado escreve uma linha de auditoria marcada com o tenant, o ator, o endereço IP e a mudança exata. O log de auditoria é somente-anexação. O raciocínio de cada incidente pode ser reconstruído a partir da linha do tempo, não de um resumo opaco de fornecedor. A memória — o corpus de resoluções anteriores do qual o agente aprende — vai ser servida como arquivos markdown simples por tenant, versionáveis e exportáveis a qualquer momento. Os operadores são donos dos próprios dados.

Preferimos auditabilidade a poder de consulta quando os dois entram em conflito. Um auditor de compliance quer ler a trilha; um painel quer filtrá-la. O primeiro vence.

Não estamos construindo um agente generalista. Estamos construindo um executor de runbooks para frotas Linux.

Agentes generalistas de código como o Claude Code respondem à pergunta "o que um engenheiro sênior faria aqui?" sobre uma superfície ampla. O OpenRemedy responde a uma pergunta mais estreita: "dado um formato de incidente conhecido em um tipo de servidor conhecido, qual das cinco correções conhecidas se aplica, e é seguro executá-la agora?".

A pergunta mais estreita nos permite ser mais específicos em cada camada. Nosso catálogo de receitas é curado, não sintetizado. Nossos prompts de agente são específicos por domínio. Nossa escada de confiança é por receita e por servidor, não um controle global de autonomia. Nosso classificador de segurança já está em produção, executando uma chamada de LLM independente antes de qualquer execução automática; treinar uma versão por tenant sobre o corpus de incidentes real de cada tenant, em vez de um modelo de propósito geral, é o próximo passo.

A superfície de produto com a qual o operador interage — a forma visível da plataforma — é governada por quatro mecanismos sobrepostos entre si.

O controle mais grosso. Cada servidor está em modo audit, shadow ou live. O modo determina quais etapas do pipeline do agente são executadas.

Os operadores nunca precisam escolher entre "o agente tem autonomia total" e "o agente não tem nenhuma". A escada de confiança registra toda aprovação, toda rejeição, toda execução automática e toda falha pós-execução para cada par (servidor, receita). Quando um par acumula dez aprovações sem nenhuma rejeição em 30 dias, a plataforma sugere a promoção.

O que "Aceitar" faz depende do modo atual do servidor. Em um servidor shadow, aceitar promove o servidor para live — o mecanismo histórico. Em um servidor já em live, aceitar concede uma substituição de papel de receita por tenant para a tupla (receita, papel do servidor): na próxima vez que o pipeline propuser essa receita em um servidor com esse papel, a porta de confiança × risco é pulada e a etapa de validação é ignorada. O operador pode revogar a substituição a qualquer momento na página de Agentes; a revogação restabelece a porta de controle.

A plataforma nunca se autopromove. Os limites mínimos são 5 aprovações em 7 dias; abaixo disso, nenhuma sugestão é gerada. O caminho da substituição é igualmente explícito por parte do operador — nunca é concedido sem um clique em Aceitar, e uma única rejeição na janela desqualifica o par. Juntos, isso evita um descuido do tipo "autopromoção na primeira aprovação", ao mesmo tempo em que deixa receitas de confiança saírem da fila de aprovação sem mudar a postura de todo um servidor.

Independentemente do modo, qualquer execução pendente pode ser marcada como pré-visualização. Uma execução de pré-visualização aplica a receita em modo simulação contra o host — informando o que mudaria, sem aplicar de fato — e termina em um estado dedicado de pré-visualização-concluída, distinto do estado de sucesso.

Execuções de pré-visualização não avançam o incidente para revisão (não há nada para revisar), não aparecem nas métricas que contam mudanças aplicadas, e escondem o botão de rollback (não há nada para desfazer). O operador escolhe a pré-visualização no momento da aprovação, por execução.

Esses mecanismos se combinam. Um servidor em shadow pode rodar uma pré-visualização de uma proposta antes de decidir se aprova a execução real. Um servidor em live pode rodar uma pré-visualização de uma receita arriscada antes de deixar a porta de confiança × risco executar automaticamente a próxima. Um servidor em audit não vai mostrar nenhuma execução. Planos de manutenção se sobrepõem aos três — um passo de plano roda sob o mesmo modo de servidor e a mesma mecânica de pré-visualização que uma execução disparada por incidente, de modo que um passo de reinício escalonado em um servidor live é controlado exatamente como qualquer outra remediação.

A resposta a incidentes é reativa. O mesmo arcabouço também executa mudanças planejadas. Um plano de manutenção é um documento markdown com cabeçalho YAML (risco, estratégia, dimensões de snapshot) e uma sequência de passos tipados — validate, custom_tool, recipe, wait, notify, human_gate. Cada passo declara se exige aprovação; o mesmo modelo de porta de controle que governa a remediação de incidentes governa também cada passo não trivial aqui.

Os planos rodam sob uma estratégia: rolling (um servidor por vez, fácil de abortar no meio da frota), parallel_batched (tamanho de lote fixo com período de estabilização), rings (canary → piloto → amplo, com períodos de estabilização por anel). Na aprovação, o markdown do plano é congelado no agendamento, de modo que edições futuras no template do plano nunca afetam uma execução já aprovada; edições do operador no próprio agendamento são preservadas ao longo da aprovação. Um editor de IA permite que o operador redija e revise o markdown de forma conversacional antes de aprovar, e uma entrada de log de auditoria registra cada mudança feita por chat, de modo que a história da mudança planejada fica tão inspecionável quanto a da resposta a incidentes.

A escada de confiança e a porta de aprovação decidem quem pode executar o quê. O OpenRemedy Guardian decide algo mais estreito e mais direto: se a ação específica diante da plataforma é do tipo que destrói dados ou derruba um sistema — um disco apagado, um banco de dados excluído, um firewall zerado, uma reinicialização forçada do host errado — não importa quão rotineira a solicitação ao redor pareça.

O Guardian é um modelo dedicado que roda antes da porta de aprovação, como um sinal de pré-triagem independente. Ele lê a operação que está prestes a ser executada — o comando concreto, não só o alerta que o disparou —, reconhece intenção destrutiva mesmo quando ela está disfarçada, e atribui uma severidade. Essa severidade é incorporada ao risco da ação antes que a porta de controle a veja: a plataforma usa o maior valor entre o risco declarado no catálogo e a leitura do Guardian. Uma receita com aparência rotineira que se revela destrutiva é escalada automaticamente para aprovação humana.

O Guardian nunca relaxa uma decisão — ele só pode elevar o risco, nunca reduzi-lo — e nunca executa nada por conta própria. É um domínio de falha separado do modelo que raciocina sobre o incidente e da porta que autoriza a execução, de modo que uma ação destrutiva precisa passar pelas três barreiras de forma independente. Quando o Guardian fica inacessível, cada tenant escolhe a postura: seguir adiante, com as portas de controle existentes de pé, ou forçar aprovação humana até ele voltar.

Toda leitura que o Guardian faz é registrada na linha do tempo do incidente, de modo que o operador consegue ver rapidamente que a plataforma examinou uma ação e a considerou segura — ou que deu o alarme e encaminhou a ação para uma pessoa.

O OpenRemedy está em teste privado. O fundador o usa contra a própria infraestrutura de produção privada antes de abrir a plataforma para outros operadores. Ainda não há clientes externos, por design.

O que esse uso interno produziu, no momento em que este texto foi escrito:

Os 76 incidentes que não avançaram até a execução foram classificados como transitórios ou eram artefatos de bugs da plataforma que encontramos usando-a nós mesmos — o mesmo motivo pelo qual fazemos isso, para encontrá-los antes que um cliente real o faça. As resoluções mais rápidas (quase instantâneas) foram, em geral, reclassificações automatizadas; as mais lentas (até cerca de seis minutos) foram investigações que chamaram várias ferramentas de diagnóstico antes de decidir. O Guardian, em produção desde junho, já avaliou 69 decisões na etapa de execução — um registro pequeno, mas real, da verificação de risco anterior à porta de controle funcionando de fato contra tráfego de produção, não apenas contra testes de laboratório.

Os números são pequenos. O que importa nesta fase é o formato da implantação: um único operador com vinte anos de experiência em produção com Linux, rodando a plataforma contra a própria infraestrutura, encontrando bugs ao usá-la, e lançando uma melhoria cada vez que encontra um. A infraestrutura já é madura o suficiente para que o operador não precise ficar de olho nela; o modelo especializado por tenant que vem a seguir vai permitir generalizar além da intuição de um único operador.

A plataforma atual cobre a cunha de fechamento de ciclo para frotas Linux — alertas de entrada, classificação, diagnóstico, remediação controlada e auditoria. O roteiro se estende em duas direções.

Profundidade. O classificador de segurança descrito no §03 — uma chamada de LLM independente com prompt reforçado, entre a porta de confiança × risco e o despacho ao worker — já está em produção. Seu único trabalho é responder sim ou não à pergunta "essa ação específica é segura neste host específico agora?". Ele nunca pode relaxar as portas existentes; só pode vetar. O próximo passo é treinar uma versão por tenant sobre o próprio corpus de incidentes resolvidos do tenant, em vez de um modelo de propósito geral, e encaixá-la nessa mesma posição de classificador.

Uma memória baseada em arquivos por tenant — arquivos markdown exportáveis e versionáveis em vez de linhas opacas de banco de dados — vai substituir o corpus de resolução atual. Transcrições paralelas vão capturar o raciocínio completo de cada etapa do pipeline como JSONL, separadamente da visão resumida do painel.

Amplitude. A cunha atual é fechar incidentes sobre infraestrutura já existente. A trajetória é o ciclo de vida completo da infraestrutura de um operador sob uma única superfície agêntica — o que pensamos como vibe deploy, ao lado do vibe coding que a indústria já tem. Descreva um projeto; a plataforma escolhe a nuvem, provisiona, vigia, corrige o que quebra, e faz crescer um corpus de resolução por tenant do qual o operador é o dono. A cunha desbloqueia o resto: no momento em que um operador confia na plataforma para encerrar um incidente de nível um às três da manhã, ele confia nela para implantar o próximo ambiente, e o mesmo ciclo agêntico cuida dos dois.

A ideia é grande e o caminho é longo. Sabemos com o que estamos nos comprometendo.

Três coisas que aprendemos construindo isso.

O arcabouço é auditável; o modelo não é. Quando um auditor de compliance pergunta por que uma correção foi aplicada, a resposta não pode ser "o modelo decidiu". A resposta tem que ser uma cadeia de decisões da plataforma — em que modo o servidor estava, qual nível de confiança o agente tinha, qual nível de risco a receita carregava, quem aprovou, o que a plataforma registrou — terminando com o raciocínio do modelo como só mais uma entre várias entradas. O arcabouço é o que produz uma trilha de auditoria defensável.

Modos de falha independentes são a única defesa em profundidade real. Cinco portas que dependem todas do mesmo provedor de LLM são uma única porta. Cinco portas que dependem de um modo de servidor (definido pelo operador), risco de receita (curado no catálogo), nível de confiança (por agente), filtro de ferramentas (fixo no código) e uma chamada de classificador separada (um LLM independente) falham em condições diferentes e dão ao operador uma margem de segurança real. Auditar a independência desde o início; corrigir antes que o sistema cresça.

Gradientes de confiança vencem interruptores de confiança. Operadores não querem uma caixinha que diz "deixa a IA cuidar disso". Eles querem um caminho da observação até a autonomia que possam percorrer passo a passo, sobre o qual possam demonstrar defensabilidade, e do qual possam voltar em qualquer ponto. Construir a plataforma em torno desse caminho é a diferença entre algo que um operador vai rodar em infraestrutura de produção e algo em que ele dá uma demonstração de cinco minutos e nunca mais toca.

Nada disso é exclusivo do OpenRemedy. São as consequências de levar operações autônomas a sério o bastante para colocá-las na frente de um comprador com exigências de compliance. A tecnologia é o modelo; o produto é o arcabouço.