---
title: El modelo como fallo bizantino correlacionado
description: "Un modelo de lenguaje no se detiene cuando falla: contesta algo arbitrario y plausible. La replicación clásica no lo cubre, porque el mismo modelo llamado dos veces se equivoca en el mismo sitio. Tres reglas de ALLAN son la misma respuesta a ese hecho."
allan.topic: foundation
allan.service: allan-server
allan.date: 08/04/2026
allan.fuente: [Platform Server/internal/agents/watchdog.go, Platform Server/internal/forge/repair.go, Platform Server/internal/forge/pipeline.go, Platform Server/internal/forge/validation_report.go, Platform Server/internal/agents/eval_engine.go, Platform Server/internal/agents/prompt_engine.go, Platform Server/internal/reviser/reviser.go, Platform Server/internal/reviser/tools.go, Platform Server/internal/models/context.go, Platform Server/internal/memory/extraction.go, Responses API/responses_api/cmem/judge.py, Responses API/responses_api/cmem/consensus.py, Responses API/responses_api/cmem/config.py]
allan.audiencia: [desarrollador]
allan.madurez: emergente
---

Un componente que se detiene es barato de tolerar. El sistema nota el silencio, lo saca del
quórum y sigue. Sobre ese supuesto —*fail-stop*— descansa casi toda la ingeniería de
fiabilidad que se practica a diario: reintentos, réplicas, sondas de salud, disyuntores.
Lamport, Shostak y Pease lo nombraron en 1982 precisamente para descartarlo cuando la
fiabilidad exigida es alta: «it is often assumed that a computer may fail to respond but will
never respond incorrectly. However, when extremely high reliability is required, such
assumptions cannot be made, and the full expense of a Byzantine Generals solution is
required».

Un modelo de lenguaje es exactamente el componente que obliga a pagar ese precio. No se cae:
contesta. Contesta con la misma fluidez, el mismo formato y la misma seguridad aparente
cuando acierta que cuando inventa un identificador, cuando clasifica mal una categoría o
cuando declara «hecho» un trabajo que no hizo. Y contesta cosas distintas a partes distintas
del sistema: el mismo modelo puede decirle al planificador que la herramienta existe y al
validador que no, sin que ninguna de las dos respuestas sea detectable como fallo desde el
sitio donde se recibe. El artículo de 1982 abre su introducción describiendo ese caso con una
precisión incómoda: «A failed component may exhibit a type of behavior that is often
overlooked—namely, sending conflicting information to different parts of the system».

La clasificación, por tanto, no es una metáfora: un modelo de lenguaje es, en sentido técnico,
un componente bizantino. La consecuencia es la que casi nunca se saca.

## Lo que el teorema pide, y lo que no

Conviene leer el artículo original antes de invocarlo, porque no dice lo que se le suele
atribuir. Lamport, Shostak y Pease **no** postulan que los fallos de las réplicas sean
estadísticamente independientes. Su modelo es adversarial, no probabilístico: los traidores
pueden coordinarse, mentir de forma consistente y elegir el peor comportamiento posible —«The
loyal generals will all do what the algorithm says they should, but the traitors may do
anything they wish»—. Donde sí razona con probabilidades es al construir la función de firma
del algoritmo SM(*m*), y allí distingue explícitamente el caso *Random Malfunction* del caso
*Malicious Intelligence*, que remite a criptografía. Un supuesto de independencia entre
procesadores defectuosos no aparece en ninguna de las páginas recuperadas.

Lo que el teorema exige es otra cosa, y es más dura: una **cota sobre cuántos componentes
pueden estar defectuosos**. «Using this result, we can show that no solution with fewer than
3m + 1 generals can cope with m traitors». Es una condición sobre la composición del conjunto,
no sobre la estadística de sus errores.

Ahí está el bien escaso, y ahí es donde se ha colado el supuesto que sí importa. La
independencia nunca fue un axioma del teorema: es la excusa con la que la ingeniería ha
justificado que la cota se cumple. Si tres implementaciones se desarrollan por separado —se
argumentaba—, la probabilidad de que dos fallen sobre la misma entrada es el producto de dos
probabilidades pequeñas, luego casi seguro que como mucho una está mal y la mayoría es
correcta. Ese argumento tiene nombre propio y tiene fecha de defunción. La
programación multiversión «depends for its reliability improvement on the assumption that
programs that have been developed independently will fail independently», y Knight y Leveson
lo sometieron a experimento en 1986: «In all, 27 versions of a program were prepared
independently from the same specification at two universities and then subjected to one
million tests». El resultado: «the programs were individually extremely reliable but […] the
number of tests in which more than one program failed was substantially more than expected».

