El foso competitivo es el andamiaje, no el modelo.

La respuesta a incidentes moderna se basa en las mismas cinco investigaciones sobre los mismos cinco runbooks, repetidas decenas de miles de veces al día en cada centro de datos del planeta.

Un ingeniero senior recibe un aviso a las 03:00, dedica entre 20 y 40 minutos a comprobar cuál de las soluciones conocidas aplica, y la aplica. El trabajo es estructuralmente repetitivo; la persona es el cuello de botella; y el modo de fallo es el descuido del operador bajo fatiga — el servicio equivocado reiniciado en el momento equivocado, el nombre de host equivocado escrito en un comando destructivo.

OpenRemedy es una plataforma de SRE autónoma que cierra esos incidentes bajo el control del operador. Ejecuta el paso de verificación que hoy hacen las personas, propone la solución que sabe que es segura, y ejecuta solo lo que el operador ha aprobado — directamente o de antemano a través de la escalera de confianza.

Esta no es una afirmación novedosa. Un análisis académico reciente de la plataforma Claude Code de Anthropic — un agente autónomo comparable en el dominio adyacente de la ingeniería de software — encontró que solo el 1,6 % del código era lógica de decisión de IA; el 98,4 % restante era infraestructura determinista: puertas de permisos, gestión de contexto, enrutado de herramientas, lógica de recuperación.^[1] Los modelos de frontera están convergiendo en capacidad. La superficie competitiva duradera es el sistema que decide qué mostrarle al modelo, qué puede tocar el modelo, y cómo recuperarse cuando el modelo se equivoca.

OpenRemedy se construye sobre esa tesis, aplicada a un dominio distinto y a un comprador distinto.

El ciclo del agente es simple. Reunir el contexto del incidente, llamar al modelo, despachar las herramientas que el modelo quiere invocar, comprobar si el operador autorizó esas herramientas para ejecutarse en este host, ejecutar las que se aprueban, recoger los resultados, repetir hasta que el modelo dice que ha terminado. Quizá doscientas líneas de código.

Lo que rodea al ciclo es la plataforma.

Cada casilla fuera de Triage y Diagnóstico es infraestructura determinista. El agente no decide si una receta es segura de ejecutar en este host; lo decide la plataforma. El agente no escribe en el registro de auditoría; lo hace la plataforma. El agente no asciende un servidor de simulación a en vivo; lo hace la plataforma, y solo después de que un operador haya pulsado aceptar sobre una sugerencia que la plataforma se ganó con resultados registrados.

Esto no es una restricción que aceptamos a regañadientes. Es el diseño.

La misma lógica gobierna lo que el modelo llega a ver. La plataforma construye el contexto del incidente a partir de hechos recopilados — la topología real del servidor, el servicio realmente vinculado al puerto que falla, la política que disparó la alerta — de modo que el modelo razona sobre información verificada en vez de sobre una descripción en texto libre que puede estar desactualizada. Decidir qué se pone delante del modelo es, en sí mismo, trabajo de andamiaje, no trabajo de modelo.

Los modelos de frontera seguirán mejorando, y quien compra una plataforma de operaciones autónomas — sobre todo en sectores regulados — no está comprando un modelo. Está comprando la superficie de control del operador, el rastro de auditoría, las puertas de seguridad, la capacidad de defender una solución ante un auditor. Nada de eso viene del modelo. Todo viene del andamiaje.

Cuando decidimos qué construir a continuación, nos preguntamos: ¿esto hace la plataforma más inteligente, o hace el andamiaje más digno de confianza? Preferimos lo segundo.

Cada decisión arquitectónica de OpenRemedy remite a uno de cinco valores. Los valores no son aspiraciones; son criterios de decisión. Cuando dos alternativas de diseño funcionan igual de bien técnicamente, elegimos la que puntúa más alto en los cinco.

Las personas son las dueñas de cada acción que importa. El agente propone; el operador decide. Esto es una regla dura, no un valor por defecto que se pueda relajar. La plataforma se niega a desplegar una configuración en la que un LLM pueda autoautorizar una remediación fuera de los límites que el operador ha fijado explícitamente.

La escalera de confianza (audit → shadow → live) es el mecanismo por el que los operadores conceden autonomía por etapas. Un servidor en modo audit nunca ve una propuesta de remediación. Un servidor en modo shadow ve cada propuesta detenerse a esperar aprobación humana, sin importar la puerta de confianza × riesgo que gobierna el modo live. El ascenso entre modos lo decide el operador, con un rastro de auditoría que registra quién decidió conceder autonomía, cuándo, y con qué evidencia.

Un límite de seguridad que depende de un único mecanismo no es defensa en profundidad — es defensa de nombre. La plataforma ejecuta cinco puertas de control independientes antes de cualquier remediación, cada una con un modo de fallo distinto.

