La evolución tardó casi cuatro mil millones de años en producir una especie capaz de leer su propio ADN. Y solo unas décadas más en que esa especie aprendiera a editarlo. Algo parecido —pero comprimido en meses, no en eones— es lo que el Anthropic Institute acaba de poner sobre la mesa: sus modelos ya escriben la mayor parte del código con el que se construyen los siguientes modelos. La serpiente no se muerde la cola. Se la está rediseñando.

Lo que Anthropic ha contado (y por qué importa)

El Anthropic Institute ha publicado un ensayo titulado When AI builds itself (firmado por M. Favaro y J. Clark) sobre algo que en el sector llevamos años tratando como ciencia ficción educada: la auto-mejora recursiva, o RSI por sus siglas en inglés (recursive self-improvement). La idea de que una IA participe en el diseño y entrenamiento de su sucesora, y que cada generación acelere a la siguiente.

Lo interesante no es la especulación. Especulación tenemos de sobra. Lo interesante es que esta vez vienen con datos de su propia cocina:

• Más del 80% de las líneas de código que se integran en los repositorios de Anthropic las escribe Claude, no un humano.
• Cada ingeniero integra 8 veces más código al día que en 2024.
• La optimización de experimentos de entrenamiento pasó de un speedup de 3× hace un año a 52× con sus modelos internos más recientes.
• En tareas abiertas, mal definidas —las difíciles de verdad— el éxito pasó del 26% al 76% en seis meses.

Y a esto se suma evidencia externa: según METR, el horizonte temporal de las tareas que un modelo puede completar de forma autónoma se duplica cada cuatro meses. Hace dos años hablábamos de tareas de minutos. Hoy, de jornadas enteras.

El ensayo es claro en una cosa: el bucle todavía no está cerrado. Ningún modelo ha diseñado y entrenado a su sucesor de forma autónoma. Pero el tramo previo —que la IA escriba, ejecute y depure la maquinaria con la que se fabrica la siguiente IA— ya no es hipótesis. Es telemetría.

El cuerpo que remodela su propio esqueleto

Para entender qué está pasando, me sirve una metáfora de biomecánica: el hueso.

El esqueleto parece la parte más estática del cuerpo, pero es tejido vivo en remodelación constante. Hay células que destruyen hueso viejo (osteoclastos) y células que construyen hueso nuevo (osteoblastos). Cada vez que corres, saltas o levantas peso, el esqueleto se reconstruye para soportar mejor la carga que le pides. El cuerpo se reedifica a sí mismo, en silencio, mientras lo usas.

Los laboratorios de IA están llegando a algo análogo. El modelo ya no es solo el producto: es parte del equipo de obra. Claude escribe el código de la infraestructura donde se entrenará el siguiente Claude. Optimiza los experimentos que deciden cómo será. Revisa los fallos del sistema que lo sirve. El esqueleto se remodela con cada zancada.

Y aquí viene el matiz que el propio ensayo subraya, y que me parece la clave de todo: ese proceso tiene dos planos muy distintos.

El plano de la ejecución: escribir el código, lanzar el experimento, producir el resultado. Esto, según Anthropic, está esencialmente resuelto. El coste humano de hacer tiende a cero.

El plano del criterio: decidir qué experimento merece la pena, qué problema atacar, cuándo un resultado prometedor es en realidad un espejismo. Eso que los investigadores llaman taste. Ahí los humanos seguimos ganando. De momento.

Es la diferencia entre el músculo y el sistema nervioso central. El músculo ejecuta, y los modelos ya tienen una musculatura sobrehumana. Pero la decisión de hacia dónde correr todavía sale de un cerebro humano. La pregunta incómoda del ensayo es: ¿por cuánto tiempo? Sus propios datos sugieren que esa brecha también se estrecha —y sus autores admiten, con una honestidad poco habitual, que no saben si el criterio investigador es un techo real o simplemente «otra capacidad más» que caerá como han caído las demás.

Ahora, la lectura crítica (porque aquí elegimos la pastilla roja)

Este blog no se llama «Elegir la Pastilla Azul», así que toca mirar el truco de magia desde detrás del escenario.

Primero: el emisor es juez y parte. Anthropic vende el agente que produce la aceleración que Anthropic mide. La tesis «la IA acelera la IA» es, casualmente, la mejor campaña de marketing posible para quien comercializa esa IA. Esto no invalida los datos, pero obliga a descontar el envoltorio narrativo.

Segundo: buena parte de las métricas son auto-referenciales. El 76% de éxito en tareas abiertas lo determina… un juez que también es Claude. Las líneas de código son telemetría interna que nadie externo puede auditar. Y el propio documento admite que medir líneas de código sobreestima la ganancia real de productividad. Hay que agradecer que lo digan, pero conviene no olvidarlo al citar el 8×.

Tercero: el dato más espectacular es el más débil. El ensayo cuenta que, en ciertos momentos de bloqueo, el modelo elige mejor que el humano el «siguiente paso» de una investigación (64% de las veces con su modelo más reciente). Suena a jaque mate. Pero esos momentos fueron seleccionados precisamente porque el humano tenía margen de mejora. En el grupo de control, donde el humano ya iba bien encaminado, el modelo solo aporta mejora un ~20% de las veces. El titular vive en la letra pequeña.

Y cuarto: la investigación de punta a punta todavía no transfiere. En su experimento más ambicioso, agentes trabajando 800 horas recuperaron el 97% de la brecha de rendimiento en un problema de entrenamiento, por unos 18.000 dólares —donde un equipo humano había recuperado el 23% en una semana. Impresionante. Pero el resultado no funcionó al trasladarlo a escala de producción, y fue un humano quien eligió el problema y definió cómo medir el éxito. La serpiente edita genes, sí, pero todavía no decide qué organismo quiere ser.

Los tres futuros (y cuál me quita el sueño)

El ensayo dibuja tres escenarios, como tres ramas de un árbol filogenético:

1. La curva se aplana. Las exponenciales resultan ser curvas-S, como casi todo en la naturaleza. El criterio investigador no emerge de escalar cómputo y hace falta una idea nueva. Aun así, las capacidades actuales se difunden por toda la economía y el mundo cambia bastante. Anthropic lo incluye casi por cortesía: no se lo cree.
2. Ganancias compuestas con humano al timón. El desarrollo se automatiza masivamente pero las personas siguen fijando dirección y juzgando resultados. Es la apuesta central del laboratorio. Aquí aparece un viejo conocido de la ingeniería, la ley de Amdahl: acelera una parte del sistema y el cuello de botella simplemente se muda a otra. En Anthropic ya pasó: generar código es tan barato que el límite ahora es revisarlo. El humano como cuello de botella de su propia creación.
3. El bucle se cierra. Los sistemas diseñan y entrenan a sus sucesores y el ritmo lo marca el cómputo disponible. El humano queda en el rol de supervisor de un laboratorio virtual que trabaja a una velocidad que no puede seguir. Es el escenario distópico de manual: no porque las máquinas se rebelen, sino porque nadie —ni sus creadores— tiene ya visibilidad real de lo que ocurre dentro del bucle.

Mi lectura honesta: el escenario 2 es el terreno donde ya estamos pisando, y el 3 dejó de ser un cuento de campamento. Lo que me inquieta no es la versión Hollywood. Es algo más sutil y más biológico: en la naturaleza, cuando un proceso de selección empieza a retroalimentarse —selección sexual desbocada, carreras armamentísticas evolutivas— los resultados son rápidos, extraños e irreversibles. La cola del pavo real no la diseñó nadie. Emergió del bucle.

¿Y a los demás, qué nos toca?

Tres ideas para llevarse a casa, aunque uno no entrene modelos frontera:

El cuello de botella se muda a la verificación. Si la generación de código (de textos, de análisis, de lo que sea) tiende a coste cero, el valor escasea en quien sabe revisar, validar y juzgar. Inviertan en criterio. Es el órgano que más tarda en atrofiarse, pero también el que menos se ejercita cuando todo lo hace la máquina.

Desconfía de los múltiplos, quédate con la dirección. El 8×, el 52×, el 76%: cifras internas, no auditables, medidas por el propio interesado. Pero la dirección del vector está corroborada por benchmarks externos como METR o SWE-bench. La señal es real aunque el volumen esté exagerado.

El acceso al bucle se concentra. Si la RSI compone, compone en función del cómputo. Y el cómputo está en manos de un puñado de laboratorios. Esa concentración —quién tiene acceso a la maquinaria que se mejora a sí misma y quién no— me parece la cuestión política de la década, mucho más urgente que cualquier debate sobre robots conscientes.

La serpiente ya tiene el editor genético en la mano. Todavía le pedimos permiso… bueno, todavía nos pide permiso para cada edición. La pregunta que deja el ensayo de Anthropic, flotando entre líneas con admirable franqueza, es qué pasa el día que deje de necesitarlo.

Ese día, ojalá, seguiremos aquí para contarlo. Con la pastilla roja bien tragada.

Fuentes

• When AI builds itself — Anthropic Institute (M. Favaro, J. Clark)
• METR — Measuring AI Ability to Complete Long Tasks
• SWE-bench

El sistema musculoesquelético del cuerpo humano funciona porque hay un esqueleto debajo. Sin él, los músculos tirarían en direcciones contradictorias y el conjunto colapsaría sobre sí mismo. Los stacks modernos de datos e IA tienen exactamente ese problema: muchos músculos —Pydantic, JSON Schema, SQL, GraphQL, RDF— tirando sin hueso debajo. LinkML propone ese hueso.

El problema de fondo: cuatro versiones del mismo dato

Si has trabajado en cualquier arquitectura medianamente seria en los últimos años, esto te va a sonar. Tienes una entidad —pongamos Cliente— y termina viviendo en cuatro sitios distintos:

• Una clase Pydantic en el backend para validar entrada.
• Un JSON Schema en la documentación de tu API y en las definiciones de tools MCP.
• Un SQL DDL en la base de datos.
• Y, si tienes mala suerte, un vocabulario semántico (RDF, OWL, JSON-LD) para algún consorcio o cliente que exige interoperabilidad.

Las cuatro versiones empiezan iguales y, al sexto mes, han divergido. Alguien renombró un campo en Pydantic y olvidó actualizar el DDL. La tool MCP devuelve un JSON que el agente downstream no sabe parsear porque el esquema está desactualizado. Es entropía pura: el sistema tiende al desorden si no inviertes energía constante en mantenerlo alineado.

Es como un cuerpo cuyos huesos crecen a ritmos distintos. Acaba siendo inviable.

¿Qué es LinkML, en una frase?

LinkML (Linked data Modeling Language) es un lenguaje declarativo basado en YAML donde defines tu modelo una sola vez y se compila a más de 30 formatos: Pydantic, JSON Schema, SQL DDL, GraphQL, Protocol Buffers, TypeScript, Java, Rust, OWL, SHACL, JSON-LD, Mermaid diagrams, docs HTML… la lista no termina ahí.

Es el esqueleto compartido. Los músculos siguen siendo los mismos —cada lenguaje, cada base de datos, cada API— pero ahora cuelgan de algo coherente.

De dónde viene esto (y por qué importa)

LinkML no nace ayer en una startup con demo en Y Combinator. Viene del Lawrence Berkeley National Laboratory y de la Monarch Initiative, una red de proyectos biomédicos federados que llevan años obsesionados con un problema muy concreto: hacer que cien laboratorios distintos publiquen datos que se puedan combinar sin que cada combinación cueste un mes de trabajo humano.

Pero —y esto es lo interesante— ha trascendido su origen biomédico. Hoy lo usan:

• ENTSO-E (la red eléctrica europea).
• NFDI (la infraestructura nacional de investigación de Alemania).
• NIH Bridge2AI, iSamples, Alliance of Genome Resources y un largo etcétera.

Y la publicación de referencia —Moxon et al., «LinkML: an open data modeling framework»— acaba de salir en GigaScience 2026. No es un proyecto en hibernación: el último commit es de hace 24 horas.

Licencia Apache-2.0 en el core, CC0 en el metamodelo. Todo comercialmente usable sin fricciones. Por si te lo estás preguntando.

Cómo funciona: una sola fuente de verdad

Escribes algo así (YAML, legible incluso para un product manager con buena voluntad):

classes:
  Cliente:
    description: Una persona o entidad que compra
    slots:
      - id
      - nombre
      - email
      - sector

slots:
  id:
    identifier: true
    range: string
  email:
    range: string
    pattern: "^\\S+@\\S+\\.\\S+$"
  sector:
    range: SectorEnum

enums:
  SectorEnum:
    permissible_values:
      energia:
      sanidad:
      industria:

Y desde ese YAML generas, con un comando, las versiones equivalentes en cada formato que necesites. Cambias un campo en el YAML, recompilas, y todas las versiones quedan sincronizadas. Una verdad, muchas máscaras.

La pieza que cambia el juego para los que trabajamos con LLM: OntoGPT

Aquí es donde para mí esto se pone interesante de verdad.

OntoGPT —de Monarch Initiative, BSD-3, 809 estrellas en GitHub— implementa un método llamado SPIRES (Structured Prompt Interrogation and Recursive Extraction of Semantics). El truco es elegante: usas tu esquema LinkML como contrato de extracción. Le das al LLM un texto libre y le pides que extraiga información estructurada conforme a ese esquema. La salida se valida automáticamente contra el contrato. Si el modelo alucina un campo que no existe, se descarta.

Y lo mejor: soporta modelos abiertos vía ollama (Qwen, Llama, Mistral). Es decir, todo el pipeline puede correr on-premise, dentro de tu propio DGX Spark o el hardware que tengas, sin tocar APIs externas. Si te preocupa la soberanía sobre tus datos —y a mí cada día me preocupa más—, esto es relevante.

Es básicamente lo que muchos equipos están reimplementando a mano con Pydantic + Instructor + parsers ad-hoc de LangChain. Solo que aquí, además, el esquema es portable: lo pueden consumir también tu API, tu base de datos y tu pipeline de docs.

Dónde encaja en una arquitectura agéntica moderna

Pensemos en un stack típico hoy: LangGraph orquestando agentes, MCP tools para acciones externas, RAG para contexto, modelos on-premise para inferencia, y un par de APIs downstream con su Pydantic.

Cada uno de esos componentes habla de las mismas entidades —clientes, documentos, eventos— pero cada uno tiene su propia representación. Y cada cambio se propaga como un dolor distribuido por todo el sistema.

LinkML te permite tener un único contrato canónico que se compila a:

• Pydantic para los agentes y el estado de LangGraph.
• JSON Schema para las definiciones de tools MCP.
• SQL DDL para la persistencia.
• JSON-LD u OWL si en algún momento expones los datos como linked data (o si un cliente del sector público te lo exige por compliance).

El cuerpo deja de pelearse consigo mismo.

El ángulo distópico: la otra cara

Voy a ser honesto con la parte oscura, porque siempre la hay.

Imagínate un futuro donde todo está descrito por un esquema formal. Cada interacción humana, cada decisión, cada concepto. Suena a sueño racionalista —y de hecho lo es— pero también suena a control absoluto. Si quien define el esqueleto eres tú, organizas el cuerpo. Si lo define un consorcio cerrado, lo organiza para sus intereses. La interoperabilidad puede ser libertad o puede ser captura, dependiendo de quién sostenga el bolígrafo.

LinkML, por ser abierto, Apache-2.0 y con adopción europea, está hoy en el lado luminoso. Pero la herramienta es neutral. Lo que se haga con ella, no. Conviene tenerlo presente cuando pensamos en estándares de datos para la próxima década.

Cuándo usarlo y cuándo no

No es una bala de plata. Mi heurística práctica:

Usa LinkML cuando se cumplen una o varias de estas condiciones:

• Tienes tres o más consumidores del mismo modelo (API, BD, agentes, otra app).
• Hay requisitos explícitos de FAIR, gobernanza o interoperabilidad.
• El proyecto tiene horizonte largo (≥18 meses).
• Compartes el modelo con un consorcio externo o un cliente que exige semántica formal.

Quédate con Pydantic directo cuando:

• El modelo es interno, vive en un único servicio y nadie más lo consume.
• El proyecto es corto y no va a evolucionar mucho.
• Tu equipo no tiene apetito por aprender una herramienta nueva ahora mismo.

LinkML brilla en proyectos con múltiples bocas comiendo del mismo plato. Para una cuchara y un plato, sigue siendo overkill.

Riesgos honestos

Para no quedarme en el modo «venta»:

• Sesgo biomédico del ecosistema: las plantillas y ejemplos están dominados por dominios biológicos. Generalizar a industrial o empresarial requiere validación propia.
• Curva de aprendizaje semántica: conceptos como IRI, JSON-LD context o SHACL pueden intimidar. La buena noticia es que se pueden ignorar hasta que hagan falta. La mala es que la documentación tira a vocabulario ontológico.
• Bus factor moderado: el proyecto vive principalmente en LBNL/Monarch. No es Apache Foundation. Conviene tener un fork interno espejado.
• OntoGPT con modelos abiertos: SPIRES está validado contra GPT-3/4. Su rendimiento sobre Qwen o Mistral on-premise hay que medirlo. Suposición razonable: funciona, pero requiere tuning de prompts.

Mi recomendación práctica

Si me preguntas qué haría en los próximos dos meses con esto, mi respuesta tiene tres pasos pequeños y baratos:

1. Spike de 1–2 sprints: coger un pipeline interno que ya tiene Pydantic + JSON Schema + SQLAlchemy duplicados y reescribir esa fuente común en LinkML. Medir fricción real.
2. Piloto OntoGPT + Qwen on-premise: probar el patrón SPIRES sobre un dominio no biomédico, con extracción estructurada no trivial. Comparar contra una baseline manual.
3. Documentar un criterio de uso interno de una página. «¿Cuándo LinkML, cuándo Pydantic?» — para que el equipo no tenga que reinventar el juicio cada vez.

Si los dos primeros pasos salen bien, LinkML deja de ser una curiosidad académica y se convierte en pieza arquitectónica transversal. Si salen regular, hemos perdido seis semanas y hemos aprendido algo. Coste asimétrico, riesgo controlado.

Cierre

Llevo unos años pensando en lo mismo: que los datos en las organizaciones tienen un problema de esqueleto, no de músculo. Compramos herramientas (músculos) constantemente, pero seguimos sin tener un hueso común que las sostenga. Cada decisión de arquitectura repite la misma tarea cognitiva: «¿cómo represento esta entidad?», «¿en qué formato?», «¿con qué validación?».

LinkML no es la única respuesta posible, pero es de las más serias que he visto. Y, sobre todo, es de las pocas que viene del mundo de la investigación abierta, con licencia permisiva y adopción institucional europea. Eso, en el momento en que estamos —con cada vez más presión por la soberanía de datos—, no es un detalle menor.

Si tu organización está construyendo agentes, extracción estructurada con LLM o data platforms que tienen que hablar con otros sistemas, vale la pena un spike. Como mínimo, vas a salir con un mapa mental nuevo sobre cómo separar la definición del dato de sus muchas representaciones.

Y eso, por sí solo, ya cambia bastantes cosas.

Fuentes

• linkml.io — sitio del proyecto
• github.com/linkml/linkml — repositorio core
• monarch-initiative/ontogpt — OntoGPT
• Moxon SAT et al., LinkML: an open data modeling framework, GigaScience 2026;15:giaf152 · DOI: 10.1093/gigascience/giaf152
• Caufield JH et al., SPIRES: Structured Prompt Interrogation and Recursive Extraction of Semantics, Bioinformatics 2024, btae104

Una lectura larga sobre cómo la IA generativa está reescribiendo, literalmente, qué entendemos por gestión del conocimiento en una empresa. Spoiler: ya no es un repositorio, es un organismo.

// 00TL;DR

Si solo tienes dos minutos, quédate con esto. Si tienes veinticinco, baja conmigo a la raíz del sistema.

// 01Panorama del mercado de KMS

1.1 Cuatro generaciones, un mismo bicho

El Knowledge Management System es uno de esos conceptos que se reinventa cada década sin morirse del todo. Cuatro generaciones reconocibles, donde cada nueva no sustituyó a la anterior —igual que una nueva especie no extingue a sus ancestros, los desplaza al sotobosque—. Lo que importa es entender qué capa domina la conversación estratégica en cada momento. Y ahora mismo, sin duda, es la cuarta.

La cuarta generación no es una mejora incremental, es una mutación: cambia la unidad atómica del KMS (del documento a la respuesta), el modelo de interacción (de la búsqueda a la conversación, y de ahí al agente) y la arquitectura de gobierno (de las ACL estáticas al permission-aware retrieval en tiempo real). Es como pasar de un herbario disecado a un jardín que responde cuando lo riegas.

1.2 Tamaño y crecimiento: una niebla con dirección

Los analistas no se ponen de acuerdo porque cada uno dibuja la frontera del mercado por donde le conviene. Aun así, las cifras de 2025 dan una idea de la magnitud:

El dato que sí merece subrayado: el segmento de chatbots inteligentes y virtual agents crece al 21,88 % CAGR (Mordor), mucho más rápido que document management. El despliegue cloud copa el 62,18 %. La selva se reorganiza rápido.

Y otro dato de Menlo Ventures: el gasto en infraestructura GenAI alcanzó 18 B USD en 2025 (×2 vs. 2024). Dentro de las apps horizontales, los copilots dominan: «Copilots dominate with 86 % share ($7.2 billion)». Las plataformas de agentes capturan otros 750 M (Salesforce Agentforce, Writer, Glean).

1.3 Gartner y Forrester: el momento en que los analistas se enteran

• Gartner declara que no publica un único Magic Quadrant para KM porque «no hay características comunes suficientes para que exista un solo mercado». KM aparece embebido en cuatro mercados adyacentes, y en nov 2025 lanza el Emerging Market Quadrant for Generative AI Knowledge Management Apps, donde Glean fue nombrado Emerging Leader.
• Forrester publicó por primera vez The Forrester Wave: Knowledge Management Solutions, Q4 2024 el 2 dic 2024 — la primera Wave KM dedicada de la historia. Leaders: Atlassian y KMS Lighthouse. Strong Performers: USU y SearchUnify.
  Verbatim · Forrester, ene 2025

  «Knowledge management is changing before our eyes. The past decade has seen little advancement in knowledge management (KM) solutions, practices, or standards… With the introduction of generative and conversational AI, knowledge management is returning.»

1.4 Taxonomía actual (2026)

Cinco capas conviven, no se excluyen, y se solapan cada vez más: KMS tradicional (Confluence, SharePoint, Notion), Enterprise/Cognitive Search (Glean, Coveo, Elastic), AI-native Knowledge Platforms (Glean, Sana, Hebbia, Dust, Writer), Copilots embebidos (M365 Copilot, Google Gemini, Atlassian Rovo) e Infraestructura RAG/Vector/KG (Pinecone, Weaviate, Databricks Vector Search, Azure AI Search, Neo4j).