En junio de 2026 el experimento se repitió sustituyendo a los estudiantes por agentes de
codificación, sobre la misma especificación de Knight y Leveson: «we evaluate 48
agent-generated implementations on a shared oracle and a campaign of 1,000,000 randomized test
inputs». El veredicto no admite lectura amable —«The results show substantial common-mode
failure, along the findings of Knight–Leveson»— y la introducción lo cuantifica: «the
idealized fault independence hypothesis fails: among the 48 admitted implementations in the
campaign archive, the experiment produces 429 coincident-failure cases where the random
independence model predicts only 115.36 (z = 29.20)». Los fallos coincidentes se concentran
donde la especificación es difícil o ambigua, no se reparten al azar.

Merece la pena decir qué no sostiene ese trabajo, porque este ensayo usa una sola de sus dos
mitades. Sus autores concluyen que la diversidad entre agentes sí compra fiabilidad práctica
pese a la correlación —el recuento medio de fallos baja de 387,44 a 130,99 con voto
por mayoría entre tríos— y cierran diciendo que sus resultados son «the strongest evidence to
date that N-Version Programming with coding agents is a useful engineering strategy». Lo
desmentido es la independencia, no la utilidad de replicar; y la distinción es la que importa
aquí, porque replicar mejora la media sin acotar el peor caso, y esa cota es lo que un teorema
bizantino necesita para funcionar.

Conviene enunciar con cuidado dónde se rompe la analogía, porque es fácil enunciarlo mal. El
problema no es que el teorema bizantino sea falso ni que no aplique: es que **su hipótesis dejó
de ser comprable**. Llamar N veces al mismo modelo no produce N componentes con fallos
acotados; produce N muestras de una misma distribución de error, y sobre esas N muestras nada
garantiza la cota `m ≤ (n−1)/3`.

## Cuánto vale realmente un voto

La afirmación anterior es medible, y desde 2025 está medida.

Sobre más de 350 modelos, dos *leaderboards* y una tarea de cribado de currículos, Kim, Garg,
Peng y Garg encuentran que «on one leaderboard dataset, models agree 60% of the time when both
models err». El matiz que destruye la salida fácil —usar proveedores distintos— está en la
frase siguiente: «larger and more accurate models have highly correlated errors, even with
distinct architectures and providers». La diversidad de proveedor no compra independencia; la
capacidad correlaciona los aciertos y, con ellos, los errores.

Cuando esa correlación se convierte en votos, el rendimiento del panel se puede cuantificar.
Un tribunal de nueve jueces de siete familias distintas, sobre tres conjuntos de inferencia
natural con cien anotaciones humanas por ítem, «effectively provide only about 2 independent
votes' worth of information», y el efecto sobre la exactitud no es cosmético: «the panel's
actual accuracy falls 8-22 percentage points short of what independent voting would achieve».
La conclusión es la que debería presidir cualquier plan de «añadamos más jueces»: «The
bottleneck is correlated judges, not the aggregation algorithm, implying that scaling up
panels cannot substitute for genuinely independent evaluation».

Queda la variante intramodelo, la que un motor de agentes practica sin darse cuenta cada vez
que reintenta: muestrear varias veces el mismo modelo y quedarse con la mayoría. También está
evaluada, y el resultado es negativo con una explicación mecánica: «aggregation
fails to provide a robust truth signal because language model errors are strongly correlated».
El mismo trabajo aporta la frase que conviene tener presente al diseñar cualquier juez: «under
uncertainty, models are better at predicting what other models will say within model ensembles
than at identifying what is true, revealing a separation between social prediction and truth
verification». Un panel de modelos no mide la verdad; mide el consenso esperado de los
modelos, que es otra magnitud. Y la correlación sobrevive incluso al intento de eliminarla por
construcción: «even when conditioned on out of distribution random strings and asked to produce
pseudo-random outputs, different models produce correlated outputs».

Más llamadas pueden incluso empeorar el resultado en términos
absolutos: «the performance of both Vote and Filter-Vote can first increase but then decrease
as a function of the number of LM calls», porque «more LM calls lead to higher performance on
"easy" queries, but lower performance on "hard" queries».

Sobre la pregunta concreta de si un LLM detecta los fallos de otro LLM hay un dato estructural
y dos duros. El estructural: un evaluador reconoce sus propias salidas con exactitud no trivial
y las puntúa por encima de lo que las puntúan los humanos —«an LLM evaluator scores its own
outputs higher than others' while human annotators consider them of equal quality»—, y esa
preferencia crece con la capacidad de autorreconocimiento («a linear correlation between
self-recognition capability and the strength of self-preference bias»). Los duros: sobre 148
trazas de agentes anotadas por humanos, «the best Gemini-2.5-pro model scoring a mere 11% on
TRAIL»; y en el estudio de modos de fallo multiagente, la taxonomía se construyó «through
rigorous analysis of 150 traces, guided closely by expert human annotators and validated by
high inter-annotator agreement (kappa = 0.88)». Sobre esa clase de trazas, los anotadores
humanos se ponen de acuerdo casi siempre sobre qué falló; el mejor modelo de contexto largo
localiza el fallo una de cada nueve veces.

