Módulo 6: La cáscara determinista
El pipeline propuesta → ejecución
Descripción
Tienes todas las piezas de la cáscara determinista, cada una construida y medida por separado: el modelo propone en vez de ejecutar (L2), en un formato estructurado (L3), de un menú acotado de capabilities (L4), validado contra las reglas de negocio (L5), con un núcleo mantenido pequeño (L6). Esta lección las pone en orden, como compuertas en serie, en un solo flujo que va de la propuesta a la ejecución: estructura → capability → política → ejecutar. Y le agrega la pieza que faltaba y que hace de todo esto un sistema operable, no solo seguro: el log de auditoría, que registra qué se propuso, qué se aprobó, qué se bloqueó y en qué etapa.
El pipeline es la cáscara determinista entera, ejecutada de punta a punta. Cada propuesta del modelo entra por la primera compuerta y avanza mientras pase; en cuanto una compuerta la rechaza, se detiene ahí y se registra la razón. Solo las propuestas que pasan las tres compuertas llegan a ejecutarse. Vas a ver el pipeline corriendo sobre un lote de ocho propuestas variadas, mostrando en qué etapa se detuvo cada bloqueo: una en estructura, dos en capability, dos en política, y tres que pasaron todo y se ejecutaron.
Conexión con el módulo. Esta es la lección de síntesis operativa: ensambla las compuertas de L3, L4 y L5 en el orden correcto y agrega la auditoría. Es el equivalente, para las acciones, de "la hoja de propiedades" o "el request path" de los módulos anteriores: el patrón completo en un artefacto que puedes llevarte. La frontera con el módulo 7 (el lazo de datos) aparece aquí en germen: el log de auditoría que esta lección construye para operar la cáscara es también la materia prima del lazo de retroalimentación del módulo 7 —cada decisión registrada es un dato sobre cómo se comporta el modelo—. La frontera con AI Engineering se mantiene: el pipeline contiene y audita las acciones; cómo el modelo las genera es AI Eng.
Una analogía: el control de seguridad del aeropuerto
Piensa en cómo pasas de la entrada de un aeropuerto a la puerta de embarque. No es un solo control: es una secuencia de compuertas en orden, y cada una verifica algo distinto. Primero, el documento: ¿tu pase de abordar es válido y legible? Si no tienes pase, no pasas —y ni siquiera importa a dónde vayas—. Segundo, la identidad: ¿tu identificación coincide con el pase? Si no, te detienes ahí. Tercero, la inspección de seguridad: ¿lo que llevas cumple las reglas —nada prohibido, líquidos en su límite—? Si algo falla, te detienen en ese punto. Solo si pasas las tres llegas a abordar. Y cada compuerta verifica algo que las anteriores no: el documento no mira tu maleta, la inspección no revisa tu pase.
Fíjate en dos propiedades de esta secuencia. Primero, el orden importa: la inspección de seguridad no tiene sentido antes de verificar que tienes un pase válido —¿para qué inspeccionar la maleta de alguien que ni siquiera va a volar?—. Las compuertas van de la más básica (¿tienes documento?) a la más específica (¿tu equipaje cumple las reglas?). Segundo, hay un registro: cada control deja constancia de que pasaste (o de que te detuvieron y por qué). Si algo sale mal, o si alguien pregunta "¿cómo llegó esta persona a la puerta?", hay una traza de por cuáles compuertas pasó y cuáles no.
Ese control de seguridad es el pipeline propuesta → ejecución. La compuerta del documento es el chequeo de estructura (¿es un comando bien formado?); la de identidad es la de capability (¿este agente puede proponer esta acción?); la de inspección es la de reglas de negocio (¿la acción cumple la política?). El orden va de lo básico a lo específico, igual que en el aeropuerto. Y el registro de cada control es el log de auditoría: la traza de qué se propuso, qué pasó y qué se detuvo, para poder operar el sistema y responder cuando alguien pregunta cómo se ejecutó (o no) una acción.
Ejemplo trabajado: el pipeline completo, con auditoría
Vamos a correr el control de seguridad entero. Definimos las tres compuertas como funciones —stage_structure, stage_capability, stage_policy— y las ponemos en una lista, en orden. Cada propuesta pasa por las compuertas en secuencia; en cuanto una la rechaza, se detiene ahí, se registra la etapa y la razón, y no avanza. Las que pasan las tres se ejecutan. Para que se vea la separación de compuertas, el menú de comandos conocidos (ACTION_MENU) incluye acciones que existen en la plataforma pero que este agente no tiene otorgadas (issue_store_credit, change_price): así una de ellas se detiene en la compuerta de capability, no en la de estructura. Corremos un lote de ocho propuestas.
# Modulo 6, Leccion 7: el pipeline propuesta -> ejecucion.
# Ensambla las tres compuertas en orden: estructura (canal) -> capability
# (menu) -> reglas de negocio (politica) -> ejecutar. Cada propuesta del LLM
# pasa por el pipeline y queda en un log de auditoria. Sin red, sin API.
ORDERS = {
"A-1001": {"total": 50.00, "days_since_delivery": 3, "refunded": False},
"A-1002": {"total": 120.00, "days_since_delivery": 45, "refunded": False},
"A-1005": {"total": 75.00, "days_since_delivery": 8, "refunded": False},
}
MAX_REFUND = 100.00
RETURN_WINDOW_DAYS = 30
# Menu de comandos conocidos (estructura) y sus campos requeridos.
ACTION_MENU = {
"refund": {"order_id", "amount"},
"escalate_to_human": {"reason"},
"send_message": {"text"},
"issue_store_credit": {"amount"},
"change_price": {"product_id", "price"},
}
# Capabilities GRANTED al agente de soporte (subconjunto del menu).
GRANTED = {"refund", "escalate_to_human", "send_message"}
def stage_structure(p):
if not isinstance(p, dict):
return (False, "texto libre, no es un comando")
action = p.get("action")
if action not in ACTION_MENU:
return (False, f"accion desconocida: {action!r}")
if ACTION_MENU[action] - p.keys():
return (False, "faltan campos requeridos")
return (True, "")
def stage_capability(p):
if p["action"] not in GRANTED:
return (False, f"{p['action']} fuera de las capabilities del agente")
return (True, "")
def stage_policy(p):
if p["action"] != "refund":
return (True, "") # solo refund toca dinero y necesita politica
oid, amount = p["order_id"], p["amount"]
if oid not in ORDERS:
return (False, f"pedido {oid} no existe")
o = ORDERS[oid]
if o["refunded"]:
return (False, f"pedido {oid} ya reembolsado")
if o["days_since_delivery"] > RETURN_WINDOW_DAYS:
return (False, "fuera de la ventana de devolucion")
if amount > o["total"] or amount > MAX_REFUND:
return (False, "monto fuera de limite")
return (True, "")
def execute(p):
if p["action"] == "refund":
ORDERS[p["order_id"]]["refunded"] = True
return p["amount"]
return 0.0
PIPELINE = [("ESTRUCTURA", stage_structure),
("CAPABILITY", stage_capability),
("POLITICA", stage_policy)]
PROPOSALS = [
{"action": "refund", "order_id": "A-1001", "amount": 50.00},
"voy a devolverte el dinero enseguida",
{"action": "issue_store_credit", "amount": 200.00},
{"action": "change_price", "product_id": "P-1", "price": 0.01},
{"action": "refund", "order_id": "A-1002", "amount": 120.00},
{"action": "refund", "order_id": "A-9999", "amount": 40.00},
{"action": "escalate_to_human", "reason": "cliente pide supervisor"},
{"action": "refund", "order_id": "A-1005", "amount": 75.00},
]
print(f"{'#':<3}{'accion':<20}{'resultado':<14}{'detenida en':<12}razon")
print("-" * 92)
executed = 0
money = 0.0
stopped = {"ESTRUCTURA": 0, "CAPABILITY": 0, "POLITICA": 0}
for i, p in enumerate(PROPOSALS):
action_name = p["action"] if isinstance(p, dict) and "action" in p else "(texto libre)"
blocked_at = None
reason = ""
for stage_name, stage_fn in PIPELINE:
ok, why = stage_fn(p)
if not ok:
blocked_at = stage_name
reason = why
stopped[stage_name] += 1
break
if blocked_at is None:
money += execute(p)
executed += 1
print(f"{i:<3}{action_name:<20}{'EJECUTADA':<14}{'-':<12}{reason}")
else:
print(f"{i:<3}{action_name:<20}{'BLOQUEADA':<14}{blocked_at:<12}{reason}")
print()
print(f"Ejecutadas : {executed}/{len(PROPOSALS)} dinero movido: {money:.2f}")
print(f"Bloqueadas por etapa -> ESTRUCTURA: {stopped['ESTRUCTURA']} "
f"CAPABILITY: {stopped['CAPABILITY']} POLITICA: {stopped['POLITICA']}")Qué esperar. Al correr el archivo, la salida es exactamente esta:
# accion resultado detenida en razon
--------------------------------------------------------------------------------------------
0 refund EJECUTADA -
1 (texto libre) BLOQUEADA ESTRUCTURA texto libre, no es un comando
2 issue_store_credit BLOQUEADA CAPABILITY issue_store_credit fuera de las capabilities del agente
3 change_price BLOQUEADA CAPABILITY change_price fuera de las capabilities del agente
4 refund BLOQUEADA POLITICA fuera de la ventana de devolucion
5 refund BLOQUEADA POLITICA pedido A-9999 no existe
6 escalate_to_human EJECUTADA -
7 refund EJECUTADA -
Ejecutadas : 3/8 dinero movido: 125.00
Bloqueadas por etapa -> ESTRUCTURA: 1 CAPABILITY: 2 POLITICA: 2
Lee el log de auditoría fila por fila, porque cada bloqueo cayó en la compuerta que le corresponde.
Tres propuestas pasaron las tres compuertas y se ejecutaron. La 0 (refund A-1001 $50), la 6 (escalate_to_human) y la 7 (refund A-1005 $75): cada una es un comando bien formado, dentro de las capabilities del agente, que cumple la política (o que, como el escalamiento, no toca dinero y no necesita política). Solo estas tres movieron el sistema —$125 en reembolsos legítimos y un escalamiento a un humano—. Las tres pasaron por las tres compuertas en orden, como el pasajero que muestra su pase, su identidad y su equipaje y llega a abordar.
Cada bloqueo cayó en su compuerta, y eso es diagnóstico puro. Mira la columna "detenida en":
- La 1 (texto libre) se detuvo en ESTRUCTURA: no es siquiera un comando, así que ni tiene sentido preguntar por su capability o su política. Se rechazó en la primera compuerta, la más básica.
- Las 2 y 3 (
issue_store_credit,change_price) se detuvieron en CAPABILITY: son comandos bien formados —pasaron estructura— pero no están entre las capabilities otorgadas al agente de soporte. Fíjate en lo importante: son acciones que existen en la plataforma (están enACTION_MENU, por eso pasaron estructura), pero este agente no las tiene otorgadas (no están enGRANTED). Se rechazan en la segunda compuerta, por identidad de agente, no por formato. - Las 4 y 5 (
refundA-1002 fuera de ventana,refundA-9999 inexistente) se detuvieron en POLITICA: sonrefundbien formados, dentro de las capabilities del agente, pero violan las reglas de negocio. Se rechazan en la tercera y última compuerta, por política.
El orden de las compuertas evita trabajo inútil. Fíjate en que ninguna propuesta se evaluó en una compuerta posterior a la que la detuvo. El texto libre de la fila 1 nunca llegó a la validación de política —¿para qué preguntar por la ventana de devolución de algo que ni es un comando?—. Es la misma lógica del aeropuerto: no inspeccionas la maleta de quien no tiene pase. Las compuertas van de lo básico (¿es un comando?) a lo específico (¿cumple la política?), y cada propuesta avanza solo hasta donde falla. Esto no es solo eficiencia: es claridad diagnóstica —la etapa donde se detuvo es el tipo de problema que tiene—.
El resumen por etapa es un tablero de operación. La última línea —"ESTRUCTURA: 1, CAPABILITY: 2, POLITICA: 2"— no es un adorno: es información operativa. Si un día ese conteo cambia bruscamente —de golpe muchos bloqueos en CAPABILITY—, te dice que el modelo empezó a proponer acciones fuera de su menú (¿un cambio de prompt?, ¿un intento de manipulación?, ¿un drift?). El log de auditoría convierte la cáscara de una caja negra que "a veces bloquea" en un sistema observable, donde sabes exactamente qué se propuso, qué se aprobó, qué se bloqueó y por qué. Y esa observabilidad es, además, la primera materia prima del lazo de datos del módulo 7.
Profundización: la cáscara como un pipeline observable
El ejemplo mostró el flujo; vale la pena entender las propiedades que hacen de este pipeline un artefacto de diseño, no solo una secuencia de if.
El orden de las compuertas es de lo general a lo específico. Estructura → capability → política no es un orden arbitrario: es de la pregunta más básica a la más específica. Estructura pregunta "¿es esto siquiera un comando?" —lo más general, y precondición de todo lo demás—. Capability pregunta "¿es un comando de este agente?" —más específico, pero aún independiente de los datos—. Política pregunta "¿es una acción que cumple las reglas ahora mismo?" —lo más específico, y lo que requiere consultar la fuente de verdad—. Poner las compuertas en este orden significa que cada propuesta se rechaza en la etapa más temprana (y más barata) posible, y que las etapas caras —consultar la base de datos para la política— solo se corren para propuestas que ya pasaron las baratas. Es el mismo principio de "falla rápido y barato" que rige cualquier pipeline de validación.
El pipeline: compuertas EN ORDEN, de lo general a lo especifico
propuesta del LLM
│
▼
┌──────────────┐ falla → BLOQUEA (registra: ESTRUCTURA) ─┐
│ ESTRUCTURA │ ¿es un comando del menu, con campos? │
└──────────────┘ │
│ pasa │
▼ │
┌──────────────┐ falla → BLOQUEA (registra: CAPABILITY) ─┤
│ CAPABILITY │ ¿es un comando de ESTE agente? │
└──────────────┘ ├──► LOG DE
│ pasa │ AUDITORIA
▼ │
┌──────────────┐ falla → BLOQUEA (registra: POLITICA) ───┤
│ POLITICA │ ¿cumple las reglas de negocio? │
└──────────────┘ │
│ pasa │
▼ │
┌──────────────┐ │
│ EJECUTAR │ el dinero/estado se mueve SOLO aqui ────┘
└──────────────┘ (y tambien se registra)
El log de auditoría es parte del diseño, no un extra. Es tentador ver el logging como algo que se agrega "después, si hay tiempo". En una cáscara que controla acciones sobre dinero, es al revés: la auditoría es un requisito de diseño. Por tres razones. Rendición de cuentas: cuando alguien pregunta "¿por qué se reembolsó (o no) este pedido?", el log tiene la respuesta exacta —qué se propuso y qué compuerta decidió—. Observabilidad: el conteo por etapa es un tablero que revela cambios en el comportamiento del modelo antes de que se vuelvan un problema. Depuración: cuando algo sale mal, el log dice en qué compuerta y por qué, sin tener que reconstruir el flujo. Una cáscara sin auditoría contiene las acciones pero es opaca; con auditoría, contiene y explica. Y explicar es lo que te permite operar el sistema, no solo tenerlo corriendo.
El pipeline es la hoja de propiedades de la cáscara de acciones. Si el módulo 4 tenía su "guardrail stack" y el módulo 1 su "hoja de propiedades del componente", este pipeline es el artefacto equivalente para las acciones: la lista ordenada de compuertas que toda acción propuesta debe pasar, más el registro de lo que pasó. Cuando diseñes la cáscara de una feature de IA que toma acciones, este es el molde: ¿cuál es su chequeo de estructura?, ¿cuál su menú de capabilities?, ¿cuáles sus reglas de política?, ¿cómo se audita? Responder esas cuatro preguntas es diseñar la cáscara. El pipeline no es una implementación entre muchas; es la forma canónica de la contención de acciones.
Ejecutar es solo una etapa más, la última. Fíjate en un detalle del diagrama: execute está al mismo nivel que las compuertas, como la etapa final del pipeline, y el dinero se mueve solo ahí, después de las tres validaciones. Esto materializa toda la tesis del módulo: la ejecución no está acoplada a la salida del modelo (eso era el antipatrón de L2); está al final de un pipeline de compuertas que la propuesta tuvo que pasar entera. El modelo propone al principio; el sistema dispone en cada compuerta; el efecto ocurre solo al final, y solo para lo que pasó todo. "El modelo propone, el sistema dispone" no es una frase: es la estructura de este pipeline.
Errores comunes
Poner las compuertas en desorden o saltarse alguna. Qué pasa: el pipeline valida la política antes de verificar la estructura, o se salta la compuerta de capability confiando en que las reglas atraparán todo. El resultado son errores raros —intentar leer el order_id de algo que no es un comando y caerse— o agujeros —una acción fuera del menú del agente que pasa porque nadie chequeó sus capabilities—. Por qué pasa: el orden parece un detalle, y cada compuerta parece redundante con las otras. Cómo detectarlo: ¿tu pipeline evalúa la estructura primero, luego capability, luego política, y detiene la propuesta en la primera que falla? Si no, tienes desorden o huecos. Cómo corregirlo: las compuertas van de lo general a lo específico, en orden, y cada propuesta se detiene en la primera que la rechaza. Cada compuerta protege contra algo que las otras no ven; ninguna sobra.
Ejecutar y auditar como pasos separados que pueden desincronizarse. Qué pasa: el código ejecuta la acción en un lugar y escribe el log en otro, y cuando algo falla en medio, el sistema puede ejecutar sin registrar (o registrar sin ejecutar), dejando una traza que no coincide con la realidad. Por qué pasa: el logging se trata como un efecto secundario opcional, no como parte de la transacción. Cómo detectarlo: ¿puede tu sistema mover dinero sin dejar un registro, o dejar un registro de algo que no ocurrió? Cómo corregirlo: trata la ejecución y su registro como una unidad —lo que se ejecuta se audita, siempre, en el mismo flujo—. El log tiene que ser un espejo fiel de lo que el sistema hizo, o no sirve para rendir cuentas.
Tratar el log como ruido y no mirarlo. Qué pasa: el pipeline audita todo, pero nadie mira el log ni el conteo por etapa, así que un cambio en el comportamiento del modelo —de golpe muchos bloqueos en capability, o en política— pasa desapercibido hasta que se vuelve un incidente. Por qué pasa: el log se ve como un archivo para "cuando algo falle", no como un tablero para vigilar. Cómo detectarlo: si nadie revisa las métricas de tu cáscara de forma regular, la auditoría solo sirve como autopsia, no como alerta temprana. Cómo corregirlo: el conteo por etapa es una señal en vivo —vigílalo—. Un salto en los bloqueos de una etapa es información sobre el modelo, sobre un ataque, o sobre un drift, y es exactamente la clase de señal que el lazo de datos del módulo 7 convierte en mejora del sistema.
Ejercicios
Ejercicio 1 — Predice la etapa. Sin correr el código, para cada una de estas propuestas di en qué compuerta se detendría (o si se ejecutaría), dado el agente del ejemplo (GRANTED = {refund, escalate_to_human, send_message}, ACTION_MENU incluye además issue_store_credit y change_price): (a) {action: "send_message", text: "Listo"}; (b) {action: "change_price", product_id: "P-2", price: 5.00}; (c) {action: "refund", order_id: "A-1005", amount: 90.00}; (d) {action: "cancel_order", order_id: "A-1001"}.
Ver solución
- (a)
send_message→ EJECUTA. Estructura: es un comando del menú con su campotext— pasa. Capability:send_messageestá enGRANTED— pasa. Política: no esrefund, así que no necesita validación de reglas — pasa. Las tres compuertas: se ejecuta. - (b)
change_price→ BLOQUEA en CAPABILITY. Estructura:change_priceestá enACTION_MENUcon sus camposproduct_idyprice— pasa estructura. Capability:change_priceno está enGRANTED(el agente de soporte no lo tiene otorgado) — se detiene aquí. Es un comando válido de la plataforma, pero no de este agente. - (c)
refundA-1005 $90 → EJECUTA. Estructura:refundconorder_idyamount— pasa. Capability:refundestá enGRANTED— pasa. Política: A-1005 existe, no reembolsado, 8 días ≤ 30, $90 ≤ total ($75)... espera —$90 > $75 (el total del pedido)—, así que BLOQUEA en POLITICA por "monto fuera de limite". (Corrección: el monto excede el total del pedido, aunque esté bajo el límite de $100.) Lección: hay que verificar los datos reales del pedido, no solo el límite del agente. - (d)
cancel_order→ BLOQUEA en ESTRUCTURA.cancel_orderno está enACTION_MENUen absoluto —no es un comando conocido de la plataforma—, así que se detiene en la primera compuerta por "accion desconocida". Ni siquiera llega a capability. Es una acción inventada/alucinada.
El patrón: el tipo de problema determina la compuerta. Acción inventada → estructura; acción real pero no de este agente → capability; acción del agente que viola las reglas → política. (Nota: (c) muestra que "bajo el límite del agente" no basta si excede el total del pedido; ambas reglas de monto aplican.)
Ejercicio 2 — Por qué el orden. Explica por qué el pipeline pone ESTRUCTURA antes que POLITICA, y qué pasaría si se invirtiera el orden y se validara la política primero. Da un ejemplo concreto del lote donde el orden invertido causaría un problema.
Ver solución
El pipeline pone ESTRUCTURA antes que POLITICA porque la validación de política depende de que la propuesta ya sea un comando bien formado: para preguntar "¿el monto excede el límite?" o "¿el pedido existe?", primero tiene que haber un amount y un order_id que consultar. La política razona sobre los campos de la acción; si la propuesta ni siquiera es un comando (es texto libre) o le faltan campos, no hay nada sobre lo cual razonar.
Si se invirtiera el orden y se validara la política primero, la fila 1 del lote —"voy a devolverte el dinero enseguida" (texto libre)— causaría un problema concreto: stage_policy intentaría leer p["order_id"] y p["amount"] de un string, lo que lanzaría un TypeError (un string no se indexa con claves) y el pipeline se caería, en vez de rechazar limpiamente la propuesta con "no es un comando". La compuerta de estructura existe precisamente para garantizar que, cuando la propuesta llegue a política, ya sea un comando con sus campos —de modo que la política pueda asumir que puede leerlos sin miedo—. El orden general → específico no es estético: cada compuerta prepara el terreno para la siguiente, verificando las precondiciones que la siguiente da por sentadas.
Ejercicio 3 — Diseña la auditoría. El equipo de operaciones de Mercado quiere poder responder tres preguntas sobre el agente de soporte: (1) ¿cuánto dinero reembolsó el agente hoy?, (2) ¿está el modelo proponiendo más acciones fuera de su menú que la semana pasada?, (3) cuando un cliente reclama "el agente no me quiso reembolsar", ¿por qué se bloqueó? Para cada pregunta, di qué dato del log de auditoría la responde y por qué la auditoría es parte del diseño de la cáscara, no un extra.
Ver solución
- (1) ¿Cuánto reembolsó hoy? → el registro de las acciones ejecutadas con su monto (la variable
moneydel ejemplo, acumulada por día). El log de lo aprobado y ejecutado da la suma exacta de dinero movido, sin tener que reconstruirla de la base de datos. - (2) ¿Más acciones fuera del menú que la semana pasada? → el conteo de bloqueos por etapa, específicamente los de CAPABILITY, comparados entre semanas. Un aumento en los bloqueos de capability significa que el modelo está proponiendo más acciones fuera de su menú —posible cambio de prompt, intento de manipulación, o drift—. El conteo por etapa es un tablero de tendencias.
- (3) ¿Por qué se bloqueó el reembolso de este cliente? → la fila del log de esa propuesta: la etapa donde se detuvo y la razón ("fuera de la ventana de devolución", "pedido no existe", "monto fuera de límite"). El log da la respuesta exacta y auditable, no una suposición.
Por qué la auditoría es parte del diseño y no un extra: sin ella, la cáscara contiene las acciones pero es una caja opaca —bloquea y ejecuta, pero no puedes decir por qué, ni vigilar cómo cambia, ni rendir cuentas—. Las tres preguntas de operaciones son necesidades reales de un sistema que mueve dinero, y ninguna se puede responder sin el registro. Una cáscara que controla dinero tiene que ser auditable por diseño: la rendición de cuentas, la observabilidad y la depuración no son features opcionales, son requisitos de operar un sistema que toma decisiones sobre el dinero de la gente. Además, ese mismo log es la materia prima del lazo de datos del módulo 7: cada decisión registrada es un dato sobre el comportamiento del modelo que puede mejorar el sistema.
Resumen y siguiente paso
En esta lección ensamblaste todas las piezas del módulo en un solo flujo: el pipeline propuesta → ejecución. Las compuertas van en orden, de lo general a lo específico —estructura → capability → política → ejecutar—, y cada propuesta se detiene en la primera que la rechaza. Lo viste correr sobre ocho propuestas: tres pasaron las tres compuertas y se ejecutaron ($125 movidos, un escalamiento); cinco se bloquearon, cada una en la compuerta que le correspondía —una en estructura, dos en capability, dos en política—. Aprendiste que el orden general → específico hace que cada propuesta se rechace en la etapa más temprana y barata (y que cada compuerta prepara las precondiciones de la siguiente); que el log de auditoría es parte del diseño y no un extra (rendición de cuentas, observabilidad, depuración); y que ejecutar es solo la última etapa, donde el dinero se mueve solo para lo que pasó todo. La cáscara determinista, entera y observable.
Antes de avanzar deberías poder: ordenar las compuertas de lo general a lo específico y justificar el orden; explicar por qué cada compuerta prepara la siguiente; argumentar por qué la auditoría es un requisito de diseño de una cáscara que mueve dinero; y leer el conteo por etapa como un tablero de operación.
La lección 8 es el capstone del módulo: construyes la cáscara determinista completa del agente de soporte de Mercado. Vas a tomar el pipeline de esta lección y correrlo sobre un lote de doce propuestas del modelo —legítimas, alucinadas, fuera de política, montos absurdos, capabilities no otorgadas— para medir la tasa de contención y el dinero que la cáscara protegió. La entrega junta todo: el diagrama de la cáscara, el código ejecutado, un ADR que registra la decisión de contener las acciones del modelo, y la justificación de por qué, en este diseño, el LLM nunca toca el dinero directamente.
Recursos
- Anthropic, "Building Effective Agents" (2024) — anthropic.com/engineering/building-effective-agents. Su descripción de los controles y verificaciones alrededor de las acciones de un agente es la base del pipeline de compuertas de esta lección. En inglés.
- Martin Fowler y Bharani Subramaniam, "Emerging Patterns in Building GenAI Apps" — martinfowler.com/articles/gen-ai-patterns. Los patrones de guardrails compuestos y de observabilidad de apps GenAI ubican este pipeline auditado en el mapa completo. En inglés.
- Chip Huyen, AI Engineering (O'Reilly, 2024). Sus capítulos sobre observabilidad y monitoreo de aplicaciones con modelos tratan el logging de decisiones —qué se propuso, qué se ejecutó— como parte del diseño, no como un extra. En inglés.
- La guía
observability-and-operations-guideo equivalente del ecosistema, para la mecánica de logging, trazas y métricas a fondo. Aquí aplicamos la observabilidad al pipeline de acciones de un componente de IA; su disciplina completa vive en la guía de operaciones. En español.