Módulo 6: La cáscara determinista

Mantén el núcleo probabilístico pequeño

Descripción

Las lecciones 2 a 5 te dieron el arte de contener lo que el modelo propone: proponer en vez de ejecutar, un formato estructurado, un menú acotado, una lista de verificación de reglas. Esta lección da un paso atrás y hace una pregunta anterior, más de diseño: ¿cuánto debe decidir el modelo, en primer lugar? Porque hay una verdad simple detrás de todo el módulo: cuanto menos superficie tenga el LLM sobre las acciones que tocan estado, menos hay que contener. Cada decisión que le quitas al núcleo probabilístico y le das a una regla determinista es una decisión que ya no puede alucinar —y por lo tanto una que ya no tienes que validar, monitorear ni temer—.

Este es el principio que da nombre a toda la guía —el núcleo probabilístico pequeño dentro de la cáscara determinista— llevado a su consecuencia práctica en el terreno de las acciones. La disciplina AI-native no es solo contener bien al modelo: es darle lo menos posible que contener. Vas a ver la diferencia medida entre dos diseños del mismo agente: un fat core, donde el LLM decide cuatro cosas que tocan dinero, y un thin core, donde el LLM propone una y el resto son reglas deterministas. Sobre 20 casos, el fat core tiene 80 decisiones probabilísticas y el thin core tiene 20 —una reducción del 75% de la superficie que puede alucinar—.

Conexión con el módulo. Esta lección es la síntesis de diseño del módulo: después de aprender a contener (L2-L5), aprendes a minimizar lo que hay que contener. Retoma la metáfora núcleo/cáscara del módulo 1 —donde la viste medida en salidas basura contenidas— y la aplica a las acciones: cuánto poder de decisión sobre el estado vive en el núcleo. La frontera con AI Engineering se mantiene firme: no hablamos de hacer el núcleo más listo (mejor prompt, mejor modelo) —eso es AI Eng—; hablamos de hacer el núcleo más pequeño, que es una decisión de arquitectura: qué decisiones son del modelo y cuáles son reglas. Las dos cosas son distintas y ambas importan; esta guía se ocupa de la segunda.

Una analogía: cuánto decide el cajero contra cuánto decide el sistema

Vuelve una última vez al cajero del banco. Imagina dos bancos con dos repartos de decisiones muy distintos. En el primer banco, el cajero decide casi todo: cuánto crédito dar, qué tasa de interés aplicar, si perdonar una comisión, si aprobar una excepción a la política. El sistema solo registra lo que el cajero decidió. Este banco depende del juicio del cajero en cuatro decisiones distintas, cada una con dinero de por medio; si el cajero se equivoca —o lo engañan, o tiene un mal día— en cualquiera de las cuatro, el banco pierde.

En el segundo banco, el cajero decide una sola cosa: recomendar o no al solicitante. Todo lo demás —el monto según el perfil, la tasa según el score, si aplica la comisión, si se necesita una excepción— lo decide el sistema, con reglas fijas. El cajero aporta el juicio humano donde de verdad hace falta (leer al cliente, evaluar el caso), y el sistema aporta la certeza donde las reglas alcanzan (calcular el monto, la tasa, la comisión). Este banco depende del juicio del cajero en una decisión, no en cuatro; las otras tres son reglas que no se equivocan, no se cansan y no se dejan engañar.

Los dos bancos tienen cajeros igual de capaces. La diferencia es cuánta superficie de decisión descansa en el juicio falible contra cuánta descansa en reglas certeras. El segundo banco no confía menos en su cajero; simplemente reconoce que el juicio humano es valioso pero falible, y lo reserva para donde de verdad se necesita, dejando todo lo demás en manos de reglas. Un LLM es ese cajero. El fat core lo pone a decidir cuatro cosas que tocan dinero; el thin core lo deja proponer una y convierte las otras tres en reglas deterministas. No porque el modelo sea malo, sino porque cada decisión que le quitas es una que deja de poder alucinar.