Existe además una formalización del caso general que acota lo que cabe esperar de encadenar
verificadores. Modelando la tasa de falsa aceptación por instancia como variable latente, la
fiabilidad de una cascada de *k* puertas deja de caer exponencialmente y, si hay un punto ciego
compartido, deja de caer: «a blind-spot atom of mass 1−π at α=1 caps the evidence extractable
from any number of gates at −ln(1−π) nats, so reliability saturates below 1». El mismo trabajo
cifra el error de calcular con independencia —«independence-based extrapolation underestimates
failure by 20x at k=5 and ~3000x at k=10»— y nombra la palanca real: «The practical lever is
decorrelation -- changing model family, modality, or evidence source -- not adding gates».

De todo esto se sigue una regla de ingeniería, no una opinión: **la cota bizantina no se paga
con más llamadas al modelo**. Si la verificación tiene que ser fiable, la parte que decide debe
vivir fuera del componente bizantino.

## Tres reglas de ALLAN que son la misma regla

En el corpus de diseño de ALLAN esta conclusión no aparece enunciada como teorema. Se
descubrió tres veces, por caminos separados, y cada vez se escribió como una regla local.
Vistas juntas son el mismo movimiento: sacar la decisión del alcance del fallo y ponerla en un
artefacto que no puede ser bizantino —una cuenta aritmética, un tipo de datos, un reloj—.

**El juez estructural de la memoria colectiva.** La capa colectiva promueve un hecho sobre un
usuario cuando varios agentes lo han aprendido por separado. Para eso hay que decidir dos
cosas: si dos enunciados dicen lo mismo, y si esa coincidencia es evidencia. Lo primero exige
comprensión lectora, y el diseño descarta explícitamente resolverlo de otro modo: «Nunca
matching textual: dos agentes casi nunca guardan el mismo hecho con las mismas palabras»
(`docs/arquitectura/collective-memory-design.md:199-200`). Lo segundo no exige comprensión
ninguna, y el diseño lo saca del modelo con nombre propio: «**Corroboración verificable, no
intuición**» (íd. `:203`).

El corte está en el código. El prompt del juez termina con «No juzgues si un hecho es verdadero:
solo estructura» (`responses_api/cmem/judge.py:51`), y la cabecera del módulo declara qué queda
fuera: «The verifiable parts — distinct agents, distinct sessions, thresholds, recency — stay in
`consensus.py`, outside the model» (`judge.py:8-10`). Es literalmente cierto: quien cuenta los
agentes distintos y las sesiones distintas es `_corroboration` (`consensus.py:304-332`), un
bucle sobre episodios recuperados del almacén; y quien comprueba las cotas son dos
condicionales sin modelo, `len(corroboration.agents) < s.min_agents` y
`len(corroboration.sessions) < s.min_sessions` (`consensus.py:424-427`), con ambos umbrales
fijados en 2 (`config.py:35-36`). La exigencia de sesiones distintas, además de agentes
distintos, está puesta para que N proyecciones de una misma conversación no cuenten como
consenso.

**El reparador que no ve la puntuación.** Cuando la validación de un agente recién forjado
falla, la sesión ofrece una tercera respuesta además de descartar o ignorar el veredicto:
reparar. El riesgo evidente es que el reparador optimice contra el examinador en lugar de
contra el defecto, y el corpus prohíbe esa vía en una frase: «Un reparador que puede leer el
examen optimiza contra el examinador; uno que solo lee la queja tiene que arreglar el agente»
(`docs/agentes/agent-forge-design.md:270`). Lo interesante es cómo se hace cumplir. No hay
instrucción en el prompt: hay ausencia de campo. `BundleEditInstructions` tiene exactamente
cinco —nombre, propósito, idioma, correcciones y restricciones (`internal/forge/pipeline.go:111-124`)—
y su comentario declara la omisión como regla: «Deliberately narrow: it carries the fixes and
the context needed to apply them, and nothing about how the agent was scored»
(`pipeline.go:107-110`). La única construcción del valor en todo el flujo de reparación
(`repair.go:219-224`) rellena esos cinco campos y no hay ninguna otra.

El mismo enrutado saca de circulación una clase entera de hallazgos: los de gobernanza —nivel
de autonomía, política de aprobación, riesgo aceptable— no se envían a ningún reparador porque
«un bucle que las "arreglara" estaría anulando en silencio a quien trabaja para él» (íd.
`:269`). En el código eso es `Repairable()` devolviendo falso para `TargetGovernance`
(`internal/forge/validation_report.go:88-91`), y el comentario del tipo explica por qué esos
valores salen de una tabla fija: «precisely so a model does not get to choose them»
(íd. `:82-84`).

