Kernel IA Orgánica · Pipeline Cognitivo

Orquestador V7.3

El cerebro que decide qué hacer antes de que nadie piense. Cuando alguien escribe "muéstrame los correos de ayer", el orquestador clasifica la intención en 53ms, encuentra el dominio correcto, rellena parámetros desde memoria, valida contra políticas de seguridad y ejecuta. Y cada día lo hace más rápido, porque aprende.

El kernel invisible

El orquestador es el pegamento universal entre el usuario y todos los sistemas. No es una IA que responde — es la IA que decide quien responde, cómo y con qué datos. Conecta correo, expedientes, excel, ficheros, APIs externas y modelos LLM locales en un solo pipeline.

Lo más importante: No necesita qué le digan que hacer. Entiende lenguaje natural, clasifica la intención y actua. Si no sabe, pregunta. Si falla, aprende. Si aprende, la próxima vez es gratis.

◆

Entiende

Clasifica intenciónes en 50-200ms usando LLM local de 3B en GPU dedicada. Cache inteligente: la segunda vez es 0ms.

◇

Decide

7 niveles de resolución, del más barato al más caro. Solo usa LLM si todo lo demás falla. El 90% se resuelve sin coste.

◈

Aprende

Cada decisión alimenta el learning loop. Un curador humano aprueba. Mes a mes, el coste baja. Lo que hoy cuesta 200ms, mañana cuesta 0.

◉

Protege

Circuit breaker, validación de acciónes, idempotencia, whitelist estricta. Nunca ejecuta algo que no debería.

Dentro del ecosistema IA Organica

Cuando...	Entonces...
Un usuario habla	Orquestador V7.3 entiende qué quiere
Necesita clasificar	Q4K (gpu3) clasifica la intención en 50ms
Necesita responder	LLM Central (gpu1) genera con contexto del usuario
Necesita ejecutar	Los Brazos actuan en IMAP, expedientes, excel...
Termina	LearningCore registra para mejorar mañana

11 Cores activos

7 Niveles intent

6 Capas memoria

135ms E2E CHAT

16ms Con cache

Qué es el Orquestador

El orquestador es el punto único de entrada para todas las peticiones de IA. No ejecuta, decide. Recibe lenguaje natural o acciones explícitas, las clasifica, valida, enriquece con memoria, y las dirige al recurso correcto: un brazo (IMAP, expedientes), un LLM (chat, código), o un admin (configuración).

Principios de diseño

Principio	Implementacion
Coste progresivo	7 niveles de resolución, del gratis al caro. Solo usa LLM si lo anterior falla.
Brazos NO reciben prompt	El kernel exige `ox.accion` explicita. Ningun brazo adivina intención.
Aprendizaje continuo	Cada decisión alimenta el learning loop. El sistema mejora sin reprogramar.
Guardrails first	Validación de acciones, circuit breaker, idempotencia. Nunca ejecuta sin verificar.
Memoria contextual	6 capas de memoria (2ms). Conoce al usuario, su proyecto, sus preferencias.
Zero vendor lock-in	100% local. GPU propia. Sin API keys externas. Sin coste por request.

Por qué baja el coste cada día

El modelo de amortización

Sin orquestador V7

▸ Cada peticion llama a un LLM (~500ms)
▸ Coste constante: nunca baja
▸ Cada brazo interpreta el prompt a su manera
▸ Sin memoria: el usuario repite todo cada vez
▸ Sin aprendizaje: los mismos errores siempre

Con Orquestador V7.3

▸ Solo usa LLM cuando falla todo lo demas
▸ Coste decreciente: aprende y amortiza
▸ Un solo formato: ox.accion
▸ Memoria: conoce al usuario, su proyecto, su alias
▸ Learning loop: nunca repite el mismo error

Curva de amortización medida

Periodo	% Q4K (LLM)	% Determinista	Latencia media	Coste GPU
Semana 1	80%	20%	~100ms	Alto
Mes 1	40%	60%	~50ms	Medio
Mes 3	15%	85%	~15ms	Bajo
Mes 6	5%	95%	~5ms	Casi cero

Clave: Q4K no desaparece — pasa de resolver a enseñar. Cada resolución exitosa alimenta el etiquetador/policy. La próxima vez, ese patron se resuelve en capa determinista (0ms, 0 coste).

Pipeline completo de una request