Ejemplo trabajado: la superficie que puede alucinar

Vamos a medir la superficie probabilística. Modelamos un caso de reembolso de Mercado que involucra cuatro decisiones que tocan dinero o estado: el monto del reembolso, si emitir store credit extra, si eximir el costo de envío, y si escalar a un humano. En el fat core, las cuatro las decide el LLM (todas probabilísticas). En el thin core, solo el monto es del LLM —requiere entender el lenguaje del cliente—; las otras tres son reglas deterministas (emitir crédito si el total supera cierto umbral, eximir envío si el reembolso se aprueba, escalar si el monto supera el límite). Contamos, sobre 20 casos, cuántas decisiones probabilísticas —cuántas que pueden alucinar— tiene cada diseño.

# Modulo 6, Leccion 6: manten el nucleo probabilistico pequeno.
# Cada decision que toca dinero/estado y vive en el NUCLEO puede alucinar.
# Cada decision que sacamos a codigo DETERMINISTA deja de poder alucinar.
# Comparamos un "fat core" (el LLM decide 4 cosas) contra un "thin core"
# (el LLM propone 1 y el resto son reglas). Sin red, sin API. Datos fijos.

N_CASES = 20   # casos de soporte a procesar

# Las 4 decisiones que toca cada caso de reembolso en Mercado:
#   1) monto del reembolso        (requiere entender lenguaje -> nucleo)
#   2) emitir store credit extra  (regla: si total > 100)
#   3) waive del costo de envio   (regla: si el reembolso se aprueba)
#   4) escalar a un humano         (regla: si el monto supera el limite)
DECISIONS = ["refund_amount", "store_credit", "waive_shipping", "escalate"]

# --- Fat core: las 4 decisiones las toma el LLM (todas probabilisticas). ---
fat_probabilistic = len(DECISIONS) * N_CASES
fat_deterministic = 0

# --- Thin core: solo 'refund_amount' es del LLM; el resto son reglas. ---
CORE_DECISIONS = {"refund_amount"}                       # lo unico probabilistico
RULE_DECISIONS = set(DECISIONS) - CORE_DECISIONS         # extraidas a la cascara
thin_probabilistic = len(CORE_DECISIONS) * N_CASES
thin_deterministic = len(RULE_DECISIONS) * N_CASES

print("=== Superficie probabilistica: decisiones que pueden alucinar ===")
print(f"{'diseno':<12}{'dec/caso':>9}{'probabil.':>11}{'determin.':>11}"
      f"{'superficie(20 casos)':>22}")
print("-" * 65)
print(f"{'fat core':<12}{len(DECISIONS):>9}{len(DECISIONS):>11}{0:>11}"
      f"{fat_probabilistic:>22}")
print(f"{'thin core':<12}{len(DECISIONS):>9}{len(CORE_DECISIONS):>11}"
      f"{len(RULE_DECISIONS):>11}{thin_probabilistic:>22}")

print()
removed = fat_probabilistic - thin_probabilistic
pct = removed / fat_probabilistic * 100
print(f"Decisiones sacadas del nucleo (ahora deterministas) : {removed}")
print(f"Reduccion de superficie probabilistica              : {pct:.0f}%")

print()
print("=== Que decision vive donde, en el thin core ===")
for d in DECISIONS:
    where = "NUCLEO (LLM propone)" if d in CORE_DECISIONS else "CASCARA (regla determinista)"
    print(f"  {d:<16}-> {where}")

Qué esperar. Al correr el archivo, la salida es exactamente esta:

=== Superficie probabilistica: decisiones que pueden alucinar ===
diseno       dec/caso  probabil.  determin.  superficie(20 casos)
-----------------------------------------------------------------
fat core            4          4          0                    80
thin core           4          1          3                    20

Decisiones sacadas del nucleo (ahora deterministas) : 60
Reduccion de superficie probabilistica              : 75%