**El vigilante que no puede vigilarse.** El motor supervisa esperas largas con arrendamientos
renovables: cuando un *lease* vence, un watchdog decide si renovar, corregir el rumbo, cancelar
la operación o escalar a una persona (`internal/agents/watchdog.go:18-22`). El watchdog es un
modelo. La pregunta obvia es quién lo vigila a él, y la respuesta del diseño es que nadie, a
propósito: el evaluador usa «un timeout no-renovable — el propio evaluador NO usa lease, para no
arriesgar recursión infinita "quién vigila al vigilante"»
(`docs/arquitectura/intelligent-wait-supervision-design.md:478-479`). En el código es
`watchdogEvalTimeout = 15 * time.Second`, con un comentario que enuncia la razón: «a watchdog
that could get stuck waiting on its own judgment call would defeat the point»
(`watchdog.go:28-34`).

La segunda mitad de la regla importa tanto como la primera. Si el veredicto no se puede obtener
—error del modelo, expiración, JSON ilegible, acción inválida— el resultado no es «no sé», es
`RENEW` (`watchdog.go:106-114`, más el parser que rechaza toda acción fuera de las cuatro,
`:236-262`). La recursión se corta con un valor por defecto
estructural, y el valor se elige por asimetría de coste: en un *lease* lo caro es matar una
operación viva, así que el fallo del evaluador renueva; cuando lo que se agotó es el presupuesto
declarado de un run, lo caro es seguir gastando, y el mismo fallo devuelve `INTERVENE`
(`watchdog.go:202`, `:225`, `:230`). Ninguna de las dos ramas consulta a un segundo modelo.

Las tres reglas dicen lo mismo con materiales distintos: la corroboración se protege con
aritmética; la reparación, con la forma de un `struct`; la supervisión, con un reloj y un valor
por defecto. Ninguna intenta comprar independencia entre modelos, porque no está a la venta.

## Invariantes, enunciados para que se puedan romper

Un hecho colectivo nunca se promueve con evidencia de un solo agente ni de una sola sesión, y
esa comprobación no pasa por ningún modelo: se cuenta sobre episodios recuperados del almacén
(`consensus.py:424-427`). Un clúster con menos de `min_agents` agentes distintos ni siquiera
llega al juez, porque la puerta previa lo descarta antes de gastar la llamada
(`consensus.py:240`).

Un reparador automático nunca recibe una puntuación, un umbral, una rúbrica ni la transcripción
de un juez. La garantía no es de comportamiento sino de tipo: no existe campo donde ponerlos
(`pipeline.go:111-124`). Corolario falsable: si alguien añade un campo `Score` a
`BundleEditInstructions`, el invariante desaparece aunque el prompt siga diciendo lo mismo.

Los hallazgos de gobernanza no se reparan nunca, y las restricciones que acompañan a una cirugía
prohíben explícitamente debilitar un eval —«Do not weaken an eval's criteria. The evals are how
this agent is measured; making the measurement easier is not a fix» (`repair.go:336`)—. Los
intentos están acotados a dos (`repair.go:55`) y cada intento se compara con el anterior por
huella SHA-256 calculada sobre `(check, path, field, source, título, fix)`
(`validation_report.go:148-161`), estable frente a la reescritura de la prosa, de modo que «no
converge» es un estado observable y no una impresión.

El evaluador del watchdog no corre bajo *lease* y su fallo nunca cancela una operación viva.
Corolario falsable: cualquier cambio que envuelva `Watchdog.evaluateWithModel` en `runWithLease`
reintroduce la recursión que el diseño excluye.

Y dos garantías que la plataforma **no** da, porque es donde un lector supondría lo contrario:
nada obliga a que el supervisor y el supervisado sean modelos distintos, y «dos agentes
distintos» no significa «dos modelos distintos».

## Lo que está roto, sin terminar o sin evidencia

ALLAN aplica bien la regla en los tres sitios donde la descubrió, y la incumple donde más caro
sale.