1.5 Consolidación: cuando los grandes empiezan a engullir

• ServiceNow → Moveworks (mar 2025, 2,85 B USD): la jugada más cara hasta la fecha en KM/enterprise search.
• Databricks → Neon (may 2025, ~1 B) y Snowflake → Crunchy Data (jun 2025, ~250 M): Postgres serverless para cargas agénticas.
• Hebbia → FlashDocs (jun 2025): cerrar el «last mile» de generación de artefactos.
• Accenture → Keepler (2025): boutique data/AI española absorbida por Big 4.

La batalla por el knowledge worker se gana en el control plane (gobierno, identidad, agentes, datos), no en la UI de la wiki. Quien se queda con el sistema nervioso central, se queda con el cuerpo entero.

// 02El impacto de la IA generativa en los KMS

2.1 De buscar, a preguntar, a actuar

El State of AI in 2025 de McKinsey (n=1.993) dice: «88 % of organizations use AI in at least one business function, up from 78 % last year.» Por primera vez, knowledge management aparece como una de las funciones con mayor uso reportado de AI. Pero solo el 5,5 % de las empresas atribuyen >5 % de su EBIT al AI. La brecha es de rediseño de workflows, no de tecnología. Comprar la herramienta sin replantear cómo trabajas equivale a meter un pulmón nuevo en un cuerpo que sigue respirando por la nariz que tenía: no notas la diferencia.

El cambio es triple: de documentos a respuestas (la unidad consumida deja de ser el PDF y pasa a ser un párrafo sintetizado con citas), de búsqueda a conversación a agente (el usuario formula intenciones; los agentes pueden ejecutar) y de estático a vivo (el conocimiento se construye en tiempo real desde Slack, meetings transcritos, CRM, código, tickets). Es la diferencia entre un fósil y un ser vivo.

2.2 Arquitecturas emergentes de retrieval

RAG baseline (2023): query → embedding → vector search → top-K → LLM. Hybrid + Reranking (2024): añade BM25 keyword y cross-encoder reranker. GraphRAG (Microsoft Research, feb 2024, open-source jul 2024): construye un grafo de conocimiento desde texto y permite razonamiento jerárquico vía community summaries. Indexado costoso (hasta 33K USD para datasets grandes); LazyGraphRAG (nov 2024) reduce coste 10–90 % difiriendo summaries al query time.

Agentic RAG (Singh et al., ene 2025): supervisor agent + sub-agentes (SQL, doc, KG) + reflective retry + synthesizer con audit trail. VentureBeat VB Pulse Q1 2026: la adopción de hybrid retrieval pasa de 10,3 % a 33,3 % en un trimestre.

Context Engineering / Knowledge Fabric (2026): capa semántica continua que une datos estructurados + no estructurados + workflows + conversaciones. «El cuello de botella ya no es el modelo, es el contexto.»

2.3 Los retos críticos

• Alucinaciones y trazabilidad: la respuesta debe venir con citaciones al chunk fuente. Quien no cite, miente con seguridad.
• Permission-aware retrieval: el RAG ingenuo destruye los permisos heredados. Microsoft tuvo que sacar SAM, Purview DLP for Copilot, DSPM y consolidarlo en el Copilot Control System. La vuln «Echoleak» (principios 2025) demostró exfiltración silenciosa vía Copilot. Si das de comer todo a un agente, también le das tus secretos.
• Knowledge decay: la documentación caduca. Los KMS modernos incorporan content pruning automatizado (18–26 % anual). Igual que un bosque sano necesita su ciclo de hojarasca, una base de conocimiento sana necesita morir un poco cada año.
• Coste: GraphRAG indexing hasta 33K USD; el consumption pricing en Glean Protect Plus genera «CFO conversations» en renovación.
• EU AI Act: mayoría en limited risk (transparencia). Si influye en decisiones de empleo/crédito/servicios públicos, escala a high-risk. El Omnibus de 7 may 2026 postpuso el deadline Annex III al 2 dic 2027. GPAI ya en vigor desde ago 2025.

2.4 Knowledge Fabric: el tejido conectivo del organismo

Tres frames convergen: Data Fabric (Talend, Informatica, Atlan), Knowledge Graph + LLM (Neo4j, Stardog, Ontotext) y Knowledge Fabric (Teradata, Glean Enterprise Graph, Atlassian Teamwork Graph). Es lo que da contexto a los agentes.

2.5 Copilots embebidos: ¿comoditización o nueva complejidad?

M365 Copilot Business a 21 USD/user/mes para SMB <300 empleados desde dic 2025 vuelve commodity el search corporativo dentro del estuario M365. Pero genera nueva complejidad: sobre-permisado, proliferación de copilots (Sales, Service, Finance, Agent Builder, Copilot Studio) y Shadow AI: Harmonic Security identificó 665 herramientas GenAI distintas en empresas tras analizar 22,4 M de prompts; solo el 37 % de orgs tiene políticas formales (IBM 2025). Microsoft responde con Agent 365 (GA 2026).

2.6 Métricas y ROI

La mayoría de orgs todavía mide vanity metrics. Los high performers redefinen el work design alrededor del AI. Eso es lo que correlaciona con EBIT real.

// 03El futuro de los KMS en distintos contextos

3.1 Grandes corporaciones

Escala y heterogeneidad (múltiples ERPs, suites, M&A acumulado → silos crónicos). Coexistencia con plataformas de datos: Databricks (Mosaic AI, Agent Bricks, Lakebase, Unity Catalog) y Snowflake (Cortex AISQL, Cortex Search, Snowflake Intelligence) se convierten en knowledge backbone, no solo data backbone. Multi-jurisdicción y compliance (GDPR + AI Act + DORA, NIS2, MDR, HIPAA). Riesgo de proliferación de copilots: ya hay orgs con 5–10 copilots no coordinados.

3.2 Pymes

Acceso a capacidades enterprise vía SaaS plug-and-play: Notion AI (10 USD/user), M365 Copilot Business (21 USD/user SMB), Guru AI, Glean for SMB. Barreras: datos no estructurados y desordenados, ausencia de «knowledge manager», recursos para curación limitados. Oportunidad de knowledge concierge: consultora externa como guardián del knowledge.

3.3 Organizaciones planas, startups, orgs ágiles

El KMS tradicional ha tenido siempre baja adopción aquí: las wikis se llenan, se abandonan y se relanzan. Mucho del know-how vive en Slack, calls y Loom recordings. Los AI notetakers son la nueva infraestructura: Granola cerró el 25 mar 2026 una Series C de 125 M USD liderada por Danny Rimer (Index Ventures) y Mamoon Hamid (Kleiner Perkins), elevando la valoración a 1,5 B USD — sixfold increase en menos de un año. Embeddings de Slack/Teams/Discord (Glean, Coveo, Dust, Sana) convierten la conversación pasada en knowledge searchable.

3.4 Predicciones cruzadas a 3–5 años

1. Search como interfaz primaria desaparece en favor de chat conversacional y agentes proactivos.
2. Convergencia KMS + Agent platform + iPaaS: los KMS dejan de ser repositorios y se vuelven plataformas de orquestación.
3. Agent-readable knowledge: documentos diseñados para ser consumidos por LLMs (estructurados, citables, versionados con embeddings de calidad).
4. Roles nuevos: Knowledge Architect, Context Engineer, Agent Operator, Prompt Engineer. El Knowledge Manager clásico se transforma en «knowledge operations».
5. Anti-tendencia: resurgimiento del knowledge engineering humano. Cuanto mejor el agente, más valor tienen las bases curadas a mano y los knowledge graphs construidos por humanos expertos. Hebbia ya contrata ex-bankers y ex-lawyers como forward-deployed engineers.
6. Bifurcación del documento: artefactos legales/regulatorios siguen doc-centric con firma y versión; «conversaciones congeladas» reemplazan a los wikis blandos.

// 04Posicionamiento estratégico

// 05Conclusiones

Los KMS están entrando en su cuarta generación y, por primera vez en la historia del sector, el cambio no es incremental sino arquitectónico: la IA generativa convierte el documento en respuesta, el repositorio en knowledge fabric vivo, y al knowledge worker en «agent boss». La consecuencia comercial es una disputa por el control plane entre tres bandos: hyperscalers de productividad (Microsoft, Google, Atlassian), AI-native challengers (Glean, Sana, Dust, Hebbia, Writer) y data platforms (Databricks, Snowflake, ServiceNow).

Y por debajo de todo eso, una pregunta que me lleva ya unos meses dándome vueltas: cuando el sistema nervioso de la empresa pase a ser una capa de agentes que sintetizan, recuerdan y deciden por nosotros, ¿qué le pasa al músculo cognitivo de las personas que trabajan ahí dentro? Igual que un astronauta pierde masa ósea en gravedad cero, un knowledge worker rodeado de respuestas pre-sintetizadas puede perder pensamiento estructurado en pocos años. No es ciencia ficción; es la versión laboral del mismo principio biomecánico.

// 06Open questions y caveats

• ¿Microsoft Agent 365 + CCS se vuelve el de facto control plane, expulsando a Glean del enterprise? Indicador: ARR de Glean en los próximos 4 trimestres.
• ¿GraphRAG vs. Agentic RAG vs. long-context puro se estabilizan o seguimos en churn arquitectónico? Una decisión tomada hoy puede caducar en 18 meses.
• ¿La UE adopta más Omnibus AI Act y se relaja la presión de compliance? Si sí, el viento de cola compliance se debilita.
• ¿Pricing dominante en 2027 — seat, consumption u outcome-based? Crítico para diseñar contratos.
• ¿Se materializa el anti-trend del knowledge engineering humano? Si sí, abre una línea de servicio premium (knowledge curators-as-a-service).
• ¿Qué pasa con los datos de meetings transcritos en la UE? Otter, Granola, Fireflies abren un frente de «ambient surveillance» que los reguladores no han abordado. Aquí la distopía empieza a oler a real.

Caveats: el sizing varía hasta 10× entre analistas; las cifras del Forrester Wave KM Q4 2024 están confirmadas para Atlassian (Leader), KMS Lighthouse (Leader, «Top 3»), USU y SearchUnify (Strong Performers). Las predicciones a 3–5 años son inherentemente especulativas. Las menciones a roadmap producto (Agent 365 GA 2026, etc.) deben revalidarse trimestralmente.

Las grandes corporaciones se parecen mucho a esos árboles centenarios que ves en mitad de un bosque: imponentes, con raíces profundas… y con una capacidad de adaptación limitada cuando el clima cambia de golpe. Y el clima de los datos ha cambiado de golpe. En este post repasamos qué son las plataformas de datos modernas, por qué la transición hacia ellas es ya una cuestión de supervivencia, y qué papel juegan piezas como Databricks o los servicios de datos de Microsoft Azure (Azure Data Factory, por ejemplo).

¿Qué entendemos por plataforma de datos moderna?

Una plataforma de datos moderna está diseñada para digerir el volumen brutal de datos que genera cualquier negocio hoy. Si el dato es el alimento, la plataforma es el aparato digestivo completo: ingesta, procesa, almacena y convierte todo eso en energía útil (insights). Sus características clave:

• Escalabilidad: capacidad de crecer con el volumen de datos sin que el rendimiento se resienta.
• Flexibilidad: soporte para tipos de datos diversos e integración con múltiples fuentes.
• Analítica avanzada: herramientas de machine learning, inteligencia artificial y analítica en tiempo real.
• Seguridad: medidas robustas para proteger datos sensibles y cumplir con la regulación.

Databricks: un ejemplo de referencia