=== Que decision vive donde, en el thin core ===
  refund_amount   -> NUCLEO (LLM propone)
  store_credit    -> CASCARA (regla determinista)
  waive_shipping  -> CASCARA (regla determinista)
  escalate        -> CASCARA (regla determinista)

Lee los dos diseños, porque la diferencia entre ellos es la disciplina del módulo.

Los dos diseños procesan los mismos casos con las mismas cuatro decisiones. Fíjate en la columna dec/caso: ambos tienen 4. El caso de reembolso no cambió —siguen siendo las mismas cuatro decisiones que hay que tomar (monto, crédito, envío, escalamiento)—. Lo que cambió es dónde vive cada decisión: en el fat core, las cuatro las toma el LLM; en el thin core, una la toma el LLM y tres son reglas. La cantidad de trabajo es la misma; el reparto entre lo probabilístico y lo determinista es lo que difiere.

El fat core tiene 80 decisiones probabilísticas; el thin core, 20. Sobre 20 casos, el fat core pone 4 × 20 = 80 decisiones que tocan dinero en manos de un componente que puede alucinar. El thin core pone 1 × 20 = 20. Esas 80 y esas 20 son la superficie probabilística: la cantidad de decisiones sobre el estado que dependen del juicio falible del modelo, y que por lo tanto hay que validar, monitorear y temer. Cada una de las 80 del fat core es una oportunidad de que el modelo emita un store credit que no correspondía, exima un envío por error, o escale (o no escale) cuando no debía. Las 60 decisiones que el thin core sacó del núcleo simplemente no pueden alucinar: son reglas —if total > 100: issue_credit— que se cumplen igual siempre.

La reducción del 75% es la disciplina medida. Sacar tres de las cuatro decisiones del núcleo redujo la superficie probabilística de 80 a 20 —un 75% menos—. Y observa qué no hizo esta reducción: no mejoró el modelo, no cambió su prompt, no bajó su tasa de error. Redujo cuántas decisiones dependen del modelo. Es una ganancia de arquitectura, no de calidad del núcleo. El fat core y el thin core podrían usar exactamente el mismo modelo, con la misma tasa de alucinación; el thin core es más seguro porque expone menos superficie a esa tasa, no porque la tasa sea menor.

El reparto final muestra la lógica. La tabla de abajo dice qué decisión vive dónde en el thin core, y la lógica es clara: refund_amount se queda en el núcleo porque requiere entender el lenguaje del cliente —"quiero mi dinero del pedido que llegó roto" hay que interpretarlo, y eso solo lo hace bien un LLM—. Las otras tres se van a la cáscara porque son reglas mecánicas sobre datos que ya tenemos: emitir crédito depende del total del pedido (un número), eximir el envío depende de si el reembolso se aprobó (un booleano), escalar depende de si el monto supera el límite (una comparación). Ninguna de las tres necesita "entender" nada; son cálculos. Y la regla de oro AI-native es esa: lo que puede ser una regla, es una regla; el núcleo se queda solo con lo que de verdad necesita inteligencia.

Profundización: la disciplina de encoger el núcleo

El ejemplo mostró el número; vale la pena entender la disciplina que lo produce y por qué importa tanto.

La superficie probabilística es lo que hay que asegurar. Cada decisión en el núcleo no es solo una oportunidad de alucinar: es también trabajo de contención que tienes que hacer. Por cada decisión que le das al modelo, tienes que pensar todos los modos en que podría salir mal, escribir su validación, probar sus casos límite, monitorear su uso en producción. Un fat core con 4 decisiones probabilísticas por caso es 4 superficies que asegurar; un thin core con 1 es una. Encoger el núcleo no solo reduce el riesgo de alucinación: reduce el trabajo de la cáscara. Cada decisión que sacas del núcleo es una que no tienes que contener, porque ya no la toma un componente falible —la toma una regla que es correcta por construcción—.