**Examinador y reparador comparten clave de configuración.** En el pipeline de Forge, el
diseñador de evals, el generador de escenarios, el juez de rúbrica, el equipo rojo y el guardián
resuelven todos contra `models.RoleReasoning` (`internal/agents/eval_engine.go:501`, `:518`,
`:543`, `:560`, `:579`); los artefactos del agente se generan con el mismo rol
(`internal/agents/prompt_engine.go:64-71`); y el cirujano que repara lo que el juez suspendió
llama a `GenerateWithTools(ctx, models.RoleReasoning, …)` (`internal/reviser/tools.go:116`). Peor
que eso: la validación (`pipeline.go:508`), la reparación (`repair.go:169`) y el cirujano
(`reviser/tools.go:114`, `reviser/reviser.go:115`) se etiquetan los tres con el mismo consumidor,
`models.ConsumerForge` = `"engine.forge"`, y el comentario del tipo explica que el reviser no
tiene consumidor propio a propósito (`internal/models/context.go:107-110`). Como la asignación
por consumidor de la página «Modelos y proveedores» anula el rol cuando fija un modelo
(`prompt_engine.go:67-70`), la consecuencia es estructural y no probabilística: **no existe
ninguna configuración de la plataforma que permita que el juez y el reparador sean modelos
distintos**. La guarda anti-Goodhart —no ver el marcador— sigue siendo válida y sigue siendo
útil: impide optimizar *contra* el examinador. Lo que no compra, y el corpus no afirma que
compre, es independencia de puntos ciegos: un defecto que el juez no ve es un defecto que el
reparador tampoco verá, y el techo de la cascada de verificadores aplica en su forma más pura.

**«Dos agentes distintos» no son dos modelos distintos.** La corroboración de la memoria
colectiva cuenta identidades de agente, y esa cuenta es honesta respecto de lo que dice contar.
Pero los hechos que compara no los escribió cada agente con su propio modelo: el extractor de
memoria es una sola llamada `models.RoleFast` (`internal/memory/extraction.go:112`, comentario
en `:14`) etiquetada con `models.ConsumerMemory` (`:109`), y ese consumidor es una única clave de
asignación para toda la plataforma (`internal/models/context.go:52-59`). El usuario puede elegir
modelo por agente para la conversación (`WithModelOverride`, `context.go:14-20`), pero el paso
que decide *qué hecho se guarda* corre siempre en el mismo modelo. Lo que la puerta de ≥2
agentes y ≥2 sesiones decorrelaciona es la **entrada**: dos conversaciones distintas, con dos
personas de agente distintas. Lo que no decorrelaciona es el extractor. Un sesgo sistemático del
extractor —leer una cortesía como preferencia declarada, por ejemplo— se reproduce en las dos
particiones y llega a la aritmética disfrazado de consenso. El invariante correcto, enunciado
para que se pueda refutar, es este: la corroboración de CMEM protege contra el ruido de muestreo
de una conversación, no contra un sesgo sistemático del extractor.

**El juez «solo estructural» tiene poder generativo.** La descripción es exacta en cuanto a lo
que el juez no hace —no decide si un hecho es verdad, no cuenta agentes, no cuenta sesiones— e
incompleta en cuanto a lo que sí hace. El juez elige la **partición**: `members =
[cluster.facts[m] for m in group.members]` (`consensus.py:257`), y la corroboración se cuenta
sobre esos miembros. Un juez que agrupe mal dos hechos no equivalentes procedentes de dos
agentes fabrica una corroboración que la aritmética posterior valida sin objeción. Y el enunciado
que acaba inyectándose en las conversaciones lo redacta el propio modelo: el prompt le pide
«redacta el enunciado canónico en español» (`judge.py:35`). El daño está acotado por dos puertas
previas —solo entran clústeres con similitud ≥ 0,80 (`config.py:41`) y ≥ 2 agentes
(`consensus.py:240`)— y por la lista blanca de categorías (`config.py:52`), pero acotado no es
nulo. «Corroboración verificable, no intuición» describe la mitad numérica del algoritmo, no el
algoritmo entero. A favor de CMEM juega un detalle de despliegue que el diseño no previó: el
juez no usa el `RoleFast` del motor que el documento anuncia
(`collective-memory-design.md:198`), sino su propio extremo configurable
—`CMEM_LLM_BASE_URL`/`CMEM_LLM_MODEL`, exigidos en el constructor (`judge.py:178-182`,
`config.py:94-96`)—, de modo que aquí sí es posible poner una familia de modelo distinta de la
del extractor. Que nadie lo haya exigido en ningún sitio es otra cuestión.

**Del watchdog escalonado solo existe el peldaño barato.** El diseño describe una escalera de
coste con heurísticas deterministas primero: detección de bucle por hash de `(tool, args)` en
ventana deslizante, y delta de estado entre vencimientos
(`intelligent-wait-supervision-design.md:197-204`). Ninguna de las dos se construyó, y la nota de
alcance lo reconoce como decisión, no como olvido: «no se construyó un detector de bucles por
hash `(tool,args)` cruzando todo el run […] no hay liveness-tracking basado en tokens» (íd.
`:501-507`). Lo que queda es un contador de renovaciones libres (`defaultMaxFreeRenewals = 2`,
`watchdog.go:39`), que es un presupuesto, no una heurística: no observa nada del run. Es decir,
la única parte no bizantina de la escalera —la que decidiría por evidencia estructural en lugar
de por juicio— es justamente la que no existe. Además `ESCALATE` «por ahora produce un run
fallido con mensaje claro, no una pausa real» (íd. `:508-510`), y los veredictos «solo se logean
vía `debugf`» (íd. `:510-511`), de modo que no hay traza consultable con la que auditar si el
vigilante acierta.