Pipeline V7.3 — "muéstrame los correos de ayer"

ChatIA
→A. Normalize
→B. Memory (2ms)
→C. Intent (53ms)
→D. Guardrails
→E. Dispatch
→F. Learning

Los 6 pasos del pipeline

Paso A — Normalize

Normaliza app_in a app_norm. Extrae prompt_eff. Construye OrqContext. Verifica idempotencia por trace_id.

Paso B — Memory (2ms)

Carga perfil profesional, preferencias UI, memoria estable, semántica, usuario e IA. Rellena slots conocidos antes de tocar Q4K.

Paso C — Intent (53ms)

Resuelve acción usando coste progresivo: alias → etiquetador → policy → memory → Q4K → GPU1 → fallback.

Paso D — Guardrails

Valida acción contra whitelist de policy. Circuit breaker por recurso. Si acción invalida → ASK canónico o fallback.

Paso E — Dispatch

Si route_to_llm=true (CHAT/CODIGO) → call_llm a GPU1/GPU2. Si brazo fisico → dispatch_brazo a IMAP, expedientes, etc.

Paso F — Post-hooks

LearningCore detecta eventos (error, fallback, baja confianza). TemplateCore aplica UI defaults. PersistenceCore guarda en ledger.

Cores del kernel

◆ IntentCore

Resuelve intención en 7 prioridades. Conecta con Q4K (gpu3) y LLM Central (gpu1).

Produccion V7.3

◇ MemoryCore

6 capas de contexto: perfil, prefs, estable, semántica, usuario, IA. 2ms load.

Produccion V7.2

◈ PolicyCore

Lee orq_domains_policy. Provee thresholds, intent_map, actions_allow, default_action.

Produccion · 7 domains

◉ Guardrails

Validate action, circuit breaker, idempotencia, ASK canónico, learning events.

Produccion V7.3

▣ LearningCore

Detecta eventos (error, fallback, invalid_action). Encola para curación.

Emitiendo · Sin UI curación

▤ TemplateCore

Aplica UI defaults por domain/usuario. Templates heredables.

Basico · Sin seed DB

▥ ParamRulesCore

Valida y transforma parámetros antes del dispatch segun policy thresholds.

Produccion

▦ PersistenceCore

Ledger-grade: orq_decisións, orq_learning_queue, orq_trazas, orq_callbacks.

Produccion

▧ AdminCore

Handler orq.* actions: memory.context.load, policy.get, learning.queue.

Produccion V7.2

MemoryCore — 6 capas de contexto

Capa	Tabla	Contenido	Ejemplo
0 Perfil	perfil_activo + perfil_personal + perfil_proyecto + perfil_integraciones	Quien es, qué hace, en qué trabaja	"Arquitecto IA, 15 años, Python/Docker"
1 UI Prefs	orq_ui_preferences	Preferencias de interfaz	tema=dark, idioma=es
2 Estable	orq_memoria_estable	Hechos permanentes	"Sprint actual: V7.3 guardrails"
3 Semántica	orq_memoria_semántica	Patrones reutilizables	prompt→domain→acción exitosos
4 Usuario	memoria_usuario	Slots del usuario	ultimo_uid, ultimo_expediente
5 IA	memoria_ia	Resumenes generados	"Resumen semana: deploy V7.2"

Capa 0 (Perfiles) genera un prompt_block que se inyecta en las llamadas a LLM Central. Cuando el usuario pregunta "qué avances hemos hecho", gpu1 ya sabe quesin qué el us es un arquitecto IA trabajando en iacombinada con stack Python/FastAPI/Docker. La respuesta es personalizada sin que el usuario repita nada.

IntentCore — 7 prioridades de resolución

Coste progresivo: cada nivel es más caro que el anterior. El sistema siempre intenta resolver al menor coste posible.

Alias explícito — ox.acción = "imap.list_unread"
0ms · Coste 0 · Confidence 1.0 · Source: explicit

Etiquetador (regex/tags) — "muestrame los correos" → acción:imap.list_unread
0ms · Coste 0 · Confidence 0.8-0.9 · Source: etiquetador

Policy default_action — Si el domain tiene default_action configurado
0ms · Coste 0 · Confidence 0.5 · Source: policy_default

Memoria semántica — Ultimo patron exitoso para ese domain
0ms · Coste 0 · Confidence 0.4 · Source: memory