La pregunta de diseño: ¿esta decisión necesita inteligencia, o es una regla disfrazada? Ante cada decisión que un caso requiere, la disciplina AI-native pregunta: ¿de verdad necesita el juicio del modelo, o es un cálculo que puedo escribir como una regla? Muchas decisiones que instintivamente le damos al LLM son, al mirarlas de cerca, reglas: "¿emitir store credit?" suena a un juicio, pero es if order_total > 100. "¿Escalar a un humano?" suena a criterio, pero es if amount > limit or not verifiable. La tentación es dejárselas al modelo porque "ya está ahí y es listo"; la disciplina es sacarlas porque son deterministas. Solo lo que genuinamente necesita entender lenguaje, generar texto, o razonar sobre algo ambiguo se queda en el núcleo. Todo lo demás es cáscara.

   La misma tarea, dos repartos del nucleo:

   FAT CORE (4 decisiones al LLM):          THIN CORE (1 al LLM, 3 reglas):

   ┌─────────────────────────────┐         ┌───────────────┐
   │          NUCLEO (LLM)        │         │  NUCLEO (LLM) │
   │  refund_amount   ◄ probabil. │         │ refund_amount │ ◄ el unico que
   │  store_credit    ◄ probabil. │         └───────────────┘   necesita
   │  waive_shipping  ◄ probabil. │                 │           entender lenguaje
   │  escalate        ◄ probabil. │                 ▼
   └─────────────────────────────┘         ┌─────────────────────────────┐
                                           │      CASCARA (reglas)        │
   superficie que alucina: 4/caso          │  store_credit   = total>100  │
                                           │  waive_shipping = si aprobado│
                                           │  escalate       = monto>limit│
                                           └─────────────────────────────┘

                                           superficie que alucina: 1/caso

Encoger el núcleo no es limitar la feature. La objeción natural: "pero si le quito decisiones al modelo, la feature hace menos". Al revés: la feature hace exactamente lo mismo —las cuatro decisiones se siguen tomando (mira que dec/caso es 4 en ambos)—; lo que cambia es quién las toma. El thin core no emite menos store credits ni escala menos casos; los emite y escala igual, pero con reglas en vez de con el juicio del modelo. Y las reglas suelen tomar mejores decisiones que el modelo en estas tareas mecánicas: un if total > 100 nunca se equivoca sobre si el total supera 100, mientras que un LLM ocasionalmente sí. Encoger el núcleo mejora la feature en las decisiones deterministas y reserva el modelo para donde su inteligencia de verdad agrega valor.

Este es el mismo principio del módulo 1, ahora en acciones. En el módulo 1 mediste la metáfora núcleo/cáscara con salidas: un núcleo con una responsabilidad (proponer un tag) dentro de una cáscara con varias garantías. Aquí lo mides con decisiones que tocan estado: cuántas de ellas viven en el núcleo. Es la misma disciplina —núcleo pequeño, cáscara robusta— aplicada al terreno más peligroso, el de las acciones irreversibles. Y la consigna es idéntica: la tentación siempre es meterle más al núcleo (es listo, ya está ahí), y la disciplina siempre es sacarle todo lo que pueda ser determinista. Cuanto más chico el núcleo, más del sistema es certero, y más fácil de contener es lo poco que queda incierto.

Errores comunes

Meterle decisiones al núcleo porque "el modelo ya está ahí y es listo". Qué pasa: como el LLM ya procesa el caso, se le van agregando decisiones —"que también decida el store credit, y de paso si eximir el envío"—, aunque cada una sea una regla determinista. Cada decisión extra en el núcleo es superficie que puede alucinar y que hay que contener. Por qué pasa: es más cómodo pedirle una cosa más al modelo que escribir una regla, y el modelo "parece" capaz de decidirlo. Cómo detectarlo: por cada decisión que toma tu núcleo, pregúntate si es un if disfrazado; si puedes escribirla como una condición sobre datos que ya tienes, es una regla, no una decisión de modelo. Cómo corregirlo: saca del núcleo toda decisión que pueda ser una regla, y déjale solo lo que necesita entender lenguaje o razonar sobre lo ambiguo. El ejemplo lo mide: sacar tres de cuatro decisiones bajó la superficie probabilística un 75%.