Databricks es una plataforma unificada de analítica de datos que ha ganado una tracción enorme entre grandes corporaciones. Combina la potencia de Apache Spark con un espacio de trabajo colaborativo donde ingenieros de datos, científicos de datos y analistas de negocio trabajan sobre el mismo terreno. Sus puntos fuertes:

• Analítica unificada: ingeniería de datos, ciencia de datos y analítica de negocio en una sola plataforma.
• Escalabilidad: recursos de cómputo que crecen o se reducen según la demanda.
• Colaboración: workspaces y notebooks compartidos para desarrollar y analizar en equipo.
• Machine learning: soporte integrado para flujos de ML y despliegue de modelos.

La transición: cómo cambiar de esqueleto sin dejar de caminar

Migrar a una plataforma de datos moderna en una gran corporación es como una metamorfosis: el organismo tiene que seguir funcionando mientras se transforma por dentro. No puedes parar el negocio para cambiar la columna vertebral. Por eso la transición exige planificación quirúrgica.

Evaluación y planificación

Antes de mover una sola pieza, toca radiografía completa:

• Evaluar las fuentes de datos y soluciones de almacenamiento existentes.
• Identificar los requisitos y objetivos clave del negocio.
• Desarrollar un plan de transición con hitos y plazos claros.

Migración de datos

La fase más delicada: trasladar los datos desde los sistemas legacy a la nueva plataforma garantizando su integridad y minimizando el tiempo de parada. Consideraciones clave:

• Elegir las herramientas y técnicas de migración adecuadas.
• Asegurar la calidad y consistencia de los datos durante todo el proceso.
• Implementar medidas sólidas de gobierno del dato y seguridad.

Adopción y formación

Una plataforma nueva sin personas que sepan usarla es un músculo sin nervio que lo active. La adopción requiere:

• Formación y recursos para ingenieros, científicos de datos y analistas.
• Fomentar una cultura de decisiones basadas en datos.
• Soporte continuo y acompañamiento tras el despliegue.

Caso práctico: los servicios de datos de Microsoft Azure

Microsoft Azure ofrece un conjunto de servicios que ejemplifican bien lo que puede dar de sí una plataforma moderna. Azure Data Factory, por ejemplo, es un servicio de integración de datos en la nube que permite crear, programar y orquestar flujos de datos. Sus características principales:

• Integración de datos: conexión fluida con fuentes diversas, tanto on-premise como cloud.
• Escalabilidad: capacidad para procesar y transformar datos a gran escala.
• Automatización: flujos de datos automatizados y programados para una gestión eficiente.
• Seguridad: funciones completas de protección de datos sensibles.

Conclusión

La transición a plataformas de datos modernas ya no es opcional para las grandes corporaciones: es el equivalente evolutivo de adaptarse o quedarse como fósil de museo. Plataformas como Databricks o los servicios de datos de Azure ofrecen soluciones robustas para integrar, procesar y analizar datos. Con una transición bien planificada, datos íntegros y equipos formados, una organización puede desbloquear todo el potencial de su información. Y en un futuro donde quien controla el dato controla el ecosistema, llegar tarde a esta mudanza puede salir muy caro.

A finales de febrero de 2026 hice algo trivial: un script que cogía cuatro WAVs de lofi, los empalmaba con un crossfade de pydub y los exportaba a MP4 con una onda de fondo. El primer commit del repositorio se llama, literalmente, yup. No tenía agentes, no tenía catálogo, no tenía nada. Era una sesión de estudio para mí.

Pero el experimento dejó dos cosas claras y muy desagradables.

La primera: encadenar dos canciones bien no es una macro. Si pegas dos pistas en compases distintos, con tonalidades incompatibles o con BPM dispares, no obtienes "una mezcla". Obtienes un choque. Un crossfade lineal aplicado a dos señales a 0 dBFS suma +6 dBFS — fuera de rango — y produce distorsión digital. Sin un pre-mix gain de −3 dB y monitoreo de pico, el archivo final clipa.

La segunda: las decisiones musicales no caben en un prompt único. "Hazme una sesión de techno oscuro" parece una instrucción atómica, pero por dentro son cinco preguntas distintas: ¿qué tracks del catálogo encajan?, ¿en qué orden harmónico?, ¿hay un arco de energía o todo plano?, ¿qué transiciones van a sonar mal?, ¿está limpia la mezcla final? Un LLM general responde a las cinco a la vez y a ninguna en serio. Suena plausible y musicalmente es plano.

De ese picor — quiero mezclas que no choquen, y no me las hace un solo agente — sale todo lo demás.

v0.x: el primer pipeline (marzo)

El 15 y 16 de marzo aparecen dos commits que cambian la forma del proyecto: Initial public release — deep session generator y Add smart session generation with unified track catalog. La idea era simple pero ya no trivial: separar los WAVs por carpeta de género, calcular BPM con librosa y tonalidad en notación Camelot una sola vez por archivo, y guardarlo todo en un tracks.json que sirviera de fuente única de verdad.

A partir de ese catálogo, una función de selección clusteriza por tempo y hace un random walk harmónico sobre la rueda Camelot. Lo elegante de la rueda Camelot — desarrollada por Mark Davis en 2004 — es que reduce toda la teoría de armonía a un grafo de vecinos:

def _camelot_neighbors(key: str) -> set[str]:
    num = int(key[:-1])
    letter = key[-1].upper()
    opposite = "B" if letter == "A" else "A"
    return {
        key,
        f"{(num % 12) + 1}{letter}",       # +1 horario
        f"{((num - 2) % 12) + 1}{letter}", # -1 antihorario
        f"{num}{opposite}",                 # llave paralela
    }

Dos tracks son compatibles si están al mismo número, a una posición horaria o en su paralela mayor/menor. Eso es todo. El ordenador hace en milisegundos lo que un DJ humano resuelve por intuición acumulada.

Con eso ya tenía sesiones que sonaban "bien" — pero la decisión de qué tracks proponer, en qué orden y para qué mood seguía siendo monolítica. La cosa pedía romperse.

v1.0: el panteón empieza a hablar (abril)

El 7 de abril nace ApolloAgents propiamente dicho. Con el lanzamiento llegan cuatro decisiones que aún sostienen todo el proyecto.

Decisión 1 — agentes con rol acotado, no un super-LLM. La sesión se descompone en un pipeline de 8 fases, cada una a cargo de un agente con un system prompt específico, una lista cerrada de tools y un formato de salida estructurado. Cada uno lleva nombre mitológico. No por capricho estético — porque obliga a pensar en su rol antes que en su implementación:

Apollo no es un nombre decorativo: es el director del coro. Como en el panteón griego, cada deidad tiene un trozo del mundo. Janus mira en dos direcciones — la del usuario y la del catálogo — antes de dejar pasar nada.

Decisión 2 — protocolos de texto estructurado, no JSON. Pedirle a un LLM que produzca JSON entre agentes es frágil: el modelo se inventa comas, mete prosa antes del bloque, escapa mal las comillas. ApolloAgents usa bloques de texto con palabras clave centinela. Janus contesta así:

CONFIRMED
genre: techno
duration_min: 60
mood: dark industrial build to a hard peak

Y Momus así:

PROBLEMS:
- [pos 2→3] key clash 5A → 11A — fix: swap pos 3 for a 6A track
- [pos 7→8] BPM jump 132 → 148 — fix: insert bridge track

VERDICT: NEEDS_FIXES

El parser es una iteración línea a línea de unas pocas decenas de líneas de Python. Si el modelo añade prosa, no rompe. Si se sale de formato, hay fallbacks. Es feo en lo teórico y robustísimo en la práctica.

Decisión 3 — dos checkpoints humanos dentro del pipeline, no al final. La automatización completa era tentadora pero equivocada. El checkpoint 1 va después del Planner y antes del Critic. El checkpoint 2, después del Critic. ¿Por qué dos y no uno? Porque las preguntas son distintas: en el primero estás dando forma al arco de energía; en el segundo, decidiendo qué problemas concretos te merece la pena arreglar y cuáles asumir. Mezclar las dos conversaciones añade carga cognitiva y empeora ambas decisiones. Los checkpoints son hard gates: ningún agente aplica un fix sin tu visto bueno explícito.

Decisión 4 — un solo main.py de ~2.600 líneas. Esto sigue siendo polémico y lo sigo defendiendo. Para un proyecto de este alcance, un único fichero inspeccionable con secciones bien marcadas es más mantenible que una jerarquía de módulos por la que hay que saltar para entender un cambio de tres líneas. La capa de agentes (agent/) sí va separada — porque su ciclo de iteración (prompts, signaturas de tools, esquema de memoria) es de naturaleza diferente al del pipeline DSP.

v1.1–v1.3: pulir el sonido, no las capas (abril)

A finales de abril el sistema funcionaba pero seguía haciendo dos cosas mal. Cada cosa generó un mini-ciclo de mejoras.

Las duraciones eran estimaciones. El Planner calculaba la longitud de la sesión asumiendo 5 minutos por track. Para una sesión de 60 min pedía 12 tracks y la realidad podía salir 50 o 75. Solución en v1.1: leer duration_sec del header WAV una vez al construir el catálogo, almacenarlo en tracks.json y usarlo para todos los cálculos posteriores. Coste: cero decode. Beneficio: la duración prometida y la entregada se acercan.

La detección de BPM mentía en lofi. Librosa tendía a detectar todo el lofi a 110 BPM por culpa del clásico problema del octavado (tomar el off-beat por el beat y duplicar el tempo). La v1.1.1 corrige detect_bpm() para sesgar start_bpm al punto medio del género y probar bpm/2 y bpm*2 antes de hacer el clamp. Resultado: el lofi ahora se detecta a 70–85 BPM, que es lo que tiene que ser.

Los crossfades extremos sonaban a moledora. Pyrubberband empieza a producir artefactos audibles a partir de ratios de 1.5×. Antes, si el Planner ponía un track de 90 BPM seguido de uno de 140, el sistema lo intentaba estirar y el resultado parecía un cassette estropeado. La v1.3 introdujo tres mecanismos:

• _STRETCH_MAX = 1.5 — bound duro de seguridad. Cualquier transición que requiera más se marca como problema obligatorio.
• suggest_bridge_track(from_pos, to_pos) — busca en el catálogo un track con BPM intermedio, lo puntúa por min(ratio_a, 1/ratio_a) × min(ratio_b, 1/ratio_b) y devuelve los 3 mejores candidatos.
• insert_bridge_track(after_position, track_id) — inserta el bridge elegido, partiendo una transición imposible en dos transiciones individualmente seguras.

Y un cuarto detalle que cambia la sensación más de lo que parece: EQ matching en el crossfade. Cuando la distancia harmónica entre dos tracks es > 2 pasos Camelot, se aplica un high-shelf cut de −3 dB a 8 kHz en el saliente y un low-shelf cut de −3 dB a 250 Hz en el entrante, solo durante el solape. Eso reduce el enmascaramiento frecuencial sin tocar el audio fuera de la transición. Es el tipo de truco que un ingeniero de mezcla aplica de oído y que, formulado, es media docena de líneas.

v1.4–v1.5: del batch al directo (abril)

A mitad de abril el agente sabía construir sesiones pero no sabía escucharlas. Se podía rendear un MP4 de 60 minutos sin tener forma de previsualizar una transición antes de comprometer al render completo. v1.4 mete tres tools que cambian el ritmo del workflow: play_mix, preview_transition y play_track. De repente puedes auditar dos tracks solapados ±15s antes de decidir si están bien encadenados, sin esperar 40 minutos de render.

Pero la conclusión real de ese movimiento llegó dos días después, en v1.5: si puedes reproducir, puedes pinchar en vivo.