Q4K tag:intent (gpu3) — Qwen2.5-3B clasifica → categoría → CATEGORY_MAP → domain+acción
50-200ms · Coste ~0 (local) · Confidence 0.65 · Source: q4k_v3 · Cache 1h

LLM Central (gpu1) — Solo para domains criticos. Supervisor que analiza con más cuidado
500-1500ms · Coste bajo (local) · Confidence 0.5 · Source: gpu1_supervisor

Fallback — Si prompt existe sin domain → CHAT (gpu1 responde). Si no → missing_action
Source: fallback_chat

Mapping categorías Q4K → Domains

Categoría V3	Domain	Default Action	Routing
CORREO	correo.imap	imap.list_unread	Brazo ACA
EXPEDIENTES	expedientes	exp.list	Brazo ACA
EXCEL	excel	excel.list	Brazo ACA
FICHEROS	gestor_ficheros	gf.list	Brazo ACA
CODIGO	_llm_specialist	_llm_generate	GPU2 tag:code
CHAT	_llm_central	_llm_generate	GPU1 tag:chat
ADMIN	orq.admin	orq.memory.context.load	AdminCore

Guardrails P0

Guardrail	Proteccion	Implementacion
P0 #1 — Anti-hallucination	Q4K devuelve acción qué no existe	`validate_action()` contra whitelist de policy. Case-insensitive exacto, sin fuzzy.
P0 #2 — Idempotencia	Retries duplican decisiónes	`check_idempotent(trace_id)` retorna cached si `kpis_snapshot.done=true`.
P0 #3 — Circuit breaker	Endpoint lento bloquea workers	Contador en memoria por recurso. 3 fallós en 60s → circuito abierto 30s.
P0 #4 — ASK canónico	Cada brazo pide info diferente	`build_ask_response()` formato único: `payload.tipo="ask"`, `questions[]`, `ask_reason`.
P0 #5 — Learning events	Errores sin registrar	5 eventos obligatorios: error_dispatch, fallback, low_confidence, invalid_action, need_clarification.

Cómo aprende el orquestador

Learning Loop completo

Q4K resuelve
→Learning detecta
→Cola curación
→Curador aprueba
→LearningApplier
→Policy/Etiquetador absorben

Tipos de evento que generan aprendizaje

Evento	Cuando	Se aplica en
`q4k_resolved`	Q4K clasificó exitosamente	intent_map (capa 3) o patrón etiquetador (capa 2)
`error_dispatch`	Brazo falló	Revisar brazo/timeout/circuit breaker
`invalid_action`	Q4K devolvió acción no valida	Corregir whitelist de policy
`fallback_default_action`	Ningún nivel resolvió	Añadir mapping a intent_map
`need_clarification`	Se emitió ASK al usuario	Revisar ask_schema del domain

Por qué se puede borrar

Todo el aprendizaje es aditivo y reversible. El learning no modifica código — solo añade entries a tablas SQL: orq_learning_queue (pendientes), orq_domains_policy.intent_map (aprobados), patrones en etiquetador. Si algo sale mal:

DELETE FROM orq_learning_queue WHERE domain='X' → borra aprendizaje pendiente
Editar intent_map en policy → quitar mapping incorrecto
El sistema vuelve a usar Q4K para esos casos → como si nunca hubiera aprendido

No hay pesos de red, no hay fine-tuning, no hay modelo re-entrenado. Es SQL puro. Borrar un aprendizaje es un DELETE. El peor caso es volver a la semana 1 (Q4K resuelve todo), que ya funciona.

Mapa de recursos GPU

◆ gpu3 — A2000

6 GB VRAM · Qwen2.5-3B Q4 · Intent classifier

Autoboot · Siempre ON
tag:intent · 37-210ms

◇ gpu1 — RTX 5090

32 GB VRAM · Qwen3-30B / Yi-9B · Central

Chat, factories, supervisor
tag:chat · ~100-600ms

◈ gpu2 — RTX 3090

24 GB VRAM · DeepSeek-Coder / Yi-9B · Especialista

Código, análisis, code review
tag:code

Orquestación inteligente

El Orquestador es el cerebro que coordina toda la arquitectura IA Orgánica. Clasifica, decide, ejecuta y aprende. Cada día más rápido, cada día más inteligente.

Ver IA Orgánica Completa