Si dos de esas puertas dependieran del mismo servicio externo — por ejemplo, si todas necesitaran una llamada a un LLM para evaluar — no serían cinco puertas. Serían una sola puerta con cinco sombreros. Auditamos explícitamente en busca de modos de fallo compartidos y separamos las capas cuando coinciden. Este es el principio que Liu et al. señalan como el patrón de fallo más común en las plataformas de agentes: una defensa en profundidad que degenera en un único punto de fallo bajo carga.

Conceder a un agente la autoridad para actuar sobre infraestructura de producción no es una decisión binaria. Es un gradiente, y el trabajo de la plataforma es hacer ese gradiente legible.

Cada servidor de OpenRemedy vive en uno de tres modos.

En modo audit, el agente clasifica el incidente y lo resuelve de inmediato. No se propone ninguna remediación; nada se ejecuta; el operador obtiene visibilidad sin ningún compromiso.

En modo shadow, el agente ejecuta el pipeline completo de diagnóstico y propuesta, y cada propuesta espera la aprobación humana.

En modo live, la puerta de confianza × riesgo decide si una receta se ejecuta de forma autónoma.

Un servidor entra en modo audit y solo se gana el paso a live mediante aprobaciones del operador registradas — no mediante configuración, ni mediante una decisión puntual que el operador podría olvidar. La escalera de ascenso genera sugerencias cuando un par (servidor, receta) acumula al menos diez aprobaciones sin ningún rechazo en una ventana de 30 días. El operador acepta o descarta; la plataforma nunca se autopromociona.

Estar preparado para auditoría no es una función añadida al final de la construcción. Es una restricción que se aplica en cada capa.

Cada acción que cambia estado escribe una fila de auditoría etiquetada con el inquilino, el actor, la dirección IP y el cambio preciso. El registro de auditoría es de solo anexado. El razonamiento de cada incidente se puede reconstruir a partir de la línea de tiempo, no de un resumen opaco de un proveedor. La memoria — el corpus de resoluciones pasadas del que aprende el agente — se servirá como archivos markdown planos por inquilino, versionables y exportables a demanda. Los operadores son propietarios de sus datos.

Preferimos la auditabilidad sobre la potencia de consulta cuando entran en conflicto. Un auditor de cumplimiento quiere leer el rastro; un panel quiere filtrarlo. Gana el primero.

No estamos construyendo un agente generalista. Estamos construyendo un ejecutor de runbooks para flotas Linux.

Los agentes generalistas de código como Claude Code responden a la pregunta «¿qué haría aquí un ingeniero senior?» sobre una superficie amplia. OpenRemedy responde a una pregunta más estrecha: «dada una forma de incidente conocida en un tipo de servidor conocido, ¿cuál de las cinco soluciones conocidas aplica, y es seguro ejecutarla ahora mismo?».

La pregunta más estrecha nos permite ser más específicos en cada capa. Nuestro catálogo de recetas está curado, no sintetizado. Nuestros prompts de agente son específicos de dominio. Nuestra escalera de confianza es por receta y por servidor, no un dial global de autonomía. Nuestro clasificador de seguridad está en producción, ejecutando una llamada a un LLM independiente antes de cualquier ejecución automática; entrenar una versión por inquilino sobre el corpus de incidentes real de cada inquilino, en lugar de un modelo de propósito general, es lo que viene a continuación.

La superficie de producto con la que interactúa el operador — la forma visible de la plataforma — está gobernada por cuatro mecanismos superpuestos entre sí.

El control más grueso. Cada servidor está en modo audit, shadow o live. El modo determina qué etapas del pipeline del agente se ejecutan.

Los operadores nunca tienen que elegir entre «el agente tiene autonomía total» y «el agente no tiene ninguna». La escalera de confianza registra cada aprobación, cada rechazo, cada ejecución automática y cada fallo posterior a la ejecución para cada par (servidor, receta). Cuando un par acumula diez aprobaciones sin ningún rechazo en 30 días, la plataforma sugiere el ascenso.

Lo que hace «Aceptar» depende del modo actual del servidor. En un servidor shadow, aceptar lo pasa a live — el mecanismo histórico. En un servidor ya en live, aceptar concede una anulación de rol de receta por inquilino para la tupla (receta, rol de servidor): la próxima vez que el pipeline proponga esa receta en un servidor con ese rol, la puerta de confianza × riesgo se salta y se omite la etapa de validación. El operador puede revocar la anulación en cualquier momento desde la página de Agentes; la revocación reimpone la puerta de control.

La plataforma nunca se autopromociona. Los umbrales mínimos son 5 aprobaciones en 7 días; por debajo de eso, no se genera ninguna sugerencia. El camino de la anulación es igual de explícito por parte del operador — nunca se concede sin un clic en Aceptar, y un solo rechazo en la ventana descalifica al par. Juntos, esto evita un descuido de tipo «autoascenso a la primera aprobación», mientras deja que las recetas de confianza salgan de la cola de aprobación sin cambiar la postura de todo un servidor.