Hay un consuelo parcial y conviene registrarlo: el watchdog sí está configurado para poder ser
otro modelo. Corre con `models.RoleFast` bajo `models.ConsumerWatchdog`
(`watchdog.go:104`, `:221`; `context.go:104`), una clave de asignación que ninguna otra llamada
del motor comparte, mientras que los pasos que supervisa —raíz y worker— usan
`models.RoleReasoning` (`swarm_loop_v3.go:961`, `:1618`, `:1874`). La decorrelación que Han
nombra como única palanca real —cambiar de familia de modelo— es aquí *posible*; en Forge es
imposible. Nadie la ha exigido en ningún sitio.

También conviene registrar el caso conocido en que el vigilante falló de forma bizantina, porque
está fechado en el propio código: un run que acababa de paginar 100 de 204 registros de un CRM
fue cortado con el argumento «with only 2 steps used ... the task may require many more steps»,
leyendo un presupuesto declarado pequeño como «el agente apenas ha empezado»
(`watchdog.go:122-128`). La corrección consistió en darle contadores medidos en lugar de una cola
de transcripción (`BudgetCheckpoint`, `:129-136`) y en trasladar la asimetría de coste al propio
prompt: «a wrong RENEW costs one more checkpoint while a wrong INTERVENE discards work already
paid for» (`:216`). Vale la pena ver lo que eso significa: parte de la asimetría que antes vivía
en un valor por defecto estructural vive ahora en una instrucción que el modelo puede ignorar.
Es un retroceso pequeño respecto de la doctrina, hecho por buenas razones, y no está anotado como
tal en ningún sitio.

**No hay medición propia.** Todo lo cuantitativo de este ensayo procede de la literatura. En el
repositorio no consta ninguna medición de correlación de errores entre llamadas de ALLAN a su
propio modelo, ni de acuerdo entre el juez de validación y una anotación humana, ni de tasa de
falsos `RENEW` del watchdog. El diseño de la memoria colectiva anota la pregunta correcta como
riesgo declarado —«Consenso ≠ verdad» (`collective-memory-design.md:394`)— y le asigna como
mitigación exigir sesiones distintas además de agentes distintos, que es precisamente la
mitigación cuyo alcance queda acotado más arriba. Sin instrumentación, la afirmación de que las
tres reglas funcionan descansa en el argumento estructural: sólido sobre lo que impide, mudo
sobre lo que ocurre.

La síntesis cabe en dos frases. Un modelo de lenguaje es un componente bizantino, y la cota de
componentes defectuosos que el teorema exige no se compra replicando el modelo, porque los
errores del mismo modelo —y los de modelos distintos de capacidad parecida— están
correlacionados de forma medida y sustancial. Lo único que sí se puede comprar es un componente
que no sea bizantino en el punto donde se decide: una cuenta, un tipo, un reloj. ALLAN lo hizo
tres veces sin saber que hacía lo mismo, y en Forge todavía no lo ha hecho.

## Referencias

- **Lamport, L.; Shostak, R.; Pease, M. (1982).** *The Byzantine Generals Problem*. ACM
  Transactions on Programming Languages and Systems 4(3):382-401.
  <https://lamport.azurewebsites.net/pubs/byz.pdf> — PDF recuperado y leído directamente
  (páginas 382-385 y 398-401).
  «A failed component may exhibit a type of behavior that is often overlooked—namely, sending
  conflicting information to different parts of the system.» (p. 382).
  «The loyal generals will all do what the algorithm says they should, but the traitors may do
  anything they wish.» (p. 383).
  «Using this result, we can show that no solution with fewer than 3m + 1 generals can cope with
  m traitors.» (p. 385).
  «Achieving reliability in the face of arbitrary malfunctioning is a difficult problem, and its
  solution seems to be inherently expensive. The only way to reduce the cost is to make
  assumptions about the type of failure that may occur. For example, it is often assumed that a
  computer may fail to respond but will never respond incorrectly. However, when extremely high
  reliability is required, such assumptions cannot be made, and the full expense of a Byzantine
  Generals solution is required.» (p. 401).
  *Nota de lectura*: en las páginas recuperadas **no** aparece ningún supuesto de independencia
  estadística entre réplicas. El modelo del artículo es adversarial y lo que exige es una cota
  sobre el número de componentes defectuosos («we can only guarantee that these algorithms will
  work in the presence of up to m failures, be they processor or communication line failures»,
  p. 398). El razonamiento probabilístico que sí contiene es sobre la falsificación de firmas, y
  distingue «Random Malfunction» de «Malicious Intelligence» (p. 400). Atribuir a este artículo
  un «supuesto de independencia» es incorrecto: ese supuesto pertenece a la programación
  multiversión, y el encargo que originó este ensayo lo daba por sentado. Cambiar esa premisa es
  la corrección de fondo del texto.

