Skill: TESSERA | Type: design Summary: EPISODIO 1 — MNEMO_PRE_DIGEST: Mi inclinación, y qué la cambiaría
2.7 KiB
| episode_id | puente_flat | session_code | acto_dialogico | actor_flujo | criticidad_aegis | skill_dominante | fase_proyecto | tipo_semantico | summary_one_line | source_type | trust_boundary | created_at | relectura_tagged | forgejo_commit_sha |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| a7c9ce68-6c69-4485-a157-730e4979bb0f | TRAZA_mi-inclinacin-y-qu-la-cambiara_S20260801.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD | S20260801.PIPELINE_FIXES | informar | multi_actor | low | TESSERA | operations | design | EPISODIO 1 — MNEMO_PRE_DIGEST: Mi inclinación, y qué la cambiaría | claude_code | internal | 2026-08-02T04:20:54.119576+00:00 | false | pending |
Mi inclinación, y qué la cambiaría
Curar primero. La razón es asimétrica: el re-embedding es reversible, barato y con éxito medible al día siguiente; la unificación es un cambio de arquitectura en la ruta por donde pasa toda tu memoria, y hacer cirugía estructural antes de recuperar el acceso es dejar al paciente sin memoria mientras se rediseña el quirófano. Además, con la sonda puesta, el riesgo de que la grieta se abra en el intervalo es visible en 24 horas.
Lo que me haría cambiar de opinión: si tienes previsto tocar el mapeo de LiteLLM en los próximos días por cualquier otro motivo —añadir un modelo, rotar una key, cambiar de proveedor—, entonces conviene unificar primero y re-embeber una sola vez al final.
La pregunta esencial
¿Hay algún cambio previsto en la configuración de LiteLLM o en las rutas de embedding próximamente? Si no lo hay, te preparo el plan de re-embedding con backup y lo ejecutamos; si lo hay, invertimos el orden.
📌 PILA (R20): ❓ orden curar-vs-blindar (esperando tu respuesta) · 🟠 deuda estructural: dos rutas de embedding que coinciden por casualidad · 🟡 config LiteLLM sin política de backup · ✅ causa de la causa documentada y en 3 remotos · ✅ sonda viva midiendo.
¡Listo, John! Te entregué el documento completo → MODELOS_CONEXION_IA_Y_PERCIA_S20260801.md (ya en tu panel). Sigue fuera del repo EMBER, como mandaste.
Lo esencial de las dos preguntas
Tu intuición es correcta y es la clave de todo: conectar IAs tiene capas, como una torta de red. MCP es el cable (capa 2, modelo↔herramienta), A2A es el cable entre agentes (capa 3), y PERCIA aspira a quién manda y quién deja registro (capas 4-5, gobernanza). No compiten — se apilan. "MCP como conector + PERCIA como protocolo" es exactamente la combinación sana.