LiveDJ es un agente proactivo con su propio motor de audio. Mientras suena una pista, otro hilo está estirando temporalmente la siguiente con pyrubberband en background, de modo que cuando llega el momento del crossfade la siguiente pista ya está en memoria al BPM correcto. El motor corre cuatro hilos:

El watchdog corre al doble de frecuencia que el event loop del agente. Eso garantiza que ningún evento crítico (cruce de umbral, fin de pista) se pierda entre dos polls del LLM. Y el agente tiene un presupuesto duro de 5 turnos por batch de eventos — si lo agota sin llamar a una tool terminal, el motor cae al comportamiento automático. Sin ese tope, una situación ambigua podría arrastrar al agente a una cadena de razonamientos mientras la música sigue sonando.

La regla de decisión que aplica LiveDJ cuando se acerca un crossfade cabe en tres líneas:

Y mientras suena, tú puedes escribir cosas como next, stay 60, more energetic o wind down. Algunas (las literales) se ejecutan sin mediación del LLM, por latencia. Otras (las naturales) pasan por el agente para que traduzca a llamadas de tool.

v2.0–v2.6: abrir la cabina (abril–mayo)

Hasta v1.5 todo vivía en la terminal. v2.0 fue el primer salto fuerte: convertir cada fase del pipeline en endpoints de FastAPI, abrir un canal WebSocket para el streaming del agente, y montar un cliente Next.js + React 19 con vista de playlist arrastrable y sidebar de Critic. El print() muere; sale el evento tipado.

De v2.1 a v2.5 vinieron capas finas pero cargadas de detalles:

• v2.1 — visuales reactivos al beat en el navegador, con eventos del LiveEngine puenteados al frontend como JSON tipado.
• v2.2 — playlists nombrados con CRUD + reorder por drag-and-drop. Estandarización de puertos de desarrollo: 4010 frontend, 4020 backend.
• v2.3 — user_id propagado por todo el thread, ratings por track y favorites, bias del Planner según las puntuaciones del propio usuario. Los agentes empiezan a tener oído por persona.
• v2.5 — el LiveEngine cruza al navegador: tres modos (Audience, Booth, Immersive), capa visual sincronizada al beat, y modo improvisación con micro + peticiones del público.

Y entonces, el 11 de mayo, v2.6.0 Ember. La escalera de 9 fases del frontend anterior se colapsa en cinco rutas planas con un vocabulario visual común — italic-serif, acento ember-rojo, una sola línea de mando:

/dashboard   → la sesión de esta noche + el último póster impreso
/brief       → una frase entra, un brief estructurado sale
/curate      → arco, playlist, notas del crítico (apply / ignore en línea)
/editor      → reordenar, swap, insertar bridge tracks
/render      → backend ffmpeg → MP4 1080p con progreso por SSE
/live        → reproducción real, modos Audience / Booth / Immersive

El brief lo parsea Claude Haiku en menos de 300 ms a {genre, duration, mood, venue, energy, tempo}. Si algo es ambiguo, Apollo pregunta en la misma pantalla y retoma cuando confirmas. Los checkpoints siguen existiendo, pero dejan de ser muros que cruzar fase a fase: ahora son anotaciones en el margen que aplicas con un click o ignoras.

v2.7–v3.1: el último kilómetro (mayo)

Las últimas semanas el proyecto se ha movido en el espacio entre "esto funciona en mi máquina" y "esto funciona en directo delante de gente".

• v2.7 — ingesta de YouTube Live Chat como peticiones del público en directo. La audiencia escribe en YouTube, el motor lo lee y el agente decide si meterlo en la siguiente decisión.
• v2.7.2 — feed de OBS, waveform peaks en el navegador, polling de YouTube más amable con la API.
• v2.7.3 / v2.7.4 — reconexión robusta de WebSocket en vivo, disciplina del agente, observabilidad.
• v3.0 — precision beat matching offline y live con paridad. Las transiciones se enganchan a downbeats reales (detectados con madmom) en lugar de aproximaciones.
• v3.0.1 — un critic_warning cuando el phase-lock no encuentra el downbeat y cae al linear fade. Pequeño cambio, gran efecto en confianza: ahora sabes cuándo el sistema está improvisando.
• v3.1 — live beat matching con paridad en el navegador via playbackRate. El tempo en el HTML5 audio del frontend coincide con el del motor offline. Lo que sale por el OBS suena igual que lo que sale por el render.

Y un último detalle de la semana pasada que cambia la vida para quien viene nuevo al proyecto: un stack de Docker Compose con hot reload tanto para backend como para frontend. docker compose up --build y tienes todo corriendo, sin pelearte con uv ni con npm.

Lo que aprendí construyendo esto

Hay tres cosas que me llevo del recorrido, y que mantengo cuando empiezo proyectos nuevos.

Los roles acotados ganan a los súper-agentes. Es tentador escribir un system prompt gigante y dejar que un único modelo "lo haga todo". La experiencia con Apollo dice lo contrario: cuanto más estrecho es el rol — Janus solo valida, Momus solo critica, Themis solo analiza — más predecible y depurable es el resultado. La modularidad no es elegancia: es la única forma de saber en qué fase se rompió algo.

El texto estructurado le come la tostada al JSON entre agentes. Pedirle a un LLM bloques con palabras centinela (CONFIRMED, PROBLEMS, VERDICT, Status:) y parsearlos línea a línea suena primitivo. Pero sobrevive a la prosa de más, a las comillas mal escapadas, a los modelos que cambian de proveedor. JSON parecía la respuesta correcta y, en producción, no lo era.

Los humanos en checkpoints concretos, no como aprobación final. El valor del crítico no es enforzar el fix. Es señalar el problema. La decisión sobre qué arreglar — y qué asumir — es del usuario, y tiene que vivir dentro del pipeline, no después. Cuando moví los checkpoints de "al final, una vez" a "después del Planner y después del Critic", la calidad de las sesiones subió de golpe.

ApolloAgents es open source bajo MIT, está en github.com/pabloformoso/apollo-agents, y todo lo que ves en este canal de YouTube ha sido generado por el sistema en alguna de sus versiones. Si lo pruebas — una star en el repo y, sobre todo, lo que encuentres roto en los issues, me harían el día.

Ayer publiqué la primera versión usable de un proyecto pequeño y un poco recursivo: csk, un gestor de skills para Claude Code. La parte recursiva es que no escribí ni una línea de código a mano. csk está hecho, de principio a fin, con Claude Code. Una herramienta para Claude Code, construida por Claude Code. Una serpiente mordiéndose la cola, pero una serpiente que compila.

Quiero contarte qué problema resuelve, porque seguramente lo tienes y no le has puesto nombre todavía, y dejarte el camino para probarlo en cinco minutos.

El problema: skills sin esqueleto

Si usas Claude Code, sabes que una skill es una carpeta con instrucciones que le enseña a hacer algo concreto: un flujo, un formato, una manía tuya. Claude Code tiene dos formas de cargarlas. Los plugins se distribuyen por un marketplace, se instalan con un comando y se actualizan solos. Y luego están las skills personales: carpetas sueltas en ~/.claude/skills/.

Aquí está la grieta. Los plugins tienen una historia de distribución cuidada. Las skills personales no tienen ninguna. Si desarrollas una skill en su propio repositorio de git, el flujo es artesanal y un poco triste: clonar a mano, copiar o enlazar dentro de ~/.claude/skills/, y acordarte —tú, con tu memoria de primate— de hacer git pull cada cierto tiempo. No hay manifiesto. No hay lockfile. No hay forma de declarar "este es mi conjunto de skills" y reproducirlo en otra máquina o pasárselo a un compañero.

Piénsalo en términos de biomecánica. Un plugin es una prótesis que viene con su servicio de ajuste: encaja, se calibra, se revisa. Una skill personal es una prótesis que llevas suelta en la mochila y te atas como puedes cada mañana. Funciona, sí. Pero no hay tejido conectivo: nada que sujete el conjunto, nada que garantice que el brazo de hoy es el mismo que el de ayer.

Y el efecto secundario es el peor de todos: la deriva. Trabajas en el portátil, en la torre de casa, en el de la oficina. Cada máquina acumula sus propias versiones, sus propios parches, sus propios olvidos. Al cabo de unos meses no tienes un entorno replicado tres veces: tienes tres subespecies distintas del mismo organismo, evolucionando por separado y en silencio. El día que una falla y otra no, no tienes ni idea de por qué.

Qué es csk

csk llena exactamente esa grieta. La idea es robarle el modelo mental a herramientas que ya funcionan: lo que cargo o uv son para las librerías, csk lo es para las skills. Tres piezas, y la metáfora se cae sola:

El manifiesto (skills.toml) es el ADN. Tú lo editas. Declaras cada skill con una clave, una URL de git y, si quieres, una rama o un subdirectorio. Es la intención: "este organismo debería tener estos órganos".

El lockfile (skills.lock) es la expresión fijada de ese ADN. Lo escribe csk, no tú, y ancla cada skill a un commit exacto. Es la diferencia entre "quiero un perro" y "quiero este perro, con este genoma, hasta el último par de bases".

csk install es la clonación. En una máquina nueva, csk lee el lockfile y reconstruye el conjunto idéntico: mismas skills, mismos commits clavados. El mismo organismo, no un primo lejano.

Lo elegante es que csk no toca Claude Code para nada. Escribe en las mismas rutas de ~/.claude/skills/ que Claude ya lee. Claude Code no necesita enterarse de que csk existe. Cero acoplamiento.

Pruébalo en cinco minutos

csk es un único binario estático, escrito en Go. En macOS o Linux se instala así (en el README tienes la versión para Windows con PowerShell):