- **Knight, J. C.; Leveson, N. G. (1986).** *An Experimental Evaluation of the Assumption of
  Independence in Multiversion Programming*. IEEE Transactions on Software Engineering
  12(1):96-109.
  «This method depends for its reliability improvement on the assumption that programs that have
  been developed independently will fail independently.»
  «In all, 27 versions of a program were prepared independently from the same specification at
  two universities and then subjected to one million tests.»
  «The results of the tests revealed that the programs were individually extremely reliable but
  that the number of tests in which more than one program failed was substantially more than
  expected.»
  **PARCIALMENTE VERIFICADA.** El artículo está tras el muro de pago de IEEE Xplore y no se ha
  podido recuperar. Las tres frases proceden de una reproducción literal del resumen incluida en
  un documento de seminario de KTH
  (<https://www.csc.kth.se/utbildning/kth/kurser/DA2210/vettig13/Seminarier/KnightLeveson.pdf>),
  recuperado y leído en esta sesión. **No se ha leído el cuerpo del artículo**, de modo que
  ninguna afirmación de este ensayo depende de nada que no esté en su resumen.

- **Ron, J.; Baudry, B.; Monperrus, M. (2026).** *N-Version Programming with Coding Agents*.
  arXiv:2606.20158v1, 18 jun. 2026. <https://arxiv.org/abs/2606.20158> — PDF recuperado y leída
  la página 1 (resumen e introducción).
  «Using the Knight–Leveson's, Launch Interceptor Program Specification, we evaluate 48
  agent-generated implementations on a shared oracle and a campaign of 1,000,000 randomized test
  inputs. The results show substantial common-mode failure, along the findings of
  Knight–Leveson.» (resumen).
  «First, the idealized fault independence hypothesis fails: among the 48 admitted
  implementations in the campaign archive, the experiment produces 429 coincident-failure cases
  where the random independence model predicts only 115.36 (z = 29.20), and strong pairwise
  clusters can be observed across both language and agent boundaries.» (introducción).
  «across majority voting three-version units, the mean failure count drops from 387.44 for
  single versions to 130.99 for triples, and 11,844 N-version units exhibit zero observed
  failures. Our original results is [*sic*] the strongest evidence to date that N-Version
  Programming with coding agents is a useful engineering strategy.» (resumen).
  *Advertencia de uso*: este ensayo emplea solo la mitad negativa de un trabajo cuya conclusión
  general es positiva. Lo que el artículo desmiente es la independencia, no la utilidad de la
  replicación. *Corrección de esta revisión:* una versión anterior transcribía «Our original
  results **are**»; el resumen del preprint dice «is», con la concordancia rota, y se cita tal
  cual.

- **Kim, E.; Garg, A.; Peng, K.; Garg, N. (2025).** *Correlated Errors in Large Language Models*.
  arXiv:2506.07962, 9 jun. 2025. <https://arxiv.org/abs/2506.07962> — resumen recuperado íntegro.
  «We find substantial correlation in model errors -- on one leaderboard dataset, models agree
  60% of the time when both models err.»
  «Crucially, however, larger and more accurate models have highly correlated errors, even with
  distinct architectures and providers.»

- **Kohli, G. (2026).** *Nine Judges, Two Effective Votes: Correlated Errors Undermine LLM
  Evaluation Panels*. arXiv:2605.29800, 28 may. 2026. <https://arxiv.org/abs/2605.29800> —
  resumen recuperado íntegro.
  «we find that the 9 judges effectively provide only about 2 independent votes' worth of
  information.»
  «the panel's actual accuracy falls 8-22 percentage points short of what independent voting
  would achieve, and the best single judge matches or outperforms the full panel across all
  conditions.»
  «The bottleneck is correlated judges, not the aggregation algorithm, implying that scaling up
  panels cannot substitute for genuinely independent evaluation.»

- **Denisov-Blanch, Y.; Kazdan, J.; Chudnovsky, J.; Schaeffer, R.; Guan, S.; Adeshina, S.;
  Koyejo, S. (2026).** *Consensus is Not Verification: Why Crowd Wisdom Strategies Fail for LLM
  Truthfulness*. arXiv:2603.06612, 20 feb. 2026. <https://arxiv.org/abs/2603.06612> — resumen
  recuperado íntegro y verbatim.
  «Across models and benchmarks, aggregation fails to provide a robust truth signal because
  language model errors are strongly correlated.»
  «We find that under uncertainty, models are better at predicting what other models will say
  within model ensembles than at identifying what is true, revealing a separation between social
  prediction and truth verification.»
  «The source of correlation goes beyond any individual benchmark: we show that even when
  conditioned on out of distribution random strings and asked to produce pseudo-random outputs,
  different models produce correlated outputs.»

- **Chen, L.; Davis, J. Q.; Hanin, B.; Bailis, P.; Stoica, I.; Zaharia, M.; Zou, J. (2024).**
  *Are More LLM Calls All You Need? Towards Scaling Laws of Compound Inference Systems*.
  arXiv:2403.02419, mar. 2024 (rev. jun. 2024; NeurIPS 2024).
  <https://arxiv.org/abs/2403.02419> — resumen recuperado íntegro y verbatim.
  «We find, surprisingly, that across multiple language tasks, the performance of both Vote and
  Filter-Vote can first increase but then decrease as a function of the number of LM calls.»
  «more LM calls lead to higher performance on "easy" queries, but lower performance on "hard"
  queries, and non-monotone behavior can emerge when a task contains both types of queries.»

- **Panickssery, A.; Bowman, S. R.; Feng, S. (2024).** *LLM Evaluators Recognize and Favor Their
  Own Generations*. arXiv:2404.13076, 15 abr. 2024. <https://arxiv.org/abs/2404.13076> — resumen
  recuperado íntegro.
  «One such bias is self-preference, where an LLM evaluator scores its own outputs higher than
  others' while human annotators consider them of equal quality.»
  «By fine-tuning LLMs, we discover a linear correlation between self-recognition capability and
  the strength of self-preference bias.»

- **Deshpande, D.; Gangal, V.; Mehta, H.; Krishnan, J.; Kannappan, A.; Qian, R. (2025).** *TRAIL:
  Trace Reasoning and Agentic Issue Localization*. arXiv:2505.08638, 13 may. 2025 (rev. 23 jun.
  2025). <https://arxiv.org/abs/2505.08638> — resumen recuperado íntegro.
  «we […] present a set of 148 large human-annotated traces (TRAIL) constructed using this
  taxonomy and grounded in established agentic benchmarks.»
  «Our evaluations reveal that modern long context LLMs perform poorly at trace debugging, with
  the best Gemini-2.5-pro model scoring a mere 11% on TRAIL.»

- **Cemri, M.; Pan, M. Z.; Yang, S.; Agrawal, L. A.; Chopra, B.; Tiwari, R.; Keutzer, K.;
  Parameswaran, A.; Klein, D.; Ramchandran, K.; Zaharia, M.; Gonzalez, J. E.; Stoica, I. (2025).**
  *Why Do Multi-Agent LLM Systems Fail?* arXiv:2503.13657, 17 mar. 2025 (rev. 26 oct. 2025).
  <https://arxiv.org/abs/2503.13657> — resumen recuperado íntegro.
  «We develop MAST through rigorous analysis of 150 traces, guided closely by expert human
  annotators and validated by high inter-annotator agreement (kappa = 0.88).»
  «This process identifies 14 unique modes, clustered into 3 categories: (i) system design
  issues, (ii) inter-agent misalignment, and (iii) task verification.»

- **Han, J. (2026).** *Partially Correlated Verifier Cascades in LLM Harnesses: Concave Log-Odds,
  Polynomial Reliability, and Blind-Spot Ceilings*. arXiv:2607.13918, 15 jul. 2026.
  <https://arxiv.org/abs/2607.13918> — resumen recuperado íntegro.
  «a blind-spot atom of mass 1−π at α=1 caps the evidence extractable from any number of gates at
  −ln(1−π) nats, so reliability saturates below 1.»
  «In synthetic tests, independence-based extrapolation underestimates failure by 20x at k=5 and
  ~3000x at k=10; the correlated fit at R=8 tracks held-out depths.»
  «The practical lever is decorrelation -- changing model family, modality, or evidence source --
  not adding gates.»

- **Huang, J.; Chen, X.; Mishra, S.; Zheng, H. S.; Yu, A. W.; Song, X.; Zhou, D. (2023).** *Large
  Language Models Cannot Self-Correct Reasoning Yet*. arXiv:2310.01798, 3 oct. 2023 (rev. 14 mar.
  2024; ICLR 2024). <https://arxiv.org/abs/2310.01798> — resumen recuperado íntegro.
  «In the context of reasoning, our research indicates that LLMs struggle to self-correct their
  responses without external feedback, and at times, their performance even degrades after
  self-correction.»