Independientemente del modo, cualquier ejecución pendiente puede marcarse como vista previa. Una ejecución de vista previa aplica la receta en modo simulación contra el host — informando de qué cambiaría sin aplicarlo — y termina en un estado dedicado de vista-previa-completada, distinto del estado de éxito.

Las ejecuciones de vista previa no hacen avanzar el incidente a revisión (no hay nada que revisar), no aparecen en las métricas que cuentan cambios aplicados, y ocultan el botón de reversión (no hay nada que revertir). El operador elige la vista previa en el momento de la aprobación, por ejecución.

Estos mecanismos se combinan. Un servidor en shadow puede ejecutar una vista previa de una propuesta antes de decidir si aprueba la ejecución real. Un servidor en live puede ejecutar una vista previa de una receta arriesgada antes de dejar que la puerta de confianza × riesgo ejecute la siguiente de forma automática. Un servidor en audit no mostrará ninguna ejecución en absoluto. Los planes de mantenimiento se superponen a los tres — un paso de plan se ejecuta bajo el mismo modo de servidor y la misma mecánica de vista previa que una ejecución impulsada por un incidente, de modo que un paso de reinicio escalonado en un servidor live se controla exactamente igual que cualquier otra remediación.

La respuesta a incidentes es reactiva. El mismo andamiaje también ejecuta cambios planificados. Un plan de mantenimiento es un documento markdown con cabecera YAML (riesgo, estrategia, dimensiones de snapshot) y una secuencia de pasos tipados — validate, custom_tool, recipe, wait, notify, human_gate. Cada paso declara si necesita aprobación; el mismo modelo de puerta de control que gobierna la remediación de incidentes gobierna también cada paso no trivial aquí.

Los planes se ejecutan bajo una estrategia: rolling (un servidor cada vez, fácil de abortar a mitad de la flota), parallel_batched (tamaño de lote fijo con periodo de reposo), rings (canary → piloto → amplio, con periodos de reposo por anillo). Al aprobarse, el markdown del plan se congela en la programación, de modo que las ediciones futuras a la plantilla del plan nunca afectan a una ejecución ya aprobada; las ediciones del operador a la propia programación se conservan a través de la aprobación. Un editor de IA permite al operador redactar y revisar el markdown de forma conversacional antes de aprobar, y una entrada de registro de auditoría registra cada cambio hecho por chat, de modo que la historia del cambio planificado queda tan inspeccionable como la de la respuesta a incidentes.

La escalera de confianza y la puerta de aprobación decide quién puede ejecutar qué. OpenRemedy Guardian decide algo más estrecho y más contundente: si la acción concreta que tiene delante la plataforma es del tipo que destruye datos o derriba un sistema — un disco borrado, una base de datos eliminada, un firewall vaciado, un reinicio forzado del host equivocado — sin importar cuán rutinaria pareciera la solicitud que lo rodea.

Guardian es un modelo dedicado que se ejecuta antes de la puerta de aprobación, como una señal de pre-triage independiente. Lee la operación que está por realizarse — el comando concreto, no solo la alerta que lo desencadenó —, reconoce la intención destructiva incluso cuando está disimulada, y le asigna una severidad. Esa severidad se incorpora al riesgo de la acción antes de que la puerta de control la vea: la plataforma toma el mayor entre el riesgo declarado en el catálogo y la lectura de Guardian. Una receta que parece rutinaria pero resulta ser destructiva se escala automáticamente a aprobación humana.

Guardian nunca relaja una decisión — solo puede elevar el riesgo, nunca bajarlo — y nunca ejecuta nada por sí mismo. Es un dominio de fallo separado del modelo que razona sobre el incidente y de la puerta que autoriza la ejecución, de modo que una acción destructiva tiene que pasar las tres barreras de forma independiente. Cuando Guardian no está disponible, cada inquilino elige la postura: continuar, con las puertas de control existentes en pie, o forzar la aprobación humana hasta que vuelva.

Cada lectura que hace Guardian queda registrada en la línea de tiempo del incidente, de modo que el operador puede ver de un vistazo que la plataforma examinó una acción y la consideró segura — o que dio la alarma y encaminó la acción hacia una persona.

OpenRemedy está en pruebas privadas. El fundador la usa contra su propia infraestructura de producción antes de abrir la plataforma a otros operadores. Todavía no hay clientes externos, por diseño.

Lo que ha producido ese uso interno, en el momento de escribir esto:

Los 76 incidentes que no avanzaron hasta la ejecución se clasificaron como transitorios o fueron artefactos de fallos de la plataforma que encontramos usándola nosotros mismos — la misma razón por la que lo hacemos, para encontrarlos antes que un cliente real. Las resoluciones más rápidas (casi instantáneas) fueron sobre todo reclasificaciones automatizadas; las más lentas (hasta unos seis minutos) fueron investigaciones que llamaron a varias herramientas de diagnóstico antes de decidir. Guardian, en producción desde junio, ha evaluado 69 decisiones en la etapa de ejecución hasta ahora — un registro pequeño pero real de la comprobación de riesgo previa a la puerta de control funcionando de verdad contra tráfico de producción, no solo contra pruebas de laboratorio.

Las cifras son pequeñas. Lo que importa en esta etapa es la forma del despliegue: un solo operador con veinte años de experiencia en producción con Linux, ejecutando la plataforma contra su propia infraestructura, encontrando fallos al usarla, y publicando una mejora cada vez que encuentra uno. La infraestructura ya es lo bastante madura como para que el operador no tenga que estar pendiente de ella; el modelo especializado por inquilino que viene a continuación le permitirá generalizar más allá de la intuición de un solo operador.

La plataforma actual cubre la cuña de cierre del ciclo para flotas Linux — alertas de entrada, clasificación, diagnóstico, remediación controlada y auditoría. La hoja de ruta se extiende en dos direcciones.

Profundidad. El clasificador de seguridad descrito en el §03 — una llamada a un LLM independiente con un prompt reforzado, situada entre la puerta de confianza × riesgo y el despacho al worker — ya está en producción. Su único trabajo es responder sí o no a la pregunta «¿es segura esta acción concreta en este host concreto ahora mismo?». Nunca puede relajar las puertas existentes; solo puede vetar. Lo que viene a continuación es entrenar una versión por inquilino sobre el propio corpus de incidentes resueltos del inquilino, en lugar de un modelo de propósito general, y colocarla en esa misma posición de clasificador.

Una memoria basada en archivos por inquilino — archivos markdown exportables y versionables en lugar de filas opacas de base de datos — sustituirá al corpus de resolución actual. Las transcripciones laterales capturarán el razonamiento completo de cada etapa del pipeline como JSONL, por separado de la vista resumida del panel.

Amplitud. La cuña actual es cerrar incidentes sobre infraestructura ya existente. La trayectoria es el ciclo de vida completo de la infraestructura de un operador bajo una única superficie agéntica — lo que pensamos como vibe deploy, junto al vibe coding que la industria ya tiene. Describe un proyecto; la plataforma elige la nube, aprovisiona, vigila, arregla lo que se rompe, y hace crecer un corpus de resolución por inquilino que el operador es dueño de. La cuña desbloquea el resto: en cuanto un operador confía en la plataforma para cerrar un incidente de primer nivel a las tres de la madrugada, confía en ella para desplegar el siguiente entorno, y el mismo ciclo agéntico gestiona ambos.

La idea es grande y el camino es largo. Sabemos a qué nos estamos comprometiendo.

Tres cosas que hemos aprendido construyendo esto.

El andamiaje es auditable; el modelo no lo es. Cuando un auditor de cumplimiento pregunta por qué se aplicó una solución, la respuesta no puede ser «el modelo lo decidió». La respuesta tiene que ser una cadena de decisiones de la plataforma — en qué modo estaba el servidor, qué nivel de confianza tenía el agente, qué nivel de riesgo llevaba la receta, quién aprobó, qué registró la plataforma — terminando con el razonamiento del modelo como una entrada más entre varias. El andamiaje es lo que produce un rastro de auditoría defendible.

Los modos de fallo independientes son la única defensa en profundidad real. Cinco puertas que dependen todas del mismo proveedor de LLM son una sola puerta. Cinco puertas que dependen de un modo de servidor (fijado por el operador), un riesgo de receta (curado en el catálogo), un nivel de confianza (por agente), un filtro de herramientas (fijo en el código) y una llamada a un clasificador aparte (un LLM independiente) fallan en condiciones distintas y le dan al operador un margen de seguridad real. Auditar la independencia desde el principio; corregirla antes de que el sistema crezca.

Los gradientes de confianza superan a los interruptores de confianza. Los operadores no quieren una casilla que diga «deja que la IA se encargue de las cosas». Quieren un camino desde la observación hasta la autonomía que puedan recorrer paso a paso, sobre el que puedan demostrar defensibilidad, y del que puedan volver atrás en cualquier momento. Construir la plataforma alrededor de ese camino es la diferencia entre algo que un operador va a ejecutar sobre infraestructura de producción y algo a lo que le da una demo de cinco minutos y no vuelve a tocar.

Nada de esto es exclusivo de OpenRemedy. Son las consecuencias de tomarse en serio las operaciones autónomas hasta el punto de ponerlas delante de un comprador con requisitos de cumplimiento. La tecnología es el modelo; el producto es el andamiaje.