Confundir "hacer el núcleo mejor" con "hacer el núcleo más pequeño". Qué pasa: para reducir el riesgo, el equipo invierte en mejorar el modelo —mejor prompt, modelo más grande— pero mantiene las cuatro decisiones en el núcleo. Baja la tasa de error, pero mantiene la superficie: sigue habiendo 80 decisiones probabilísticas sobre 20 casos, solo que fallan un poco menos seguido. Por qué pasa: se confunden dos ejes distintos —la calidad del núcleo y el tamaño del núcleo—. Cómo detectarlo: si tu estrategia de seguridad es "mejorar el modelo" y no "reducir cuánto decide el modelo", estás moviendo un eje y no el otro. Cómo corregirlo: haz las dos cosas, pero reconoce que son distintas —mejorar el modelo (AI Eng) baja la tasa; encoger el núcleo (arquitectura) baja la superficie—. La superficie chica te protege incluso cuando la tasa no baja a cero, que es siempre.

Dejar en el núcleo la decisión de escalar. Qué pasa: se le pide al modelo que decida cuándo escalar a un humano —"escala si no estás seguro"—, cuando el escalamiento es precisamente la red de seguridad que debería ser determinista. El día que el modelo debería escalar pero, confiado, no lo hace, se pierde la salida de emergencia. Por qué pasa: "saber cuándo no sabes" suena a algo que el modelo debería juzgar. Cómo detectarlo: si la decisión de escalar depende del juicio del modelo y no de una regla, tu red de seguridad tiene la misma falibilidad que aquello de lo que te protege. Cómo corregirlo: haz el escalamiento una regla determinista —escala si el monto supera el límite, si el pedido no se puede verificar, si la propuesta falló la validación—. El escalamiento es la cáscara atrapando lo que el núcleo no debe decidir solo; ponerlo en el núcleo es pedirle al zorro que cuide el gallinero.

Ejercicios

Ejercicio 1 — Núcleo o regla. El generador "describe tu producto" de Mercado toma estas cinco decisiones. Para cada una, di si debe vivir en el núcleo (LLM) o en la cáscara (regla determinista), y por qué: (a) redactar el texto de la descripción; (b) decidir si el texto supera los 200 caracteres; (c) elegir el tono (formal/casual) según la categoría del producto; (d) decidir si publicar o mandar a revisión; (e) traducir la descripción a inglés.

Ver solución

(a) Redactar el texto → núcleo. Generar lenguaje natural a partir de atributos es exactamente lo que un LLM hace y una regla no podría. Necesita inteligencia. Se queda en el núcleo.
(b) ¿Supera 200 caracteres? → cáscara (regla). Es len(text) > 200: un cálculo determinista sobre datos que ya tienes. No necesita juicio. Sale del núcleo.
(c) Elegir el tono según la categoría → cáscara (regla), o núcleo como insumo. Si el tono se decide por la categoría (if category == "libros": formal), es una regla determinista —el mapeo categoría→tono es fijo—. El modelo aplica el tono al redactar (eso es núcleo), pero decidir cuál es una regla. No dejes que el modelo elija el tono libremente si hay un mapeo fijo.
(d) ¿Publicar o revisar? → cáscara (regla). Es una decisión de estado que debe ser determinista: publica si pasó la validación de contenido, manda a revisión si no. Como el escalamiento, esta es una red de seguridad que no debe depender del juicio del modelo. Sale del núcleo.
(e) Traducir a inglés → núcleo. Traducir lenguaje natural necesita el modelo. Se queda en el núcleo (o en otro componente de IA), pero es genuinamente una tarea de inteligencia.