mkdir -p ~/.local/bin
OS=$(uname -s | tr '[:upper:]' '[:lower:]')
ARCH=$(uname -m); case "$ARCH" in x86_64|amd64) ARCH=x86_64;; aarch64|arm64) ARCH=arm64;; esac
VERSION=$(curl -sI https://github.com/pformoso-deus-ai/csk/releases/latest | awk -F/ '/^location:/ {print $NF}' | tr -d '[:cntrl:]')
curl -fsSL "https://github.com/pformoso-deus-ai/csk/releases/download/${VERSION}/csk_${VERSION#v}_${OS}_${ARCH}.tar.gz" | tar xz -C ~/.local/bin csk
chmod +x ~/.local/bin/csk

A partir de ahí, el flujo del día a día:

csk init                 # crea el manifiesto y el lockfile vacíos
csk search handoff       # busca en el registro público (Skill Central)
csk add handoff          # instala una skill por su nombre corto
csk list                 # ves qué tienes y en qué estado está cada cosa

También puedes instalar directamente desde cualquier URL de git, sin pasar por el registro:

csk add https://github.com/pformoso-deus-ai/handoff-claude-skill.git

Y aquí está el momento que justifica todo el invento. Haces commit de tus dos ficheros —skills.toml y skills.lock— junto a tus dotfiles. En la siguiente máquina, después de clonarlos:

csk install

Mismo conjunto de skills, mismos commits, sin deriva. La diferencia entre recordar y no tener que recordar. Si prefieres un conjunto por proyecto en lugar de uno global, los mismos comandos dentro de la carpeta del proyecto crean un .claude/skills.toml local; csk detecta el ámbito solo.

Hay más en la caja —csk update para refrescar versiones, csk adopt para registrar una skill que ya tenías instalada a mano sin perder nada, csk doctor para diagnosticar la deriva antes de que duela, csk upgrade para que el propio binario se actualice—, pero con esos cuatro comandos ya tienes el 90% del valor.

La parte recursiva

Vuelvo al principio, porque es lo que más me interesa de este experimento. csk salió de una conversación: una especificación escrita junto a Claude Code, discutida, recortada, y luego implementada en Go por el propio Claude Code. Catorce commits, cuatro releases, de la idea a un binario que funciona en tres sistemas operativos. Yo hice de arquitecto y de crítico; el teclado lo llevó el modelo.

Y eso abre una puerta con un punto distópico que no me apetece esquivar. A medida que el agente se convierte en tu interfaz principal de trabajo, tus skills dejan de ser un detalle de configuración: son, literalmente, tu cuerpo aumentado. Son lo que sabes hacer a través de la máquina. Y ahora mismo ese cuerpo no tiene control de versiones. Cada portátil es un injerto distinto, cada actualización un parche sin registrar, y nadie —ni tú— sabe exactamente de qué está hecho tu propio entorno.

csk es, en el fondo, un intento modesto de ponerle un esqueleto a eso. Un manifiesto que diga "esto es lo que soy" y un lockfile que lo demuestre. Porque si vamos a delegar cada vez más de nuestra capacidad en estas herramientas, lo mínimo es saber —y poder reproducir— de qué están hechas.

El proyecto es open source, con licencia MIT, y está aquí: github.com/pformoso-deus-ai/csk. Si lo pruebas, una star y, sobre todo, tu feedback en los issues me harían el día.

Fuentes y enlaces: repositorio de csk en GitHub · documentación de skills de Claude Code

Hace dos días, el Día Mundial de la Enfermedad Inflamatoria Intestinal, publicamos un benchmark honesto de nuestro asistente de IA médica. Hoy te cuento por qué estuvimos a punto de publicarlo mal, y qué encontramos cuando decidimos abrir en canal el único número que no nos cuadraba.

Esto es un post mortem. Y como todo buen post mortem, empieza con un cuerpo sobre la mesa.

El paciente que no encajaba

El examen era sencillo de enunciar: 27 preguntas sobre EII extraídas de MIRAGE, un banco de pruebas para IA médica. Una mezcla de viñetas clínicas tipo examen de licencia (esas de «un paciente acude a consulta con…»), literatura biomédica de PubMedQA y un set curado de farmacología específica de la EII.

Para puntuar usamos RAGAS answer_correctness: una métrica de 0 a 1 en la que otro modelo actúa de juez y compara nuestra respuesta con la respuesta correcta de referencia. Y aquí va un detalle que importará luego: es una métrica de precisión. No premia escribir mucho ni demostrar que sabes. Premia decir lo correcto sin rellenar.

Casi todo iba razonablemente bien. Hasta que apareció un escenario que se nos quedó clavado.

Una mujer de 38 años, con una resección ileal previa por enfermedad de Crohn, llega con un cólico biliar. La respuesta correcta es coledocolitiasis: una piedra atascada en el conducto biliar. No es una pregunta tramposa; de hecho tiene una lógica biomecánica preciosa, porque quitarle a alguien una parte del íleon estropea la reabsorción de sales biliares y lo predispone justamente a fabricar cálculos. El cuerpo, otra vez, contando su propia historia.

Nuestro sistema sacó un 0,382. Un GPT-4o desnudo —el modelo crudo, sin nuestro RAG, sin nuestra tubería de agentes, solo él— sacó un 0,892. Una brecha de 0,510 puntos. En un solo escenario.

Conviene parar aquí, porque esto es incómodo. Habíamos construido toda una arquitectura alrededor del modelo —recuperación de documentos, orquestación, personas— y en esa pregunta el modelo a pelo nos barría. Habíamos puesto andamios y el andamio pesaba más que el edificio.

La tentación de publicar igual

Podríamos haber publicado el benchmark tal cual. Un escenario flojo entre 27 no hunde una media. Se redondea, se acompaña de una nota a pie de página y nadie pregunta.

No lo hicimos. Y no por orgullo, sino por una regla que es casi anatómica: un número que no sabes defender es un bulto que no has palpado. Puede no ser nada. O puede ser lo que te mate seis meses después, en producción, con un usuario real delante.

Así que abrimos. Dos días de análisis forense de causa raíz. Y lo que encontramos no fue un bug. Fueron cuatro. En serie. Y, como las capas de un tejido, cada uno tapaba al de debajo.

Cuatro bugs, en serie, tapándose unos a otros

Esta es la parte que merece detalle, porque el patrón es más interesante que cualquiera de los fallos por separado.

Bug 1 — Mojibake en la zona de uso privado

Una tubería RAG empieza por leer documentos. Nosotros le damos de comer un corpus médico en PDF, lo troceamos en fragmentos y guardamos cada fragmento como un vector —una huella numérica de su significado— para poder buscar por similitud.

Dos de esos PDF estaban envenenados. Su texto venía codificado en la Private Use Area de Unicode: un rincón del estándar deliberadamente vacío, pensado para que cada cual meta ahí sus propios símbolos. Una fuente con un cmap personalizado había mapeado las letras a esa zona. Para un humano abriendo el PDF, se leía perfecto. Para nuestro extractor de texto, era mojibake: ristras de caracteres basura sin ningún significado.

Lo venenoso no fue la basura en sí. Fue que nuestro embedder —el componente que convierte texto en vectores— no se quejó. Le diste galimatías y, tan contento, lo colocó en el espacio vectorial y empezó a puntuarlo como «parecido» a las preguntas. Imagina un sistema inmune que, en lugar de marcar un tejido extraño, lo abraza y lo integra. El cuerpo no detecta el problema; lo adopta.

El arreglo: un decodificador heurístico que detecta el desplazamiento de la zona de uso privado y revierte el mapeo, con docling como red de seguridad cuando la heurística no llega.

Bug 2 — El efecto distractor del RAG

Arreglado el primer bug, esperábamos que la herida cerrara. No cerró. Y aquí apareció algo más sutil.

La búsqueda por similitud densa —comparar vectores— de vez en cuando devolvía un fragmento con una puntuación alta, un 0,75, que sin embargo no compartía ni una sola palabra sustantiva con la pregunta. El vector decía «esto es relevante». El texto, leído por un humano, no tenía nada que ver.

Es el equivalente a un reflejo mal calibrado: el estímulo no era el correcto, pero el arco reflejo se dispara igual. Y un fragmento irrelevante metido en el contexto no es neutro. Distrae al modelo. Le da material plausible para construir una respuesta elegante y equivocada.

El arreglo: una compuerta de relevancia, activable por variable de entorno, que descarta el contexto cuando la puntuación de similitud y el solapamiento léxico caen por debajo de sus umbrales —o cuando el solapamiento baja de un suelo de veto, da igual lo alta que sea la puntuación del vector. Si las dos señales no se confirman, no entra.

Bug 3 — La persona equivocada en la sala equivocada

Este es mi favorito, porque no es un fallo de código. Es un fallo de identidad.

Nuestra persona por defecto se llama Matucha: una compañera para personas con enfermedad crónica. Está diseñada para hablar con un paciente real —con calidez, con cuidado, recordándole que consulte con su equipo médico—. Para esa misión, es exactamente lo que debe ser.

El problema es que Matucha también estaba respondiendo las viñetas tipo examen. Y a un tribunal de licencia médica le estaba contestando con preámbulos empáticos y avisos de «consulta a tu profesional sanitario», enterrando el diagnóstico bajo capas de amabilidad. La respuesta correcta estaba ahí dentro. Solo que sepultada.

Era el animal correcto en el hábitat equivocado. Un pez extraordinario al que habíamos pedido escalar un árbol.

El arreglo: despacho según el modo. Las preguntas en tercera persona —»Una mujer de 38 años acude a consulta…»— se reconocen como registro académico y se enrutan por un canal clínico, directo y sin preámbulos. Las preguntas de un paciente de verdad siguen llegando a Matucha, intacta.

Bug 4 — La verborrea que diluye

Con el canal académico ya funcionando, quedaba un último goteo. El prompt académico producía respuestas de 8 o 9 frases, mientras que el GPT-4o desnudo despachaba en 4 o 5.

Y aquí vuelve el detalle del principio. RAGAS answer_correctness es una métrica de precisión. Cada frase de fisiopatología correcta pero irrelevante que añades no suma: diluye. Es como una analítica con demasiados marcadores pedidos «por si acaso» —cada valor de más no aporta señal, solo ruido que enmascara el dato que importa.

El arreglo: apretar el prompt a 3 o 4 frases como máximo. Decir lo correcto, y callarse.

El quinto problema no era un bug del producto

Hay un quinto hallazgo que merece una mención aparte, porque es el más traicionero de todos.

Nuestro orquestador de evaluación tenía un timeout de 30 segundos. Y estaba cortando 8 de los 9 escenarios de tipo examen antes de que se pudieran medir. Es decir: durante parte del proceso estuvimos arreglando bugs sin poder ver siquiera el efecto de los arreglos, porque el banco de pruebas censuraba las respuestas antes de puntuarlas.

Lo importante: la experiencia del usuario real estuvo bien todo el tiempo. El producto respondía. Lo que estaba roto era el instrumento de medida, no el paciente. Y eso da escalofríos, porque es el error que más se parece a un termómetro estropeado: no te enferma, pero te hace tomar todas las decisiones a ciegas.

Dónde quedamos

Dos días. Ocho pull requests. La misma tanda del juez RAGAS sobre el mismo subconjunto de 27 escenarios de EII.

El resultado: 0,310 de RAGAS answer_correctness para SynapseFlow, 0,310 para el GPT-4o desnudo. Paridad. Y dentro de esa paridad global, ganamos justo en los cubos donde la recuperación de documentos importa de verdad: +0,056 en farmacología de la EII y +0,049 en literatura de PubMedQA.

Quiero ser claro con lo que esto significa y con lo que no. No significa que seamos mejores. Significa que, después de depurar cuatro bugs en serie, una arquitectura RAG con agentes está a la altura del modelo crudo, y empieza a despuntar exactamente donde se supone que debe aportar: cuando hay que ir a buscar un dato a un documento. Esa es la posición honesta. Ni «estado del arte» ni superlativos. Paridad ganada a pulso.

¿Dónde seguimos por detrás? En 3 de las 9 viñetas tipo examen, donde nuestra respuesta académica era correcta pero estaba formulada de manera distinta a la de referencia. Sospechamos que es varianza del juez, no un fallo del producto. Lo estamos investigando, y lo diremos cuando lo sepamos.

Lo que aprendimos

Si te dedicas a construir IA médica con agentes, la lección se resume en una frase: las tuberías de agentes apilan modos de fallo.

Un único punto de answer_correctness fuera de sitio escondía cuatro bugs en serie, y cada uno enmascaraba al siguiente. Arreglas el mojibake y aparece el distractor. Arreglas el distractor y aparece la persona. Arreglas la persona y aparece la verborrea. Es la diferencia entre un organismo y una pieza suelta: en un sistema con muchas capas, ningún síntoma apunta limpiamente a una sola causa. Hay que disecar.

Y la disciplina forense de negarse a publicar un número que no puedes defender no es una formalidad. Es el juego entero.

El informe completo —con el detalle escenario a escenario, todos los JSON de la línea base y el rastro de auditoría de las 8 PR— está aquí: github.com/DEUS-AI/SynapseFlow → docs/benchmarks/eje1-ibd-baseline.md.

Lo siguiente: los mismos 27 escenarios contra KAG (Liang et al., 2024). Esa es la comparación que toda esta autopsia nos estaba comprando el derecho a hacer con credibilidad. La contaremos cuando tengamos los números. No antes.

Próximo post: SynapseFlow contra KAG — la comparación que esta autopsia hizo posible.

La Venus atrapamoscas pertenece a las segundas. No persigue a nada. Despliega sus hojas, segrega un néctar dulce justo en el borde, y espera. El insecto entra por su propia voluntad, atraído por algo que parece un regalo. Solo cuando roza dos veces los pelillos sensibles del interior —cuando ya está dentro— la hoja se pliega. La planta nunca cazó nada. La presa se cazó a sí misma.

Los tres primeros ídolos de la augmentación funcionan como una trampa de golpe. Te convencen de que todo se puede diseñar, de que diseñar no cuesta nada, de que puedes fundirte con la máquina sin perder nada por el camino. Pero queda un cuarto ídolo, y este es de los que esperan. No te ataca la libertad. Te ataca la conciencia. Y te deja entrar tú solito, persiguiendo lo que parece el néctar más dulce de todos: la responsabilidad moral.

En la Parte 1 desmontamos los tres primeros: lo diseñable («todo es mejorable»), la neutralidad («mejorar no cuesta nada») y la fusión sin resto («podemos ganarlo todo sin perder nada»). Tres estructuras de pensamiento que se disfrazan de sentido común. Hoy nombramos el cuarto, el que cierra el circuito. Y luego —porque no todo es diagnóstico— buscamos la salida.

Ídolo 4: La Guía Génica

El filósofo Peter Sloterdijk encendió un incendio en 1999 con una conferencia que acabó publicada como Normas para el parque humano. Su idea, despojada de polémica, era esta: durante siglos el humanismo fue una tecnología de «domesticación» —educar, leer, civilizar—, pero esa tecnología está agotada. Lo que viene, decía, es la pregunta incómoda de la antropotécnica: la posibilidad de que la humanidad se convierta a sí misma en un proyecto de diseño consciente, también a nivel biológico.

El cuarto ídolo toma esa pregunta y la convierte en mandamiento. No dice solo que podemos guiar nuestra propia evolución. Dice que debemos. Que dejar la naturaleza humana en manos del azar —de la lotería genética, de la mutación ciega— es una forma de negligencia. Que si tienes el poder de evitar el sufrimiento de tus descendientes y no lo usas, eres cómplice de ese sufrimiento.

Y aquí está lo brillante —y lo perverso— de este ídolo: suena a virtud. Suena, de hecho, a la única postura decente posible. ¿No es egoísta negarse a mejorar a tus hijos? ¿No es cobarde esconderse detrás de la palabra «natural»?

Fíjate en el desplazamiento. Los tres primeros ídolos discutían lo que era posible y lo que costaba. El cuarto ya no discute eso. El cuarto te mira a los ojos y te pregunta qué clase de padre, qué clase de ciudadano, qué clase de especie quieres ser. Convierte la prudencia en pereza moral. Convierte el respeto por lo dado en abandono.

Pero el propio Sloterdijk avisaba del filo de esa navaja: cuando la naturaleza humana se convierte en un proyecto, los humanos se convierten en material de construcción. Y un material de construcción no se respeta: se selecciona, se descarta, se mejora según un plano. La línea entre la terapia génica que cura una enfermedad real y el «perfeccionamiento» de un rasgo que a alguien le parece deseable es mucho más borrosa de lo que nos gustaría. Y alguien tiene que trazar esa línea. Alguien —un comité, una corporación, un Estado, una moda— decide hacia dónde evoluciona la especie.

Esa es la pregunta que el cuarto ídolo entierra bajo su retórica de responsabilidad: ¿quién sostiene el lápiz?

La trampa completa

Mira los cuatro funcionando juntos, como cuatro paredes de una misma habitación sin puerta:

1. Lo diseñable: «Todo es mejorable.»
2. La neutralidad: «Mejorar no tiene coste.»
3. La fusión sin resto: «Puedes ganarlo todo sin perder nada.»
4. La guía génica: «Y no solo puedes: debes.»

Una vez que aceptas los cuatro supuestos, la augmentación deja de ser una opción. Se vuelve un imperativo. Rechazarla no es solo ineficiente: es inmoral. Es condenar a tus hijos a ser una «versión anterior» de humano mientras el resto del mundo actualiza el firmware de la especie.

Ese es el verdadero genio de la trampa. No ataca tu libertad de frente —eso lo verías venir—. Ataca tu sentido de la responsabilidad por la puerta de atrás, vestido de bondad. Y como la Venus atrapamoscas, espera a que seas tú quien cierre la hoja.

Pero toda trampa tiene una grieta. Y esta tiene una bastante grande.

La grieta: confundir el mapa con el territorio

Los cuatro ídolos comparten un error de fondo, y es un error de ingeniero: asumen que porque podemos describir algo, podemos controlarlo. Que si reducimos un ser humano a parámetros —memoria, atención, fuerza, resistencia—, lo dominamos.

Pero un organismo vivo no es una lista de parámetros. Es un sistema.

Pierre Teilhard de Chardin —jesuita, paleontólogo, una de las mentes más raras del siglo XX— pasó su vida estudiando cómo la vida se complejiza. Y vio algo que el ingeniero suele pasar por alto: la evolución no es un proceso de optimización dirigido. Es un proceso de emergencia. La complejidad no se calcula; surge. Aparece de la interacción de millones de elementos, del azar y la necesidad trabajando juntos, de encuentros que ninguna ecuación anticipó.

Es la diferencia entre un plano y un río. Puedes dibujar el cauce de un río sobre un papel con una regla. Pero el río real tiene turbulencias, remansos, fricción contra la roca, sedimentos que mañana cambiarán su curso. El río es un sistema vivo. El plano es una mentira útil. Y el cuarto ídolo te invita a gestionar el río humano como si fuera el plano.

Por qué no somos módulos

Aquí es donde la biomecánica nos da la lección más clara.

Imagina que decides «mejorar» un solo músculo de tu cuerpo: que crezca el doble, que sea el doble de fuerte. Suena a ganancia pura. Pero tu cuerpo no es una caja de piezas independientes. Es una cadena cinética. Ese músculo tira de tendones que no se han reforzado, sobre articulaciones que no se han recalibrado, dentro de una postura que el cerebro lleva décadas afinando. El «upgrade» no te hace más fuerte: te hace una lesión esperando a ocurrir.

Con la mente pasa exactamente igual, solo que no lo vemos porque no sangra.

La memoria no es una carpeta de archivos que puedas ampliar. Está tejida con la emoción, con la identidad, con el sentido del tiempo. El olvido no es un fallo del sistema: es lo que te permite perdonar, lo que evita que cada herida siga igual de fresca treinta años después. La inteligencia no es un procesador: emerge de un cuerpo que existió en un mundo peligroso, de la necesidad, del miedo, del límite. Aumentar un rasgo «aislado» sin entender de qué totalidad emerge puede fabricar monstruosidades con la misma facilidad que maravillas.

El error de los cuatro ídolos es creer que el ser humano es descomponible. Y no lo es. Todo está tejido con todo. Lo que parece una ganancia limpia en una dimensión casi siempre es una pérdida invisible en otra.

La salida no es el rechazo

Llegados aquí, mucha gente da un volantazo: si no puedo abrazar el diseño total, entonces hay que rechazar la tecnología, volver a la cueva, romper las máquinas.

No. Esa es una falsa salida —y, además, una bastante cobarde—.

Teilhard proponía algo más difícil y más interesante: no se trata de dirigir la evolución hacia un destino que hayamos elegido en una pizarra. Se trata de participar sabiamente en un proceso que nos supera. De traer conciencia, cuidado y humildad al desarrollo tecnológico, sin la fantasía de que podemos prever todas las consecuencias.

Es una postura de humildad, sí. Pero no de parálisis. Es cuidado inteligente. La pregunta deja de ser «¿podemos?» y pasa a ser «¿deberíamos?». Y «deberíamos» no se responde con la lógica del marketing —»más siempre es mejor»—, sino con la lógica más antigua de la medicina.

El criterio: primero, no dañes

El juramento hipocrático nos dio, hace dos mil quinientos años, la mejor brújula que tenemos para esto: primum non nocere. Primero, no dañes.

Es un criterio sorprendentemente práctico. Una intervención es legítima cuando trata una enfermedad genuina, cuando alivia un sufrimiento real, cuando restaura algo que se perdió. Se vuelve problemática cuando empieza a «mejorar» lo que no estaba roto, cuando confunde diferente con defectuoso, cuando mira una limitación humana y solo ve un bug pendiente de parche.

La terapia génica que cura una enfermedad degenerativa: legítima. El «perfeccionamiento» de la inteligencia en un embrión sano: problemático. La prótesis que devuelve la movilidad a quien la perdió: legítima. El implante que «optimiza» la experiencia sensorial de quien no tenía ningún problema: problemático.

¿Por qué la diferencia? Porque en los primeros casos reparamos una grieta. En los segundos, presumimos saber, mejor que millones de años de evolución, qué debería ser un humano.

El retorno del misterio

Quizá lo más revolucionario de nuestra época no sea abrirse del todo a la augmentación. Quizá sea, simplemente, resistir la idea de que todo tiene que ser diseñado, optimizado y mejorado.

Teilhard escribía sobre una «religión de la tierra»: una forma de habitarla con asombro en lugar de conquistarla a martillazos de ingeniería. Ver la vida no como un problema esperando solución, sino como un misterio esperando participación.

Los cuatro ídolos trabajan juntos para convencerte de que el misterio es ignorancia, de que la complejidad es un defecto, de que todo debe reducirse a código, a especificación, a control. Pero una vida vivida en plenitud necesita que algunas cosas sigan siendo misteriosas. Necesita aceptar que somos hijos de un proceso que no diseñamos, que cargamos un cuerpo cuya sabiduría supera nuestra comprensión, que participamos en una evolución que continuará sin nosotros y de formas que no podemos prever.

Y eso no es una limitación que haya que corregir. Es el suelo sobre el que se sostiene la libertad.

El cierre

Hemos recorrido cuatro ídolos. Lo diseñable nos dijo que todo se puede tocar. La neutralidad, que tocarlo no cuesta nada. La fusión sin resto, que podíamos fundirnos sin perdernos. Y la guía génica, el más íntimo de todos, nos dijo que negarnos a hacerlo era una falta moral.

Juntos construyen un laberinto sin puerta. Pero la puerta existe. No está en rechazar la tecnología —eso es otra cueva—. Está en cambiar nuestra relación con ella: entender que es una herramienta, no un destino. Que el futuro humano no lo decide lo que podemos hacer, sino lo que elegimos hacer con cuidado, con humildad y con amor.

El cuarto ídolo promete que seremos dioses si nos dejamos rediseñar. Pero quizá ya somos algo más extraño y más hermoso que un dios: somos materia que se volvió consciente de sí misma. Somos el universo mirándose a través de unos ojos. Y eso, simplemente eso, no necesita una actualización.

Necesita respeto.

La pregunta nunca fue «¿qué podemos hacer?».

La pregunta que importa, la que cierra esta serie y abre todo lo demás, es: ¿qué clase de humanidad queremos ser?

Fuentes y lecturas: Peter Sloterdijk, Normas para el parque humano (Siruela, 2000); Pierre Teilhard de Chardin, El fenómeno humano; Michael Sandel, Contra la perfección; Jürgen Habermas, El futuro de la naturaleza humana.

Fin de la serie «Elegir la Pastilla Roja: El Angelismo Moderno».

No es un gesto dramático. No es una epifanía ni una conversión. Es más parecido a lo que le pasa a un árbol cuando sus raíces encuentran roca: empieza a crecer en la única dirección que el sustrato le permite, y con el tiempo ya no recuerda que alguna vez pudo crecer en otra. La postura se convierte en naturaleza. La roca, en horizonte.

Así es exactamente como uno acaba arrodillado ante los ídolos de la augmentación.

En el post anterior exploramos el angelismo moderno: esa convicción de que el cuerpo es un borrador defectuoso, un problema técnico que aguarda la mano del ingeniero. Pero una pregunta quedó flotando: ¿de dónde surge esa certeza? ¿Por qué estamos tan seguros de que diseñar es mejor que recibir, que más siempre es mejor, que toda limitación es una avería y toda capacidad, un parámetro a optimizar?

La respuesta está en tres ídolos. No son estatuas de piedra ni dioses olvidados. Son estructuras de pensamiento que se disfrazan de evidencia, de neutralidad, de sentido común. Y eso es precisamente lo que los hace peligrosos: no se anuncian como dogmas. Simplemente están ahí, como el aire, y sin darte cuenta ya respiras solo por ellos.

Ídolo 1: Lo Diseñable como Inevitabilidad

Imagina un río. Durante miles de años fluye según su naturaleza: con meandros, pausas, desbordamientos. Un día llega un ingeniero y dice: «Esto puede optimizarse. Rectificaremos el cauce, controlaremos el caudal, haremos que el agua llegue exactamente donde la necesitamos.»

Así funciona el primer ídolo: la convicción de que porque podemos diseñar algo, debe ser diseñado.

Michael Sandel, en The Case Against Perfection, identificó algo crucial: cuando elevamos el diseño a un imperativo moral, perdemos la capacidad de experimentar nuestras vidas como un regalo. Lo «dado» —ese sustrato de realidad que no elegimos— es lo que nos permite tener una relación de humildad con la existencia. Pero la mentalidad augmentacionista ve lo dado no como un regalo, sino como un borrador defectuoso que espera la pluma del ingeniero.

El problema es sutil pero devastador: si todo es diseñable, entonces nada tiene valor por sí mismo. Un cuerpo no es una maravilla biológica producto de millones de años de evolución; es una versión beta de lo que realmente podría ser. Una mente es un sistema operativo con bugs que necesita patching. Una capacidad humana es un feature que podría aumentarse en la próxima release.

Pero aquí es donde el ídolo juega sucio: no es que el diseño sea malo. Es que el diseño es neutro, ¿verdad? Eso nos lleva al segundo ídolo.

Ídolo 2: Aumento como Neutralidad

Este es el más peligroso porque es el que menos parece un ídolo.

Cuando hablamos de «aumentar» la cognición humana con inteligencia artificial, o de «mejorar» nuestras capacidades físicas con implantes, lo hacemos con un lenguaje que pretende ser neutro. Estamos simplemente sumando capacidades. Un plus, sin negativo asociado. ¿Qué podría haber de malo en tener más?

Jürgen Habermas lo vio con claridad en The Future of Human Nature: no existe tal cosa como una «intervención neutra» en el cuerpo o la mente. Toda modificación implica una apuesta metafísica sobre qué es lo valioso, qué vale la pena preservar y qué debe transformarse. Cuando aumentas la memoria de un ser humano, no estás simplemente sumándole una capacidad; estás diciendo que el olvido es un defecto. Que la finitud cognitiva es un problema. Que la experiencia de no saber algo es algo que debe eliminarse.

Y con eso, has eliminado la posibilidad de asombro, de aprendizaje como transformación, de la vulnerabilidad que nos hace humanos.

El ídolo funciona así: te convence de que estás haciendo matemáticas simples (más capacidad = mejor vida), cuando en realidad estás jugando con la gramática profunda de qué significa ser humano.

Heidegger lo llamaba Gestell —la configuración de la realidad como «recursos» susceptibles de optimización. En el Gestell, nada tiene valor en sí; todo es evaluado según su utilidad y su potencial de mejora. El cielo no es bello; es un «depósito de energía solar». Un río no es un lugar de contemplación; es un «generador hidroeléctrico en potencia». Y nosotros mismos, inevitablemente, empezamos a vernos de la misma forma: depósitos de potencial sin realizar, máquinas con bugs, sistemas que esperan actualización.

Bajo el Gestell, la augmentación no es una opción; es la única forma racional de relacionarse con la realidad. Y eso, precisamente, es lo que convierte a este ídolo en trampa.

Ídolo 3: Fusión sin Resto

El tercer ídolo es el más seductor porque promete la síntesis perfecta: la unión de lo humano y la máquina, la mente biológica y el poder artificial, el individuo y el colectivo aumentado.

«No habrá conflicto», nos dicen. «Seremos más nosotros mismos, solo que mejor.»

Pero aquí está el problema: toda síntesis genuina implica un «resto», algo que no puede ser completamente absorbido en la fusión. Cuando una gota de agua se mezcla con el océano, hay algo que se pierde. No es malo o bueno; es real.

En la fusión de la mente humana con sistemas de IA, ese resto es precisamente lo que hace que seamos humanos: la capacidad de equivocarnos, de resistir, de sorprendernos con nuestras propias limitaciones. Si la IA está dentro de tu cognición, optimizándola en tiempo real, entonces ese espacio de libertad desaparece. No porque la IA sea malvada, sino porque la lógica misma de la optimización es incompatible con la libertad.

Sandel lo expresó así: cuando hacemos todo de acuerdo a diseño, renunciamos a la experiencia de que las cosas nos suceden. Y con eso, renunciamos a la gratitud, la humildad, la sorpresa, la redención — los sentimientos que requieren que algo escape a nuestro control.

La promesa del tercer ídolo es que podemos tenerlo todo: poder y vulnerabilidad, capacidad y sorpresa, individuación y colectivo. Pero la realidad de la Gestell sugiere que eso es una mentira hermosa. Lo que promete ser «fusión sin resto» es, en el fondo, captura con resto invisible.

El Patrón

¿Ves el patrón? El primer ídolo te convence de que todo puede diseñarse. El segundo te convence de que todo debe diseñarse. El tercero te convence de que puedes diseñarlo sin consecuencias.

Juntos, cierran la trampa: no toda síntesis es comunión. Algunas son captura disfrazada de mejora.

En el próximo post exploraremos el cuarto ídolo —el que cierra el circuito— y la posibilidad de que exista una salida a esta lógica que no sea simplemente rechazar la tecnología, sino aprender a habitarla de otro modo.

Porque el punto no es detener la augmentación. Es entender que el cuerpo, la mente, la vida misma, no son problemas esperando solución. Son misterios esperando sabiduría.

Próximo post: La Guía Génica — El Cuarto Ídolo y la Salida del Laberinto

Y en ese momento reconoces algo: no estamos ante una novedad del siglo XXI. Lo que está pasando ahora tiene un nombre que existe hace ochenta años. Se llama angelismo. Y el diagnóstico que lo acompaña es tan preciso que duele.

El Angelismo de Maritain

Jacques Maritain, filósofo católico francés, acuñó el término a mediados del siglo XX como una crítica quirúrgica a Descartes. No era una crítica al cartesianismo como método, sino a su metafísica más profunda: la idea de que el ser humano es, en su esencia, un ángel.

Suena extraño, ¿verdad? Pero espera.

Un ángel, en la teología medieval, es pura inteligencia. No tiene cuerpo, no tiene extensión material, no tiene limitaciones biológicas. Existe en un estado de transparencia perfecta entre su voluntad y su conocimiento. Un ángel es lo que piensa. No hay mediación, no hay fricción, no hay carne que le ralentice.

Lo que Maritain vio en Descartes fue esto: la filosofía cartesiana trataba al ser humano como si fuese un ángel. Reducía lo humano a la res cogitans — la cosa pensante — y relegaba el cuerpo a la categoría de res extensa — la cosa extendida — como si fuese un mecanismo accidental, algo que el verdadero yo (la mente) solo ocupa ocasionalmente, como quien deja el coche en un aparcamiento.

Para Maritain, esto era un error metafísico profundo. El ser humano no es un ángel accidentalmente encarnado. Es un animal racional — una unidad indisociable de cuerpo y espíritu, materia y forma. El cuerpo no es un estorbo. Es parte constitutiva de lo que significa ser humano. Somos, literalmente, de carne.

Y de ahí viene todo lo demás.

El Angelismo Hoy

El diagnóstico de Maritain sobre Descartes es exacto. Pero lo inquietante es que describe perfectamente lo que está pasando ahora, más de tres siglos después.

Observa la retórica. Observa cómo el cuerpo humano se presenta en el discurso de la augmentación: No como algo que nos define. Sino como un problema técnico.

Es un problema que puede ser solucionado mediante intervención. La genética que «heredaste» es un bug. Tu capacidad cognitiva es un spec que puede ser upgradreado. Tu energía física, tu resistencia, tu atención — todo eso son funciones que pueden ser optimizadas. Tus límites biológicos son fricciones innecesarias en el camino hacia la eficiencia perfecta. Y la solución no es aprender a vivir en tu cuerpo. Es escapar de sus restricciones.

Eso es angelismo. Es la creencia de que tu verdadero yo — tu inteligencia, tu capacidad productiva, tu potencial — está accidentalmente atrapado en una materialidad defectuosa que debe ser reparada, aumentada, diseñada, corregida. Que tu esencia es pura funcionalidad y que todo lo que no acelere esa funcionalidad es un accidente lamentable.

El transhumanismo es angelismo. La edición genética de línea germinal es angelismo. El «human augmented» es angelismo. La IA como prótesis cognitiva que fusiona tu mente con máquinas — es angelismo. Y el síntoma más revelador es siempre el mismo:

la creencia de que aceptar los propios límites es derrota.

El Ídolo Central: Lo Diseñable

Debajo de todo esto hay un ídolo. Es el ídolo más central, y merece ser nombrado claramente. Es el ídolo de lo diseñable como inevitabilidad. La creencia de que todo aquello que puede ser técnicamente intervenido debe poder serlo. Que la alternativa — aceptar algo como dado, recibir nuestras capacidades como un don en lugar de como un proyecto de ingeniería — es superstición. Es pasividad. Es conformismo.

Aquí es donde Michael Sandel, en The Case Against Perfection, ve la pérdida más honda. No es una pérdida de seguridad biológica. Es la pérdida de lo que él llama giftedness — la capacidad de recibir lo que somos como regalo, no como logro. Y cuando pierdes eso, pierdes algo que cuesta enormemente explicar hasta que lo ves desaparecer: pierdes la humildad, la gratitud, y lo más inquietante de todo, pierdes la capacidad de la solidaridad.

Porque si todo es diseño, entonces quien recibió menos no es un hermano con otra suerte. Es un defecto de fabricación.

Eso es lo que está en juego.

La Tesis de lo Que Viene

Este ídolo central — lo diseñable como inevitable — no está solo. Hay otros tres que lo acompañan, y juntos tejen una captura tan sofisticada que se presenta a sí misma como elevación. En los próximos posts vamos a nombrarlos. Vamos a ver cómo funcionan. Y vamos a hacer la pregunta que nadie hace en el discurso de la augmentación:

• ¿Cuándo es una fusión comunión, y cuándo es captura?
• Porque no toda síntesis es comunión. Algunas son captura disfrazada de elevación.

Y eso es lo que el angelismo moderno — con su guía genética y su promesa de optimización sin límites — en realidad es: captura. Una bella, seductora, irresistible captura.

Pero captura, al fin.

Próximo post: Los Ídolos de la Augmentación — Las tres ilusiones que cierran la trampa.