--- type: BCI asset_id: BCI-MercadoLibre-FURY-v01 version: v01 status: Operativo readiness: ⭐⭐⭐⭐☆ owner: Victor Heredia sherpa: Jay fecha_creacion: 2026-06-22 intellbank: IB-PO-Posta subbank: BC-PO-Research tipo: BCI — Brain Code Iniciativa (sub-instancia de BCE) empresa_padre: BCE-MercadoLibre-CognitionStack-v01 (pendiente) programa_padre: El Flywheel de Mercado Libre (commerce ↔ fintech ↔ logística) sujeto: FURY — Internal Developer Platform de Mercado Libre dominio: Platform engineering · sistemas distribuidos · observabilidad · cognición de entrega de software a escala analogía: BCI-UPS-ORION-v02 (ORION sistematiza al mejor conductor; FURY sistematiza al mejor ingeniero) corpus_base: - Platform Engineering — "Mercado Libre's Internal Developer Platform (FURY)" 2024 - Medium · Mercado Libre Tech — "From the monolith to the multicloud platform" - Medium · Mercado Libre Tech — "For devs, by devs: the Go toolkit" - Datadog Case Study — Mercado Libre observability at scale (100% uptime Black Friday) - AWS Case Study — Mercado Libre + Amazon Bedrock + Well-Architected - MELI Earnings / 8-K FY2025–2026 (inversión IA · $3.4B México · $10.9B Brasil) - Klover.ai — MercadoLibre AI Strategy (flywheel commerce/fintech) - Team Topologies (Skelton & Pais 2019) · Conway's Law · DORA / SRE (Google) --- # BRAIN CODE INICIATIVA — FURY · v01 ## Mercado Libre · Internal Developer Platform · 2015–presente **Tipo:** BCI — Brain Code de Iniciativa **Iniciativa:** FURY (Internal Developer Platform de Mercado Libre) **Empresa padre:** Mercado Libre (BCE-MercadoLibre-CognitionStack-v01 · pendiente) **Programa padre:** El Flywheel (commerce ↔ fintech ↔ logística) **Iniciado:** 2015 (nace FURY) → migración monolito→microservicios → multicloud → observabilidad embebida → IA encima **Estatus:** Operativo · 15,000 ingenieros · 30,000 microservicios · 100,000 instancias · v01 del Brain Code > **Analogía con ORION (BCI-UPS-ORION-v02).** ORION sistematizó el conocimiento tácito del **mejor conductor** y lo hizo disponible para los 60,000. FURY sistematiza el conocimiento tácito del **mejor ingeniero** —cómo se construye, despliega y observa un servicio correctamente— y lo hace el camino por defecto para los 15,000. ORION optimiza *una* operación física; FURY optimiza *la capacidad misma de construir operaciones*. Es la cognición de segundo orden de Mercado Libre: no un sistema inteligente, sino la fábrica que produce sistemas inteligentes. --- ## O1 — MAPA ONTOLÓGICO FURY parte de una observación que solo se vuelve visible al escalar: **el costo de coordinar ingenieros crece más rápido que el número de ingenieros.** Duplicar el equipo no duplica la producción — la divide entre la fricción de coordinación (Ley de Brooks). La trampa cognitiva es creer que ese costo se controla con *más proceso* (comités, gates de aprobación) — lo que frena a todos — o con *autonomía total* — lo que fragmenta la arquitectura en caos. **La trampa cognitiva que FURY resuelve:** El conocimiento de "cómo se hace bien un servicio" (cómo se despliega, se monitorea, se asegura, se escala) vive tácito en la cabeza de los mejores ingenieros. Es local (su squad), temporal (las buenas prácticas de hoy) y no transferible (se va con la persona). Sin sistematizarlo, cada nuevo equipo reinventa —mal— lo que el mejor equipo ya resolvió. FURY convierte ese conocimiento tácito en un **camino pavimentado** (paved road): la forma correcta de construir se vuelve la forma fácil y por defecto. **El hallazgo fundacional — el principio del "embebido por defecto":** La observabilidad, la seguridad y los estándares **no se agregan después** — nacen con la aplicación. Toda app creada en FURY incluye monitoreo desde el primer commit. Esto invierte la práctica común (construir primero, instrumentar cuando algo falla). El hallazgo: *lo que no está embebido al momento de crear, no se adopta a escala.* Igual que ORION descubrió que evitar giros izquierda (eliminar lo malo) supera a optimizar lo bueno, FURY descubrió que **embeber el estándar al nacer** supera a imponerlo por gobernanza. **El flywheel como sustrato:** Como commerce, fintech (Mercado Pago) y logística (Mercado Envíos) corren sobre la misma plataforma, los datos de uno alimentan a los otros en tiempo real (el historial de ventas del comerciante alimenta el underwriting de su crédito). FURY es la condición de posibilidad del flywheel: sin un sustrato común, no hay loop cerrado. --- ## MM — MODELOS MENTALES OPERATIVOS **MM-1: Plataforma como producto (los devs son los clientes)** FURY se construye "for devs, by devs": el equipo de plataforma trata a los 15,000 ingenieros como usuarios y al developer experience como métrica de producto. El modelo mental: la productividad interna es un producto que se diseña, mide y mejora — no un subproducto de contratar gente buena. **MM-2: Camino pavimentado / Golden Path** Existe una forma "bendecida" de hacer cada cosa (crear servicio, desplegar, observar, asegurar) que es self-service y está lista en minutos. La estandarización no se logra por mandato sino haciendo que **el camino correcto sea el más fácil**. Desviarse es posible, pero cuesta más — así la mayoría converge al estándar voluntariamente. **MM-3: Inversión (Inversion Thinking)** En vez de preguntar "¿cómo gobernamos a 15,000 ingenieros?", FURY pregunta "¿qué hace lento o riesgoso desplegar?" y lo elimina por diseño: automatiza el deploy, embebe la observabilidad, decopla los servicios. Como ORION elimina los giros malos, FURY elimina la fricción de entrega. **MM-4: Ley de Conway, invertida** La arquitectura de un sistema espeja la estructura de comunicación de la organización. Mercado Libre lo usa al revés (Inverse Conway Maneuver): **diseña la topología de equipos** (unidades autónomas, dueñas end-to-end) **para producir la arquitectura deseada** (microservicios independientes, deployables por separado). El organigrama es una decisión de arquitectura. **MM-5: Flywheel / compounding de datos** Cada pilar alimenta a los otros: commerce genera datos transaccionales → fintech los usa para crédito → logística los usa para predecir demanda → mejor servicio genera más commerce. El loop cerrado hace que cada vuelta sea más barata y más precisa que la anterior. La ventaja no es un dato; es el *loop*. **MM-6: Decoplamiento como optionalidad** Microservicios independientes = despliegues independientes = múltiples releases por día con radio de impacto pequeño. Cada decoplamiento compra una opción: poder cambiar una parte sin coordinar con el todo. La velocidad de Meli no es heroísmo, es arquitectura que permite equivocarse barato. **MM-7: Shift-left (embebido al nacer)** Calidad, seguridad y observabilidad se mueven al inicio del ciclo, no al final. El costo de un problema crece con cuán tarde se detecta; embeberlo al crear lo hace casi gratis. Es el "No-Left-Turns" de FURY: no optimices la corrección tardía, elimina la posibilidad de nacer sin instrumentar. --- ## SC — STACK DE CIENCIAS APLICADAS **SC-1: Platform Engineering / Internal Developer Platforms (disciplina fundacional)** FURY es una de las IDP más grandes del mundo. La disciplina: tratar la plataforma interna como producto con golden paths self-service que abstraen la complejidad de infraestructura para que el ingeniero de producto se enfoque en valor de negocio. **SC-2: Sistemas distribuidos / Arquitectura de microservicios** 30,000 microservicios sobre 100,000 instancias en multicloud. Conceptos aplicados: service discovery, contratos de API, idempotencia, circuit breakers, despliegue independiente, contención de fallas (bulkheads). El reto central: evitar el "monolito distribuido" (servicios que deben desplegarse juntos = peor de ambos mundos). **SC-3: Teoría de Observabilidad (los tres pilares)** Métricas, logs y trazas embebidos por defecto (vía Datadog en FURY). La observabilidad no es monitoreo (saber *que* algo falló) sino la capacidad de preguntar *por qué* falló sin desplegar código nuevo — condición para operar 30,000 servicios sin que nadie entienda el todo. Resultado verificado: 100% de uptime en Black Friday. **SC-4: Ley de Conway / Team Topologies (socio-técnico)** La arquitectura de software y la arquitectura organizacional son la misma cosa vista desde dos lados. Team Topologies (stream-aligned teams + platform team + enabling teams) describe exactamente el modelo Meli: squads de producto autónomos sobre una plataforma (FURY) operada por un platform team. **SC-5: Reliability Engineering (SRE)** SLAs, error budgets, "you build it, you run it". El error budget convierte la confiabilidad en una moneda: si gastas tu presupuesto de errores, frenas features y arreglas estabilidad. Alinea velocidad y confiabilidad sin un comité que decida caso por caso. **SC-6: Ciencia de datos / ML sobre el flywheel** Credit scoring de Mercado Pago a partir de datos transaccionales (underwriting más rápido que un banco tradicional), optimización de rutas de Mercado Envíos, recomendación, Mercado Ads 2.0 (bidding por IA). La IA se consume desde una capa fundacional externa (AWS Bedrock) y se aplica sobre el dato propietario del flywheel — *ahí* está el foso, no en el modelo. --- ## PT — PROCESO DE TRANSFORMACIÓN **Estado A — Antes de FURY (monolito, pre-2015):** Una base de código monolítica donde cada cambio requería coordinar con todos, los despliegues eran eventos riesgosos y poco frecuentes, y escalar el equipo aumentaba la fricción más que la producción. El conocimiento de "cómo desplegar bien" vivía en pocas cabezas. **Mecanismo de Transformación (2015–presente):** *Fase 1 (2015) — Nace FURY:* - Plataforma interna que estandariza crear/desplegar/monitorear una aplicación. - Golden path self-service: un servicio nuevo nace en minutos, ya instrumentado. *Fase 2 — Del monolito a los microservicios:* - Descomposición del monolito en servicios decoplados, deployables por separado. - Inverse Conway: squads autónomos dueños end-to-end de sus servicios. *Fase 3 — Multicloud y escala:* - FURY abstrae múltiples nubes; 30,000 microservicios sobre 100,000 instancias. - Observabilidad embebida por defecto (Datadog) en cada app desde su creación. *Fase 4 — IA sobre la plataforma:* - Capa de IA (Bedrock) sobre el dato del flywheel: credit scoring, rutas, Ads 2.0. - "AI teammates" y automatización agéntica como siguiente golden path. **Estado B — Después de FURY (presente):** 15,000 ingenieros despliegan múltiples veces al día sobre un camino pavimentado; cada nueva app nace observada, seasegura y escalable. El conocimiento del mejor ingeniero está embebido en la plataforma y mejora con cada servicio. La capacidad de construir dejó de depender de héroes individuales — se volvió un activo de la organización. --- ## RD — REGLAS DE DECISIÓN CANÓNICAS **RD-1 — Embeber al nacer, nunca agregar después:** Observabilidad, seguridad y estándares se incluyen en el momento de crear el servicio. Lo que no nace instrumentado, no se instrumenta a escala. **RD-2 — Self-service sobre ticket-and-wait:** La autonomía se da por plataforma (el ingeniero se sirve solo en minutos), no por aprobación (esperar a un equipo central). El default es "puedes hacerlo tú", no "pide permiso". **RD-3 — Decoplar para poder enviar:** Servicios pequeños, despliegues independientes, radio de impacto chico. Si dos servicios deben desplegarse juntos, es una señal de diseño roto (monolito distribuido). **RD-4 — Quien lo construye, lo opera (you build it, you run it):** El squad es dueño end-to-end de su servicio en producción. No hay un "equipo de operaciones" que herede el problema; la responsabilidad de operar retroalimenta la calidad de construir. **RD-5 — El dato fluye entre pilares por defecto:** Diseñar para que commerce, fintech y logística reutilicen datos en tiempo real. El valor compuesto del flywheel solo existe si el dato no queda atrapado en un silo. **RD-6 — Construir la plataforma, comprar la capa fundacional:** Lo diferenciador (la plataforma, el dato del flywheel) se construye in-house; lo commoditizado (modelos fundacionales de IA) se consume (Bedrock). No reinventar lo que no es foso. --- ## AP — ANTI-PATRONES **AP-1 — Gobernar la escala con proceso:** Agregar comités y gates de aprobación para "controlar" a 15,000 ingenieros frena a todos para disciplinar a pocos. El patrón correcto: caminos pavimentados que hacen lo correcto fácil, no obligatorio. **AP-2 — Autonomía total sin plataforma:** Dar libertad sin un golden path produce fragmentación: cada equipo elige su stack, nadie puede operar el todo. Es la tensión "libertad vs. orden" que Meli mismo reconoce; FURY es su resolución, no su ausencia. **AP-3 — Observabilidad como pensamiento tardío:** Instrumentar después de que algo falla pierde justo las fallas que importan. La observabilidad bolt-on es teatro; la embebida es capacidad. **AP-4 — El monolito distribuido:** Microservicios que deben desplegarse juntos: tienes el costo de coordinación del monolito y la complejidad operativa de lo distribuido. Peor de ambos mundos. **AP-5 — IA sobre datos fragmentados:** Aplicar IA antes de unificar el dato produce "dashboards bonitos sobre datos sucios". El flywheel exige primero el sustrato común — la misma lección que el benchmark de logística MX (integración antes de IA). **AP-6 — Copiar la plataforma sin la cultura:** FURY funciona por una cultura de colaboración, transparencia y confianza. Copiar el tooling sin cultivar la cultura reproduce la herramienta sin el resultado. La plataforma es socio-técnica, no solo técnica. --- ## TF — TENSIONES FUNDAMENTALES **TF-1 — Autonomía vs. Estandarización:** Demasiada autonomía fragmenta; demasiado estándar asfixia. FURY resuelve con el camino pavimentado: el estándar es el default fácil, la desviación es posible pero costosa. **TF-2 — Libertad vs. Orden a escala:** Meli reconoce explícitamente esta tensión. La plataforma es el mecanismo que permite libertad de producto sobre orden de infraestructura — sin que un humano arbitre cada caso. **TF-3 — Velocidad vs. Confiabilidad:** Desplegar múltiples veces al día maximiza velocidad pero arriesga estabilidad. El error budget (SRE) convierte el balance en una regla automática: si rompes confiabilidad, frenas features. **TF-4 — Plataforma central vs. Equipos descentralizados:** Una plataforma demasiado opinada limita a los squads; una demasiado laxa no estandariza. El platform team sirve a los stream-aligned teams como producto, no los gobierna. **TF-5 — Construir vs. Comprar:** Construir todo agota recursos; comprar todo cede el foso. La regla: construir la plataforma y el dato (diferenciadores), comprar los modelos fundacionales (commodity). --- ## ML-LOOP — MECANISMO DE APRENDIZAJE FURY/Meli aprende a través de **cuatro loops** de distinta escala temporal: **Loop 1 — Inmediato (por despliegue):** Múltiples despliegues diarios con observabilidad embebida = feedback en minutos. La frecuencia de despliegue *es* la tasa de aprendizaje: cuanto más seguido envías, más rápido aprendes qué funciona (métricas DORA). **Loop 2 — Operativo (por servicio):** Cada servicio en producción emite métricas/logs/trazas. El error budget convierte la confiabilidad en señal accionable: el gasto del presupuesto dicta si el squad acelera features o estabiliza. **Loop 3 — Plataforma (transversal):** El platform team observa cómo 15,000 ingenieros usan FURY y mejora los golden paths donde hay fricción. El uso de la plataforma retroalimenta el diseño de la plataforma. **Loop 4 — Flywheel (estratégico):** Commerce → fintech → logística → commerce. El dato de cada pilar mejora a los otros en tiempo real (ventas → crédito → demanda → servicio). Es el loop más lento y el más valioso: compone ventaja entre líneas de negocio. **Escala del aprendizaje:** - 15,000 ingenieros · 30,000 microservicios · 100,000 instancias. - Múltiples despliegues por día por squad → miles de experimentos productivos al día. - A esta escala, una mejora de 1% en el developer experience se multiplica por 15,000. --- ## FK — FRONTERA DEL CONOCIMIENTO **Pregunta abierta 1 — Agentes sobre la plataforma:** El siguiente golden path son los "AI teammates" / automatización agéntica (Mercado Ads 2.0 ya lo insinúa). La frontera: ¿pueden los agentes consumir FURY como lo hace un ingeniero, y desplegar servicios por sí mismos bajo gobernanza? **Pregunta abierta 2 — El flywheel hacia logística autónoma:** Mercado Envíos optimiza rutas y red gestionada hoy con humanos. La frontera es extender el flywheel a operación logística autónoma sin perder los SLAs comprometidos. **Pregunta abierta 3 — Foso de IA: construir vs. consumir:** Meli consume la capa fundacional (Bedrock). Si la ventaja migra del dato al modelo, ¿deberá construir capacidad fundacional propia (como Amazon) o basta el foso del dato del flywheel? **Pregunta abierta 4 — Gobernanza de IA grado-fintech:** Mercado Pago exige explicabilidad y auditoría (crédito, riesgo). La frontera: extender ese rigor de gobernanza (D4) a toda la IA agéntica de la plataforma — el límite que separa capacidad de inteligencia *desplegable* (la misma lección que hunde a Tesla a L4). --- ## SÍNTESIS — LO QUE FURY PRUEBA FURY demuestra que **la capacidad de construir es, en sí misma, sistematizable y componible.** ORION sistematizó al mejor conductor; FURY sistematiza al mejor ingeniero — y va un nivel más arriba: sistematiza la *fábrica* que produce sistemas. El conocimiento de cómo se construye bien no muere cuando el ingeniero renuncia: vive en el camino pavimentado y mejora con cada servicio que cualquier squad cree. La implicación más transferible: **la ventaja del líder no es un sistema optimizado, es la plataforma que le permite a toda la organización enviar inteligencia rápido y seguro.** No compras inteligencia organizacional; construyes el camino pavimentado que la produce en serie. **Para Posta y para EmpowerLabs/WORX:** un "FURY v0" no requiere 15,000 ingenieros. Requiere el mismo principio: un **camino pavimentado para la operación** — playbooks estándar + gobernanza embebida + self-service — sobre un dato unificado. Es exactamente la tesis WORX: el Sherpa + los IntelliBanks + la gobernanza embebida son el FURY de una organización de mensajería. Posta no necesita el músculo de Meli; necesita su *principio*: embeber el estándar al nacer, decoplar para enviar, y dejar que el dato fluya en un loop. Eso captura buena parte del compounding con una fracción de la escala. > **Por qué Meli puntúa ~51X (L5 borderline):** FURY explica D1 (decisión distribuida rápida), D3 (arquitectura de datos / flywheel) y D5 (workflows estandarizados). Su techo (no llegar a Amazon ~80X) es D2/D4: consume la capa fundacional de IA en vez de construirla, y su gobernanza de IA de frontera aún no iguala su gobernanza fintech. Ver `DC-PO-IBX-RefMercadoLibre-v01`. --- ## CHANGELOG | Versión | Fecha | Cambio | |---------|-------|--------| | v01 | 2026-06-22 | Creación. BCI de la iniciativa FURY (IDP de Mercado Libre) replicando la anatomía de BCI-UPS-ORION-v02 (O1 · MM · SC · PT · RD · AP · TF · ML-LOOP · FK · Síntesis). Analogía: ORION sistematiza al mejor conductor, FURY al mejor ingeniero / la capacidad de construir. Conectado al perfil DC-PO-IBX-RefMercadoLibre-v01 y al flywheel. | --- *BCI-MercadoLibre-FURY-v01 · IB-PO-Posta/BC-PO-Research/ · 2026-06-22* *Brain Code Iniciativa — Mercado Libre FURY · EmpowerLabs Brain OS*