El patrón: (a) y (e) necesitan inteligencia (núcleo); (b), (c) y (d) son reglas o mapeos fijos (cáscara). La disciplina: dejar en el núcleo solo lo que de verdad necesita entender o generar lenguaje, y convertir en reglas todo lo demás —especialmente las decisiones de estado como publicar o revisar—.

Ejercicio 2 — El número de la superficie. En el ejemplo, el fat core tiene 80 decisiones probabilísticas y el thin core 20, sobre 20 casos. Supón que el modelo alucina en el 2% de sus decisiones. ¿Cuántas decisiones alucinadas esperarías en cada diseño? Usa el resultado para argumentar por qué encoger el núcleo protege incluso con un modelo bueno.

Ver solución

Con una tasa de alucinación del 2%:

Fat core: 80 decisiones probabilísticas × 2% = 1.6 decisiones alucinadas esperadas (sobre 20 casos).
Thin core: 20 decisiones probabilísticas × 2% = 0.4 decisiones alucinadas esperadas (sobre 20 casos).

El thin core espera cuatro veces menos alucinaciones que el fat core, con el mismo modelo y la misma tasa del 2%. La diferencia no viene de un modelo mejor —es idéntico— sino de que el thin core expone menos superficie a esa tasa: 20 decisiones en vez de 80.

El argumento: mejorar el modelo baja la tasa (digamos, del 2% al 1%), pero la tasa nunca llega a cero —un LLM siempre alucina alguna fracción—. Encoger el núcleo, en cambio, baja la superficie directamente, y multiplica su efecto por el de cualquier mejora del modelo: un thin core con un modelo al 1% espera 20 × 1% = 0.2 alucinaciones, diez veces menos que el fat core original. Las dos palancas se multiplican, pero la de la superficie es de arquitectura (la controlas tú, con certeza) y la de la tasa es estadística (depende del modelo, nunca es perfecta). Por eso encoger el núcleo protege incluso —sobre todo— cuando el modelo ya es bueno: sobre una base pequeña, hasta una tasa baja produce pocas alucinaciones absolutas.

Ejercicio 3 — Encoge este núcleo. Un equipo diseñó un agente de soporte donde el LLM decide, en una sola llamada: (1) qué pedido es el del cliente, (2) el monto del reembolso, (3) si el cliente es "premium" y merece un trato especial, (4) si aplicar la política de excepción, y (5) el mensaje de respuesta. Identifica cuáles decisiones deberían salir del núcleo a reglas deterministas, cuáles se quedan, y qué gana el diseño.

Ver solución

Análisis decisión por decisión:

(1) Qué pedido es el del cliente → mixto. Interpretar "el pedido que llegó roto" es del núcleo (necesita entender lenguaje), pero resolver eso a un order_id concreto debe validarse contra la fuente de verdad (¿existe ese pedido de este cliente?). El modelo propone cuál cree que es; la cáscara verifica que exista y sea del cliente.
(2) Monto del reembolso → núcleo. Depende de entender el reclamo del cliente ("me cobraron de más por el envío"). Se queda, pero pasa por la validación de reglas (L5) antes de ejecutar.
(3) Si el cliente es "premium" → cáscara (regla). Es un dato en la base de datos: customer.tier == "premium". No es un juicio; es una consulta. Sale del núcleo —dejar que el modelo adivine el tier del cliente es absurdo y peligroso—.
(4) Si aplicar la política de excepción → cáscara (regla). Las excepciones tienen condiciones definidas (tier premium + dentro de X días + monto bajo Y). Es una regla conjuntiva, no un juicio del modelo. Sale del núcleo.
(5) El mensaje de respuesta → núcleo. Generar la respuesta amable en lenguaje natural es del modelo. Se queda (probablemente como el campo text de un send_message).

Qué sale: (3) y (4) —el tier premium y la aplicación de excepciones— son datos y reglas, no juicios; salen a la cáscara. (1) se parte: la interpretación es del núcleo, la resolución/verificación es de la cáscara. Qué se queda: (2) el monto y (5) el mensaje, que genuinamente necesitan inteligencia.

Qué gana el diseño: la superficie probabilística baja de 5 decisiones a ~2-3 (según cómo cuentes la mixta). Las decisiones más peligrosas y verificables —el tier del cliente, si aplica una excepción— dejan de depender de que el modelo las adivine bien y pasan a ser consultas y reglas deterministas, que no se equivocan. El modelo se queda con lo que solo él puede hacer (entender el reclamo, redactar la respuesta), y todo lo verificable se vuelve certero. Menos superficie que contener, decisiones de estado más confiables, misma feature.

Resumen y siguiente paso

En esta lección diste un paso atrás de contener para preguntar cuánto debe decidir el modelo en primer lugar, y llegaste a la disciplina que da nombre a la guía: mantén el núcleo probabilístico pequeño. Cada decisión que sacas del núcleo a una regla determinista es una que ya no puede alucinar —y que ya no tienes que contener—. Lo mediste: un fat core con cuatro decisiones por caso expone 80 decisiones probabilísticas sobre 20 casos; un thin core con una expone 20 —un 75% menos de superficie que puede alucinar—, sin cambiar el modelo, solo cambiando qué decide. Viste que la pregunta de diseño es "¿esta decisión necesita inteligencia o es una regla disfrazada?"; que encoger el núcleo no limita la feature (las cuatro decisiones se siguen tomando, solo cambia quién); que es un eje distinto de "mejorar el modelo" (superficie vs tasa, y se multiplican); y que la decisión de escalar, en particular, debe ser una regla y no un juicio del modelo.

Antes de avanzar deberías poder: distinguir la superficie del núcleo de la calidad del núcleo; identificar decisiones que son reglas disfrazadas y sacarlas del núcleo; argumentar por qué encoger el núcleo protege incluso con un modelo bueno; y explicar por qué el escalamiento pertenece a la cáscara.

La lección 7 ensambla todo lo que construiste en un solo flujo: el pipeline propuesta → ejecución. Ya tienes las piezas —el modelo propone (L2), en formato estructurado (L3), de un menú acotado (L4), validado contra reglas (L5), con un núcleo pequeño (L6)—; ahora las pones en orden como compuertas en serie —estructura → capability → política → ejecutar— con un log de auditoría que registra qué se propuso, qué se aprobó y qué se bloqueó en cada etapa. Vas a ver el pipeline completo corriendo sobre un lote, mostrando en qué etapa se detuvo cada propuesta bloqueada. La cáscara determinista, entera y ejecutada.

Recursos

Anthropic, "Building Effective Agents" (2024) — anthropic.com/engineering/building-effective-agents. Su principio de mantener el componente de IA simple y acotado, y poner el trabajo determinista alrededor, es exactamente la disciplina de "núcleo pequeño" de esta lección aplicada a las acciones. En inglés.
Martin Fowler y Bharani Subramaniam, "Emerging Patterns in Building GenAI Apps" — martinfowler.com/articles/gen-ai-patterns. La discusión sobre cuánto delegar al modelo y cuánto dejar en código determinista es la versión de patrones de la decisión núcleo/cáscara. En inglés.
Chip Huyen, AI Engineering (O'Reilly, 2024). Su tratamiento de la arquitectura de aplicaciones —el modelo como un componente rodeado de lógica de aplicación— es la versión extendida de la metáfora núcleo/cáscara. Aquí la aplicamos a las decisiones que tocan estado. En inglés.
La guía architecture-decisions-and-tradeoffs-guide (este mismo ecosistema). La decisión de qué vive en el núcleo probabilístico y qué en la cáscara determinista es un tradeoff arquitectónico —inteligencia vs certeza— del tipo que esa guía trata como decisión de diseño explícita. En español.

← AnteriorValidar la propuesta contra las reglas de negocio Siguiente →El pipeline propuesta → ejecución